The brand new Camomile release (1.0.1) is available!

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.

This looks great! I will test when I have some patches ready and share with everyone.

Thank you for your work on this!

Great news Pierre!
i'll do some testin in a couple of weeks!
thanks and keep rock'n'rolling on this gem!
a.

Because my tutorial (textual) seems to be a bit confused for some MacOS users, I made a video. I'll try to make a video for Linux and Windows pretty soon but the operations are much more simpler on these OS so I guess it's not a essential.

Cheers !

New release available:
v1.0.2

• 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

New release available:
v1.0.3

• 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)

great! thank you Pierre! This is more and more becoming a milestone in Pure Data use in standard DAWs!

New release available:
v1.0.4

• 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)

Great stuff @Pierre Guillot ! thanx!

New release available:
v1.0.5

• 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

@Pierre-Guillot thanks!! great improvements!

Here's a short demo video of the last plugin I'm working on: Space VBAP - an implementation of the Vector Base Amplitude Panning for sound spatialization. It's still a work in progress but you can see some of the new features such as the dynamic graphical interface or the adaption to the input/output layouts submitted by the digital audio workstation.

I hope you'll enjoy!

Great job Pierre! I'm very interested on spatial issuess but now I'm working on a plugin modulator. I would like to ask you if current version of Camomile allows externals to be included into the plugin folder? Thanks. All the best. Gus.

@gusadel Hi Gus. Thanks! No it's not possible to load dynamically externals (compiled objects) but you can load abstractions. There are two main reasons:

• 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

Hi @Pierre-Guillot and thanks for your continuing work on this!
I argue that adding external is just a matter of incorporating them in libpd.dll. Am I right? If I am right would be great to have a tutorial on

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!

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

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.

Thanks for the info @Pierre-Guillot!
@Pierre-Guillot said:

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!

@alfonso.santimone said:

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

I'm pleased to announce the new Camomile release 1.0.6.

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

Here are two new videos:
Camomile v1.0.6 - Demo n°9 - Ping Pong effect using PdStalFx:

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

Since Mac doesn't help the development of 32-bit application (the last Xcode tools don't support it anymore), I think I will drop the 32-bit support of Camomile for MacOS in a near future, and I'll provide a 64-bit version only.

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.