Last time I tried with libPd (last summer), I couldn't achieve the creation of a plugin that support multiple instances even using locks. I can't remember precisely of the problem but I think that the libPd implementation is not intended for this purpose. There were a lot of dead locks and when there were not, there were thread concurrencies. So I started to touch libPd files and even pd files and then I realised that it was completely unsustainable and I made my own wrapper:
There are 4 classes:
- "Pd" a class with static methods that manages all the global variables and the lock system.
- "Instance" the counterpart of the pd instance that manages a set of patches (an instance of a plugin for example) and that is thread safe except the send, midi and dsp methods because generally you want to call this methods one behind the other without locking at each call. For example:
lock();
sendNote(channel, number, velocity);
send(receiver, value);
performDsp(nsamples, ninputs, bufferin, noutputs, bufferout);
unlock();
- "Patch" the counterpart of the pd patch that manages a set of object.
- "Gui" the counterpart of the iem GUI.
There is some kind of smart pointer in the classes that avoids the deletion a patch if you are using its objects or the deletion of an instance if you are using one of its patches. And everything should be thread safe (except the functions that I noticed above) and lock free. However, I used it only for my plugin so perhaps in other contexts the approach can be improved. Anyway, the code is open and documented so you can have a look.
PS: the wrapper is in C++, I think it should be better to have a first wrapper in C and then to wrap it again in C++ like libPd.
