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.

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.

Hi @Pierre-Guillot,
thanks for your work! I'm using it for my masters thesis in Sound Design.
But I have difficulties with the openpanel object and I can't find help in your documentary. I get the PD vst to open the panel and choose a file. But it doesn't let me do anything with it. In my patch it is processed with soundfiler and played back with [tabread4]. Can somebody help how to do this in the vst?

Thanks a lot!

@Schorschua-Phrosch There are two known issues with the openpanel method of Camomile v1.0.6 (131 and 137). The fixes are ready and will be present in the next release. If you think that your problem is related I can give you a beta release for your OS. Otherwise, fell free to report the bug on Github.
Cheers,

Pierre

@Pierre-Guillot thanks for the reply, I spent the last two days on the issue I looked up the reported issues but for me it doesn't seem to be the same thing. Maybe I am just not seeing something here. Before I make a bug report; Maybe there is just something wrong with my code? ?openpanel.pd

@Schorschua-Phrosch Yes, indeed. You have to use [receive openpanel] (and not [receive camomile]) to receive the file path. Here is the documentation. And here is a fixed version: Openpanel.pd.

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.

Hi @Pierre-Guillot. Thanks for everything. Unfortunately it still doesnt work on my computer although I tried everything back and forth. I made a bug report. Maybe that shows the problem clearer?
Cheers