wish: multithread mode

[wayfu]

I know, i know, it's all interconnected and stuff on one instrument can depend on stuff from another, etc. still, i am thinking that at least for authoring if not for the replayer, shouldn't it be possible to use more than one cpu thread, to make things a little easier?

[vsariola]

Short answer: Probably not. But as a quick hack, if you are working in VSTI, you can add two Sointus to your DAW. Make one have midi channels 1-8 and blank instruments 1-8 and some other instruments on channels 9-16. Then make sure the Global instrument is identical, so that they produce same sound. You can copy-paste instruments using the clipboard from one Sointu to another, just move your cursor to the instrument name in the top and hit Ctrl-C, and then Ctrl-V in the other Sointu. Route the MIDI events to the two Sointus properly, however that is done in your DAW. Then, once you are finished with the song, you can copy paste the instruments back and undo the hack. You can of course do this have even more than 2 Sointus.

Notice that I recently benchmarked the CPU load and notice the -native synths are nowadays slower than the pure Go versions (!), so if you are using native, switch to non-native for a ~30% performance boost. You can get the latest versions from e.g. here

Long answer: The 4klang/sointu VM is designed to be ran once per sample. With the way units are inputted, the user is essentially writing "code" for the VM. The compiler never constructs a graph of what signal depends on which signal. In principle, it would be possible to construct this graph based on the VM code, but at that point, if we are going to construct a node graph of the signal flows, the UI probably should have been a graph based user interface in the first place.

Now, even if we were to construct that graph, it is not completely trivial problem to split the graph to multiple processors.

Ultimately, we would like to also vectorize the simple math operations (add / mul / addp / mulp etc.), e.g. using avx instructions. This would require analyzing the graph where the VM can be converted from "vertical" into "horizontal": instead of running the entire VM once per sample, run VM once, with each operation being vectorized.

All of this has been thought out. But it would be such a massive rewrite so that I might just call it a new project at that point, it's the "next synth project".

[vsariola]

There's the additional mess that units being one after another in the chain and send are not the only ways units can be communicate: units also communicate through shared memory. Outaux and friends are esaentially read / writes to global memory addresses. These are good sizecoding solutions to a common problem, but it is not a good design for analyzing interdependencies.

The only practical solution that comes to my mind is supporting the "hack" out of the box: e.g. make the patch have tabs, each tab with a completely independent patch fhat is ran on a separate thread.

[vsariola]

Spent the night thinking about it and perhaps a variant of it actually an implementable solution? Just let the user click for each instrument on which CPU core it is ran. The user can select multiple CPU cores, let's say small buttons 1-4 for starters. Then, when actually rendering, 4 copies are made of the patch, with every instrument that is not selected to be rendered on that CPU replaced with an empty instrument, and sent to be rendered on 4 different cores.

Benefits and drawbacks of the approach

1. User can select all cores 1-4 for the Global instrument, so that it gets processed on all cores.
2. User takes the responsibility to make sure that instruments that modulate each other get rendered on same core, so no need to perform any automagic analysis.
3. When compiling the song, we can just ignore the core selections for instrument. In most cases it should sound practically identical to the parallelized version, but of course there are edge cases where the resulting sound might be very different. For example, assume you had 4 instruments, each running on different core, and one Global. Then you feedback the global signal back to Instrument 1:s parameter. During composing, this feedback loop includes only the Instrument 1 and the Global on core 1, but in the final, the output of all instruments 1-4 modulate the parameter on Instrument 1. This actually means that the patch was not parallelizable and the user should not have used multicore rendering in the first place.

This approach is within the realm of doable things.

[wayfu]

thank you for the explanation! i will try the multiple instances approach and see how well that works for my use cases.

[vsariola]

Good luck! I consider this now as "maybe fix"; I need to actually try implementing that hack to see if it is actually doable in code or if there's some subtle difficulties.

[vsariola]

This is now implemented on the authoring side (tracker / VSTI). The thread selections are ignored by the compiler at the moment, but I will eventually make the player support it also, it's just that writing the assembly code takes a bit longer and I thought to give this for testing already.

In order to use multiple threads:

1. Select the thread from the Instrument Properties pane:

2. Select a "Multithread *" synth from the CPU panel:

Notice that the Global needs to be placed on all threads that you use, otherwise you will be missing the reverb on the threads that don't have the Global included. Here I use 3 threads so it looks like this:

If you have modulations between instruments that are not on the same threads, or if you try to select threads without selecting a "Multithread *" synth, Sointu should warn you.