Using external Pd objects

[pierreguillot]

The question of using externals Pd objects has been discussed many times in many threads. The problem is a bit technical but, roughly, most of the Pd externals are not compatible with multi-thread and multi-instance approach necessary for Camomile (and enabling these options while compiling is not always enough) and the most of the DAW seem to block the dynamic link with external libraries (even if the linking symbols are exposed by the Camomile, the Pd object cannot find them). Here are some links, if you want to explore further the subject:

• Issue 138
• Forum
• Mail List

Fortunately, since the v1.0.8 beta, there is a workaround based on the use of the [pd~] object. Proper documentation on how to use the [pd~] object in Pd would be necessary but it's no more complicated than using the object in the Pd application. As Camomile users seem to already integrate the object in their plugins, they are welcome to contribute to the Wiki pages and/or to share their experience here. Of course, users that encounter issues or have questions and remark are also welcomed to post here :)

[alfonso73]

I'll try to do some test comparing "plain" pd patches and [pd~ ] based patches.
What worries me a little bit is latency introduced by [pd~ ]. But i'll see making some simple tests.
The [pd~ ] solution seems really promising (but i "secretly" still think that a solution like the one proposed by Camomile+ELSE here https://github.com/emviveros/Camomile-ELSE could be more "solid").
Given that there is some great work on your side @pierreguillot on making a CMake version of Camomile probably compiling externals with Camomile will be easier in the future, given that externals follows "modern" requirements about multi-threading and multi-instance.

[pierreguillot]

What worries me a little bit is latency introduced by [pd~ ].

I think that if you use the same block size, there should not be any latency introduced by the [pd~] object. But this must be confirmed, asking on the mailing list should give an answer :)

And if there is latency introduced, using the latency should fix the problem (except for real-time processing of course)

[alfonso73]

Would be great to have a simple synth and a simple fx as Camomile VST3s using [pd~ ] as examples.
I'll have to check to if inside [pd~ ] ir is possible to use [block~ 1] to make 1 sample based processes.

[pierreguillot]

As I suggested on this other discussion, a great place for examples would be the wiki! I'm pretty busy but I'll try to start with something simple, perhaps the patch that I made for the video of v1.0.8 beta4?

[pierreguillot]

Here is a very basic plugin example named Playground that shows how to launch and run a Pd patch with the object [pd~] using Pd binaries embedded with the plugin (this way the final user doesn't have to install the binaries and the plugin is portable). This version is for MacOS but a similar approach can be used for Linux or Windows by replacing the Pd binaries with the corresponding ones of these OS and the path to them.

The main patch dynamically loads the abstraction [subprocess~] into the sub-patch [pd worker] using the absolute path to the plugin folder as the argument (generated using the object [pdcontrol]).

The abstraction [subprocess~] contains the object [pd~] with the path to the Pd binaries specified by the argument of the patch and the objects [adc~] and [dac~] that forwards and receives the audio signals to and from the inputs and outputs of the object [pd~].

The state message is controlled from the interface of the main patch to start the [pd~] subprocess and open the default patch patch.pd or to close the [pd~] subprocess. If there is no necessity to show and edit the patches of the subprocess (if the use of the [pd~] subprocess is mainly to support externals for example), you can use the option -nogui (see the help patch of the object [pd~]).

If you want to use externals, you can simply ship these externals with the plugin.

[micheldejoode]

Cool! I will test this soon!

[micheldejoode]

Hi, I've tested Playground on Windows 10, but got an error in the console:
can't stat c:Program FilesSteinbergVstPluginsPlayground\Pd-0.50-2.app\Contents\Resources\pd.exe.
It seems the backslashes from the beginning of the path are gone. Any idea how to solve this? I have updated the binairies to windows.
I've attached a working patch I've made for the ~pd object on Windows, it depends on the installed Pure Data, so no portable version.
PdSub.zip

[jyg]

@micheldejoode
On windows / camomile / pdlib, backslash caracters delivered by pdcontrol are escaped in the message box that should process the data after.
Furthermore, the path to portable pd.exe may be different as with osX.
You should check my plugin http://s184785159.onlinehome.fr/website/wordpress/en/audio-over-osc/
or use the following abstraction after pdcontrol to filter & replace backslashes when they are not placed before space .
replace_backslashes_by_slashes.pd.zip

[micheldejoode]

Ok thanks, I will look into it!

[piedagile]

HI!
Currenly working on new plugin that needs an xy pad, and I found this: https://forum.pdpatchrepo.info/topic/10841/vanilla-xy-drag-widget-no-mouse-external-required.
I have begin to build the Camomile conformant patch, and the xydrag subpatch works pretty well with the MacIntosh pd.app. Of course, in the audio plugin built with Camomille the crosshair and the pad position do not appear because Vanilla does not manage this kind of data structure.
Do you think that if am patient a future version of Camomille will make this possible? If yes I should be encouraged to continue to develop the entire patch on Mac (a big work) and then export to plugin. Thanks for your advice. I'm not in a hurry.

[pierreguillot]

@piedagile I still don't have Logic so I can't test...

The help of pd~ says:

ATTENTION: DSP must be running in this process for the sub-process to run. This is because its clock is slaved to audio I/O it gets from us!

It means that the patch should receive DSP ticks, perhaps when playback is off, Logic doesn't call the process method of the plugins so the patch doesn't receive the DSP ticks and so the subprocess is not working.

In Reaper, there is an option to control if the audio is still running even if the playback is off, perhaps there is the same option in Logic?

[piedagile]

I haven't found such an option in Logic, but it seems that audio stops in not running audio tracks, but remains active on MIDI tracks (I think it is because MIDI notes from an external keyboard are played) But I don't know Logic"s internals...
If you want, you can suggest tests that I could perform and keep you informed.

I also try Camomile+ELSE for the moment because the slider2D.pd seems exactly what I need. But it is not visible in Camomile 1.0.7 . I also detected a posssible problem of Graph on parent even with Pd powered by Macos. Reported in Camomie-ELSE : emviveros/Camomile-ELSE#13

Anyway, Camomile already meets 90% of my need because I could rewrite entirely the plugin in Pd, apart the xy pad that provisionaly I replace by a remote Max pictslider connected with MIDI ctl

[piedagile]

Sorry: the option exists in Logic by pressing the (i) button of any audio track header. Good.
The subsequent question is now to found a mean to make the subprocess patch appear inside the plugin Camomile window through a graph-on-parent (maybe same problem as with Camomile-ELSE)

[designerfuzzi]

in VST-AU speak an audio unit should never be turned off from inside the unit itself. Because if turned off it may fail unit testing when a DAW starts up. It is another question if Camomile is able to turn off patches for reasons of workflow.
By dropping i.e. Camomile into your DAWS signal chain you already expresses you want to use it with DSP=1. There is no technical reason why DSP should be turned off in an Audio Unit unless you may use the feature for development. In LibPD on iOS in example you adopt the running sample rate of the device and possibe sample rate of a connected device by re-establishing the buffer with the according methods of libPD.

I hope i am not to far out in this discussion..
but introducing a manual DSP switch into a VST/AU it is kinda saying "do not use Camomile" specially because from inside the plugin you have less control if the processes DSP is really running or not as seen in the video.

[pierreguillot]

The plugin doesn't turn off the audio, the DAW controls the audio status. The problem was that the plugin was bypassed by the DAW, not directly related to Camomile, but Pd expects the audio to be activated to run sub-processes with pd~. The toggle in the patch turns on or off the sub-process, which is different from controlling the audio status of the patch or the plugin.