The problem is that this module is not being used in an actual project that I am involved in, which is usually the reason why stuff gets done

The HLAC codec is used throughout the entire signal path and reduces memory usage by 50% for the preload buffers and increases the streaming perfomance because the files are smaller (up to 40%). Actually there‘s no reason not to use it...

@hisefilo said in Collaborative project!:

Size of interface ?

If you make it 1024x768 (or 2048x1536 in retina resolution), it might be exported as iPad app too, which might be intriguing for this kind of project without high a sample count.

Yes, the entire SNEX thing is completely broken right now, it's being rebuilt from the ground up and there are many things that XCode (or clang) complains about which compiles on Windows, but I am doing the macOS fixes once every milestone.

The framex_block nodes are not supposed to be used in an actual project (at the end), they are just useful during development, that's why the C++ code generator is part of scriptnode. This snippet should run about 10x times faster if it's compiled as custom node.

However Greg is right, I am currently rewriting SNEX to be able to compile the C++ generated code from a scriptnode patch, so the workflow for using frame blocks in almost-native performance might be vastly improved.

If you don't want to wait (it's a really big TODO list here), you might get the CPU down to sensitive levels by using a fix16_block instead of a framex_block.

Dave is right, every UI control has to be declared at the beginning. The reason for this is that the UI controls also act as data model and for the sake of preset consistency you need to have every slot defined (see https://docs.hise.audio/working-with-hise/project-management/user-presets/index.html)

With C++ you can easily decouple this connection and build up a separate data model which the UI controls act upon (which is what I am doing in PercX).

Nonononono, multiple no-gos. I am surprised that the AudioThreadGuard didn‘t fire

Use a stereo FX and modulate it polyphonically.

If you want precise musical timing you need to use the onTimer callback, the other ones will run in the UI thread.

If you want 100% sample accurate timing, take the timestamp of the timer callback into account (Message.getTimestamp() works there also)...

Every time I have a project getting big, Hise behave strangely. I say strangely because it's not 100% the same issue all the time.

One thing that might cause issues is the compile time-out which fires if you have a lot of stuff to do in the first onInit call. For example loading a lot of audio files might cause the time-out to fire, but if you compile it multiple times, it wents through.

The default is 5 seconds, but you can raise that value if you run against that limit with bigger stuff in the HISE settings (search "Compile Timeout").

MMC is not SysEx, so it's not impossible to add that.