multithreading

[23fx23]

well its prob far above my current skills for now, but just curious if multithreading / spead different computations on different cores is possible and would worth trying

[sm_jamieson]

There's no reason why you cannot create C++ threads using the std::thread class.

The other interesting thing that you can do on Windows with user modules is to share data between instances of the module since the DLL will only be loaded once. If you have static class data then all instances of the module can access it. Then you need thread mutexes to control access to the data by the modules, which may be different threads (if in different racks).
You can also use this to have the modules talk to each other without using Usine parameters / IML or any other inter-process communication methods.

I've not tried by I would expect the same to happen on the MAC.

I have a midi preset browser module that reads in it's config data in the first module that opens, then any other browsers share the data, which reduces memory usage.

[23fx23]

ok thanks for the infos i will try investigating those possibilities

[oli_lab]

Ho ! this is interesting indeed !
do you mean we could record on one instance of a module and play it on as many as we want on other instances of the same module ?

[sm_jamieson]

Ho ! this is interesting indeed !
do you mean we could record on one instance of a module and play it on as many as we want on other instances of the same module ?

Definitely, at least on Windows. I do not have a MAC to try it.
I think the idea of interacting modules is very interesting.

Before developing some serious stuff using this, it might be good to ask Senso about it and make sure it is not a feature that will disappear at some time.

[23fx23]

well its prob more complex than that but im trying the following:

(its basically a multi timbral synth), for now every sounds are rendered like this:

//-------------------------------
void BEZIER_MULTI::RENDER_SND_BLOC(int snd)
{
//computes bloc samples for snd
}
//--------------------------------------
void BEZIER_MULTI::onProcess()
{
for (int snd = 0; snd < SOUNDS_MAX; snd++)
{
memset(PTR_SOUND[snd], 0, GLOBAL.BLOCBYTESSIZE);
RENDER_SND_BLOC(snd);
}
}//end process
//-----------------------------

so id like to make a thread per sound, but when i try to replace the loop with

std::thread t0(RENDER_SOUND_BLOC, 0);

it won't compile saying : 'RENDER_SOUND_BLOC' identifier not declared. any basic exemple on how could trigg multiple threads in onProcess?

[sm_jamieson]

You need to specify the class, and also pass the object pointer, like this:

std::thread t0( & BEZIER_MULTI::RENDER_SOUND_BLOC, this, 0);

Simon.

[23fx23]

mm i still get the error arf

[23fx23]

mm ok that seem to works on the simple audio exemple thanks! , now i have i have to find why it doesn't in my code ehe

[oli_lab]

Hi 23fx23
very interesting indeed, but not sure it is viable if we want more than one instance of your multitimbral synth.

slightly OT :

The "policy" I tried to set up is a modular approach : for poly synth I'd use a poly subpatch with a mono synth and connect it to the module "polymux" I did. the polymux works as in an 80's hardware analog poly synth, distributing in a circular way the midi notes to the mono synths. This way I can build, modify many different synth from this polymux module, and anyone else can as well.
As for sample readers, I did a looper that record 1 loop then make it available on as much as 64 outputs, each with its own markers and pitch controls.

I can send you the module pack, before official release"

si vous n'êtes pas un robot, vous pouvez nous écrire à l'adresse gmail.com suivante :

olilab101

[23fx23]

yeee it working ok now! just with a very basic thread split reduced cpu by at least 40 percent , i should be able to track deeper stuff to be more splitted..
quicly tried 2 modules instances that didn't seem to raise problems (anyway its way to much cpu demanding in its current state for 3 instances, i put a 6950x on knee^^ lol)

yeah oli good catch on the modular split into more basic primitives idea. when i started this one it couldn't fit for several reasons but ill probably try that way in future and
ill definitely be wanting to check your approach about that, gonna send ya a mail

[23fx23]

an interesting issue i hadn't espected tho, a call to rand() made by each trheads makes it doesn't randomize anymore

[sm_jamieson]

an interesting issue i hadn't espected tho, a call to rand() made by each trheads makes it doesn't randomize anymore

rand is not thead-safe, so different threads will interfere and stop it working properly. Also it probably needs a different seed for each thread.

If you have any of the ..._r functions they should be used, e.g. drand48_r.

I've not checked what thread-safe functions are available in Visual Studio if you are using that.

There is a new "random" class in c++11 which looks quite complicated, this is an example used from the web:
#include <random>
#include <iostream>

int main() {
std::random_device rd;
std::mt19937 mt(rd());
std::uniform_real_distribution<double> dist(1.0, 10.0);

for (int i=0; i<16; ++i)
std::cout << dist(mt) << "n";
}

Simon.

[23fx23]

cool thanks a lot! gonna check that