Camomile is a plugin with Pure Data embedded that offers to load and to control patches inside a digital audio workstation. The plugin is available in the VST2, VST3 and Audio Unit formats for Linux, Windows and MacOS. Download and information on the website: https://github.com/pierreguillot/camomile/wiki.

Read carefully the documentation. Feedback are more than welcome!
For feature request and bug report, please use the issue section on the Github repository if you can:
https://github.com/pierreguillot/camomile/issues.

An overview of the main changes:
v1.0.0

• Use libpd instead of my personal wrapper.
• Use TLS approach of Pd to manage thread concurrency issues.
• Use a text file to define the properties of the plugins.
• Generate plugins with the patches included.
• Separate the GUI and the parameters' definitions.

v1.0.1

• Fix thread concurrency issue that occurred when selecting a program (#77).
• Fix stack overflow issue due to concurrent access to the Pd's stack counter (#69).
• Update documentation for VST2/VST3/AU generation on MacOS to display the name of the plugins in Ableton (#75).
• Improve the whole documentation (#72) and start "How to Create Patches" (#73).
• Add more warning when there are extra arguments in parameters' methods.
• Add support for "openpanel" and "savepanel" methods.
• Update examples Bulgroz, AlmondOrgan, Castafiore, MiniMock.
• Start/Add support for patch description in the text file (#74).
• Start/Add support for patch credits in the text file (#74).

Further information on the previous versions and the changes on this topic.

Thank you for your work on this!

Cheers !

• Fix DSP off message to Pd
• Prepare the DSP before opening the patch (#83)
• Initialize parameters and programs before opening the patch (#82)
• Use libpd_process_raw in the DSP perform method for optimization
• Add support for MIDI In SysEx, SysRealTime & Byte
• Add support for MIDI Out Byte
• Add full support for keys objects [key], [keyup] (#80)
• Add partial support for key objects[keyname] (perhaps some names are still missing names are missing)
• Improve the console (resizable)
• Improve prints for lists (remove line breaks)
• Floating Window always on top
• Floating Window with tabs (Console/Patch/Camomile)
• Display patch description
• Add support for compatibility versions (plugin's version of the patch <= plugin's version used)
• Add support for block size inferior to 64 samples (implies delay)
• Add support for non-real time processing
• Improve name of the UI Window
• Fix the FFT objects for multithreading support

• Fix DSP support for multiple audio buses
• Fix the number of channels in the messages sent to the patch
• Remove the name of the channels configuration in the messages sent to the patch (not coherent)
• Add buses information in the messages sent to the patch
• Add warning when the plugin code or the plugin type is not defined
• Fix the position of the popup menu for console level (#90)
• Add support when plugin is muted or not playing (#78)
• Fix missing library on Linux (#89)
• Add support for extra data to save and reload with the plugin's state (#91)

• Add label support for GUI objects (#95)
• Add graphical array support for GUI array objects (graph) (#93)
• Add window array support for array define objects (#93)
• Add steady/jump mode for IEM's GUI slider
• Add log scale for IEM's GUI slider (#96)
• Add instructions for contributions
• Add the facultative flag "-s" to openpanel/savepanel methods to suspend processing
• Add warning if no audio bus is defined
• Fix the width of the comment
• Fix the incrementation of the number box and the atom number
• Add support to change dynamically the graphical interface (#99)
• Add support to change dynamically the latency (#62)
• Fix variable block size support (#100)
• Improve MIDI In/Out time precision
• Add support for manually and automatic dynamic reload of the patch (#101)
• Add support for abstractions/sub-patches GraphOnParent (#102)
• Fix midi pitch bend offset due to +8192 from libpd (#104)
• Remove libpd.dll dependency to the Windows versions (#94)

• Fix warnings when audio buses are not well configured
• Fix MIDI out issue when block size is superior to 64 samples (#107)
• Improve multibus support for multichannel & side-chain - experimental with iolayout (#110)
• Add support for autoprogram to disable parameters recording within programs
• Add program updated method to notify the host that internal state has changed
• Fix plugin format recognition VST/VST3/AU
• Improve online documentation & remove locale documentation
• Add plugin's state management for dynamic reloading
• Improve background image resizing and positioning

I hope you'll enjoy!

• I don't know if it's the DAW or if it's the APIs of the plugins but the dynamic loading of libraries is restricted. There are ways to get round this problem but it's a bit tricky.
• Most of the externals objects don't have the multi-instance support so you have to re-compile the object with the multi-instance.

A solution would be to include some external libraries directly in Camomile but I'm still a bit afraid of the durability of such approach. Furthermore, depending on the library it could requires a lot of developpement and I'm already pretty busy with the basic functionnalities and the support for the several formats and operating systems.

But if anybody would like to work on some kind of Camomile-extended, I'll be pleased to help him!

Cheers

1. Making multiinstance support into an existing external or external library
2. How's to make it compatible and build for all the platforms (Win64, Win32, osx, Linux)
3. How to include them in libpd.dll and Camomile.

I guess every Camomile users can try to include the externals and external libraries they need.
Given the modular nature of pd I think this is essential for Camomile.
Thanks!

I argue that adding external is just a matter of incorporating them in libpd.dll. Am I right?

Yes but the libpd used by Camomile is the static library (.lib/.so/.a) that why libpd is embedded in Camomile.

1. In fact, I guess that some of the external libraries are already compatible with multiinstance support because it depends on what parts of the Pd API the libraries use. But to ensure the multiinstance support you must use the C flags -DPDINSTANCE=1 (and -DPDTHREAD=1) while compiling the library or libpd and avoid all the static variables (except if they use thread local storage and you ensure to init them well on each thread). Here is one of the 1st posts by Miller about it: https://lists.puredata.info/pipermail/pd-dev/2017-04/020980.html

2. The same way you did it for the "standard" approach.

3. Including an external library with libpd is pretty straightforward (as long as, in this case, the library has the multiinstance support). See this: https://github.com/libpd/libpd/wiki/Adding-Pure-Data-external-libraries-to-your-project. And if a library is included in libpd it will also be included in Camomile.

So you also have to compile libpd then Camomile (all the instructions are on the Github repository - I updated it a week ago https://github.com/pierreguillot/Camomile/tree/dev/v1.0.6-lv2#compilation - or just do the same steps as on Travis and Appveyor and I can help if needed).

Cheers

PS: Another approach would have been to ship the libpd dynamic library next to each plugin. i need to try this but I afraid that, on Windows and Linux, the DAW think that the libpd library is another plugin try to load it.

Hi @alfonso.santimone

I argue that adding external is just a matter of incorporating them in libpd.dll. Am I right?

Yes but the libpd used by Camomile is the static library (.lib/.so/.a) that why libpd is embedded in Camomile.

1. In fact, I guess that some of the external libraries are already compatible with multiinstance support because it depends on what parts of the Pd API the libraries use. But to ensure the multiinstance support you must use the C flags -DPDINSTANCE=1 (and -DPDTHREAD=1) while compiling the library or libpd and avoid all the static variables (except if they use thread local storage and you ensure to init them well on each thread). Here is one of the 1st posts by Miller about it: https://lists.puredata.info/pipermail/pd-dev/2017-04/020980.html

So i guess i have to remove directly from the external code all the static variable, so basically remove the "static" keyword from the variable declarations.
How can i compile libpd as a .lib/.so/.a and not .dll?
Should i use those flags in the various makefiles or just as a fleg in the command line? (assuming working with msys2 on Win64)

2. The same way you did it for the "standard" approach.

So it's enough to use a x64 compiler and a x64 target?

3. Including an external library with libpd is pretty straightforward (as long as, in this case, the library has the multiinstance support). See this: https://github.com/libpd/libpd/wiki/Adding-Pure-Data-external-libraries-to-your-project. And if a library is included in libpd it will also be included in Camomile.

So you also have to compile libpd then Camomile (all the instructions are on the Github repository - I updated it a week ago https://github.com/pierreguillot/Camomile/tree/dev/v1.0.6-lv2#compilation - or just do the same steps as on Travis and Appveyor and I can help if needed).

Cheers

I don't really know what Travis and Appeveyor are. I have to check them out.
How to include the static pthread lib for Win compilation? You mention it the Camomile build process readme.

PS: Another approach would have been to ship the libpd dynamic library next to each plugin. i need to try this but I afraid that, on Windows and Linux, the DAW think that the libpd library is another plugin try to load it.

I guess that most hosts have an avoid list for specific .dll. At least Reaper have a config file where is possible to remove a specific .dll from being scanned as a plugin.

thanks!

So i guess i have to remove directly from the external code all the static variable, so basically remove the "static" keyword from the variable declarations.

No, if there are static variables (except the static variable for the class that is managed by Pd) you must find a way to avoid them. For example you can use variables in your object structure.

How can i compile libpd as a .lib/.so/.a and not .dll?

The libpd version in the Camomile repository generates the static library. You only need to follow the instructions.

Should i use those flags in the various makefiles or just as a fleg in the command line? (assuming working with msys2 on Win64)

If you include the external sources to libpd, you should not have to use the makefiles and the right flags will already be defined.

So it's enough to use a x64 compiler and a x64 target?

For the 64 bit target yes.

How to include the static pthread lib for Win compilation? You mention it the Camomile build process readme.

You have to compile it. There are several way to do it so I don't want to impose one way to do it but you can have a look at the Appveyor file https://github.com/pierreguillot/Camomile/blob/dev/v1.0.6-lv2/appveyor.yml or in the Camomile directory do

git clone -q https://github.com/GerHobbelt/pthread-win32.git Dependencies\PthreadWin32
cd Dependencies\PthreadWin32
sed -i 's/4820;4668;4255;/4820;4668;4255;4711;4100;4312;4127;4296;4456;4619;4310;4311;/' pthread_lib.2015.vcxproj
sed -i 's/MultiThreadedDLL/MultiThreaded/' pthread_lib.2015.vcxproj
sed -i 's/MultiThreadedDebugDLL/MultiThreadedDebug/' pthread_lib.2015.vcxproj
msbuild pthread.2015.sln /t:pthread_lib /nologo /verbosity:quiet /p:Configuration=Release /p:Platform=%PLATFORM% /p:OutDir=lib

This new version includes several great new features:

• Add support for the LV2 format thanks to the work of Filipe Coelho that created an interface for the LV2 format with JUCE.
• Add a new plugin example PdStalFx that allows to dynamically load patches. It can be used in a similar way to the first Camomile versions (v0.0.1 to v0.0.7).
• Add support for naming the audio buses, so you can name the first bus "MainBus" and the second bus "SideChain", for example.
• Add script for Linux and MacOS that speeds up and facilitates the generation of the plugins.

And many other improvements and bug fixes:

• Fix MIDI channels correlation between Pd (0-15) and Juce (1-16)
• Fix buses with no-channels (for Debug mode only)
• Improve console for concurrent access
• Remove LibWebKit on Linux plugin for better Ardour and Carla Support (#116)
• Fix text ellipsis of the number boxes and the symbol box
• Add support for bypass parameter/manual bypass in the patch (#108)
• Fix param.get abstraction for the first value (using a default value)
• Improve the IEM/atom GUIS label rendering (#118)
• Fix invisible comments in subpatches and abstractions (#120)
• Improve font size rendering
• Add Fuzzy tests using pluginval on the Travis CI
• Fix the margins of the main patch

I hope you will like this new release! As always, feel free to give feedback, to submit bugs and to request new features!

I would like to thanks all the people that helped me for the development and especially Filipe Coelho and Alfonso Santimone! Thanks for your help!

Few words about the support for external libraries as this feature is highly requested. I didn't forget but for the moment I don't have any solution that seems usable and sustainable. You can read this discussion for further information: https://forum.pdpatchrepo.info/topic/11242/camomile-v1-0-1-an-audio-plugin-with-pure-data-embedded/13.

And few words on the future of project. I will continue this project but, for many reasons (that are good news), I will unfortunately have less time to work on it after this summer. That's why I tried to document the project and to simplify the compilation process. If anybody wants to join me on the Camomile development, it would be great and I'll be really pleased to help for this.

Cheers,
Pierre

Camomile v1.0.6 - Demo n°10 - Using the script to generate the plugins on MacOS:

Would it be a problem for someone?
Is there anybody using a 32-bit DAW on MacOS?
In this case perhaps I will split in two separate releases like for Windows. Let me know what you think and if you have any suggestion.

Thanks a lot!

Pierre

And as it seems that you use a Windows system, you will encounter the bug 131. I recommend you to use the beta release. Here is the last ones for Windows64 and for Windows32. At last, using your patch with the plugin PdStal just reveals a new bug - it seems there is a conflict with this example.I will fix this for the next release.