[PD] [PD-announce] Camomile v1.0.8-beta

[Pierre Guillot]

In a patching perspective, [pd~] object works like a subpatch so there
should not be any multi-threading or multi-instance issue. If you create a
plugin, you should create the UI in the main patch and forward the relevant
messages to the [pd~] object.

If you would like to distribute the plugin, you might want to install in a
specific path the Pd binaries that will be used by the [pd~] object, this
way you simply have to hardcode the [pd~] arguments with the installation
path. But as suggested by IOhannes, you can also use the [pdcontrol] object
to get the path of the patch and then keep the plugin library and the Pd
binaries next to each other (this might require to generate dynamically the
[pd~] object by scripting) , so you'll can simply distribute a self
contained bundle.

At this time, using [pd~] to load externals seems to be the most convenient
solution because, there is no need to compile another version of Camomile
but most of all, the code of the externals doesn't require any adaptation
for multi-instance and multi-threading (as PDINSTANCE might not be the only
change to do - for instance, if a object uses a static global t_symbol that
is not defined per thread).

At last, even if an object is compiled with the multi-threading and
multi-instance support, it doesn't seem possible to simply ship the object
library next to the patch, at least I never managed to do it because of
some unresolved symbols that I think are due to way the DAWs load the
plugin and export its internal symbols.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210113/e78e8fae/attachment.html>