I just pushed to Vangelis the changes that allow having multiple instances of the puredata engine. Woaoooo! Yes, we really deserved this! Please, update and test.
There is still a limitation with the organelle emulator, that can run only once. We hope to fix this ASAP!
@ronsum, we need to imagine a way to assign different OSC port numbers for each organelle/euclidean widget instance. From the zynthian side is trivial, but from the PD side, it’s a little bit trickier. I would like to use the ALSA MIDI port number for this. Do you think we can get this number from the organelle wrapper and use it to generate the OSC port numbers, adding it to a base port?
I seem to get the same GUI widget (Euclidean Rhythms) for all instances of PD and it doesn’t populate properly.
[Edit] Some parameters are not accessible or do not show correctly. Maybe we need a seperate topic to look at this new GUI widget because I am struggling to undertsand it. @ronsum would you like to create a topic to introduce this and give some guidance?
[Edit] Oops! I hadn’t updated fully. I see the Euclidean sequencer working now. (Much fun to be had there.) I still want to report my observations and issues somewhere.
Sure,
Create a new PD patch and add the object: [declare -path /user/lib/pd/extra/ggee]
Then add a message: [ aconnect -l (
Add the object [ shell ]
Connect the message outlet to the shell inlet.
Add a print object and attach the shell left outlet to the print inlet.
Now when you click on the message box, you should see the output of shell in the PD console showing clients and client numbers, including the Pure Data client.
The trick is figuring out how to edit the message to filter out everything so all that appears at the shell output is the PD client number. You cant use things like -d in the message because the minus sign will trigger the ALSA help menu. The shell object in PD can be quite challanging. I hope it is doable and will likely take quite a bit of experimenting. What normally works in a Unix shell may not work in the PD shell object.
Once you get the port number only, it will be easy to add it to a base number, like 41000. So if the port is 129, the OSC port number would be calculated to equal 41129 and applied to the message going to netsend.
@jofemodo, just so you know , the hard part is done. I haven’t given it a thorough test yet, so go ahead and try anyway and we’ll compare notes. Have you solved the widget portion?
Instead of using the device number, how about using the chain id? There will only be one PD instance per chain and each chain has a unique (low value) integer. Zynthian could pass the id to PD (if that helps) or save a tmp file with its content for the above procedure to be used (reading a file content, like you do for the device id). The tmp file only needs to be relevant during initialisation of the instance of PD so, if that can be atomic, you can reuse the same tmp file to deduce each instance.
[Edit] Or could we use pd -send... to set a variable during start-up? Zynthian knows the socket port number it would want to use. Presumably, PD could take this, append it to the OSC init string then loadbang it???
I’ve everything working fine, including the widget part except for the OLED display refresh when changing between patches. Is there a way to request an OLED display refresh?
If not, we could try some canvas magic.
OK! I did some canvas magic and now it works, but we still have issues with initial OLED refresh. Some geometric messages are lost because OSC ports are opened before widget is created. I think it’s not too difficult to fix, although requesting a display refresh would be super useful. Perhaps not doable due to organelle way of work.
I’ll see what I can do to get the initial OLED to refresh as soon as I get some free time. I’ve had little time to test but notice when changing patches, the OLED continues to display the closed patch.
I did some improvements to the multi-instance organelle support. Still not perfect. For instance, when restoring from snapshot , OLED display is empty until user action triggers redrawing. I have a solution in my head, but it’s not trivial. Perhaps tomorrow
Also, @ronsum, i’m thinking of implementing OSC-controllers for puredata. It would solve several limitations and increase the possibilities. Think of euclidean widget, for instance.
I just finished the multi-instance implementation for organelle widget. Now it should smoothly work in all cases, refreshing the display when loading snapshots and also when changing presets (patches).
I also implemented OSC controllers for PureData patches. This increase the control possibilities a lot. You can see a working example in audio-generative/osc_example. @ronsum , i really think you should use this for the euclidean patch. Please, note that you can also use “ticks”, so implementing selectors is now a lot better. Also note that controller syncing is bi-directional!!
I would love to test it properly, but I can’t. The aux button and encoder no longer work on my touch only Zynthian. The OSC messages from the widget are not arriving. I opened one instance of PD with an Organelle patch and looked in the OSCbuttons abstraction patch. I see it is listening on port 3010, but there are no messages arriving when touching the aux button or encoder.
I also tried to test the osc_example patch, but the sending and receiving ports are not being assigned.
Please, update and test.
