i digged into the code of Pierre Guillot Camomile project and tried to add some features. Here is a demo example
(vst linux only)
EDIT : download link updated
Camomile with editable labels / guis and xy-slider
Camomile is great, and any new development is encouraging.
I put your .so file in my local folder and both Carla and Ardour load the vst plugin successfully, but the plugin display only shows "Plugin Not Valid".
Does your fork use different dependencies? I'm using Debian 10 w/the KXStudio repositories...
I don't know...
I'm testing on Reaper 64 for linux. lubuntu 18.04.4. LTS
I cloned the camomil repo, I added vst2.x headers, I reconfigured with projucer for targetting vst2 (native) target, that's all....
Maybe removing image line in TestCamomile1.0.7.txt ?
Yeah, thanks -- it looks like my system isn't setup to compile VSTs correctly. Before I moved to Debian I was using Ubuntu Studio, and was never able to compile Camomile correctly there, but the 0.0.6 binary files (basically the contents of the Plugins folder) were available instead -- and that install does fine with LV2 plugins.
When I looked at the vst files from my own plugins, they also show "plugin not valid" on load (but they don't crash anything).
So I removed the .so file from your zip (and the bkgnd image ref), generated an LV2 and that works fine in Carla:
So yeah! Most of the features in vanilla work really well in Camomile, including those display hooks. Actually, one of the first plugins I wrote was to simply package the "extra" reverb patch, [rev3~] :
One more thing -- thanks to your git fork (and the more detailed instructions in Pierre Guillot's 0.0.7 src), I was able to compile Camomile and all the submodules correctly today. VSTs still won't compile, but I feel much farther along!
@gmoon Great to know it works. Still to be fixed : number2 boxes.
Another cons of that fork is that I had to modify the source code of pd (and thus libpd) and Pierre Guillot cannot accept such a pull request on his project (what I can now understand after discuting with him). So it cannot be integrated this way into the main Camomile package, which means it needs to be compiled independently of official Camomile releases. And I cannot compile plugins for Windows or OSX.
@jyg I can live with LV2, but it would be very cool have the ability to cross-compile to other OSs, for sure. So I don't know if my VST issues are related to the header files, to JUCE or just to a mis-step somewhere in the process.
Thank you for your efforts -- no disrespect to Mr Guillot (who deserves massive cred), but haven't been any new releases for a while. And that may not be significant at all (but several PD related projects have gone fallow the last couple years)...
Off-topic question 2: how to load native VST inside PD? I tried using vstplugin~ with this plugin: https://github.com/antanasbruzas/abNinjam but no luck.
I don't get it, on linux you have also the ability to compile native VST plugin (not using Wine LinVST or Airwave at all)?
If yes, vstplugin~ is not suited for that type of native vst plugin?
@EEight I dunno. Some plugins don't play well with others. Ardour, for instance, blacklists several plugins on my system for a variety of reasons (buffer size, etc). Have you tried a different plugin host (like Carla)?
Edit: But yes, vstplugin~ is for native plugins.
I've got 319 VST2 native plugins on my system, all installed via repositories. None of those use emulation.
@jyg OK, fixed my Camomile -> VST problem.
The build process doesn't put the vst shared obj file into the folder with the resources. The Camomile docs say to copy the vst build folder to the vst path (I use ~/.vst), but the object file isn't in that folder; it's in the build parent folder. The docs also show the vst as a .lib file, but that's not quite right...
I was assuming the file structure should be copied to ~/.vst, as-is. But instead I copied the .so into the resource folder and that into ~/.vst. Success !
So your VST example "TestCamomile0.0.7" works fine -- I broke it, trying to replicate the build structure I see here.
FYI, I just changed the code, with a version that doesn't modify the pd-core. It's a bit more tricky on the patching level, but this way the pull request has more chances to be accepted.
I can verify --