LV2 version?

[unfa]

Since you're using JUCE framework, I wonder if it's possible to build an LV2 version of this plugin too?

[pierreguillot]

No sorry, Juce doesn't support LV2 and I don't think it's a priority for them. Perhaps someone did a wrapper for it I can look for it.

[pierreguillot]

I found this but I would prefer to follow the main repository of JUCE instead of a fork that could be deprecated in the future

[falkTX]

I maintain the LV2 fork. I can update to the latest juce as needed, if someone needs it. It's just a matter of doing a "git pull" and managing any merge conflicts.

[pierreguillot]

Thanks, I can try it and find a way to add the module into Camomile. Do you have a place to start? I think the LV2 support is not integrated to the projucer so what should I add for it?

[falkTX]

There is no real place to start, you have to create your own makefile or build configuration.

I was interested on adding support in Projucer at some point, but the overall disinterest from the Juce team and lately having them being quite rude against me just pushed me away from Juce completely.

[pierreguillot]

I see... I guess Linux isn't really their main interest. I'll try to deal with the makefile but I'll surely ask you some questions. Anyway, thanks for your work!

[pierreguillot]

I'm trying your Repo but when I pull the master branch of JUCE, it generates conflicts with files that, I guess, should be unrelated to the LV2 plugins (Juce_VST3Headers.h, Juce_JUCESplashScreen.cpp, ect.). Are they "extra" developments? Perhaps I should just use the LV2 files from JuceAudioPluginClient?

[falkTX]

My fork have a few changes for better linux behaviour and to remove all tracking on the IDE and plugin wrappers. So it's not just adding LV2 support. FYI the fork assumes you want to use GPL license mode.

I pull from the juce develop branch on my fork, as breaking changes are better handled (for me) as soon as possible, to reduce the big amount of changes that pile up if I wait too long.

[pierreguillot]

I managed to compile the LV2 version of Camomile with your code on MacOS. I know, it's useless: as far I know only Ardour supports the LV2 plugins on MacOS and it doesn't recommend to use them... Anyway, it means it should be pretty easily feasible on Linux. The principal changes that I made on your code was to remove the part that generates the ttl files and to support the new approach for the setup of audio channels. One of the last problems is that the Projucer overwrites the projects' configurations but I don't find a proper alternative to the Projucer...

[falkTX]

hm? who doesn't recommend to use LV2 on macOS? LV2 is actually a portable format, there is no file paths saved by the spec and the host, so it's actually the better one for compatibility. My own host Carla supports LV2 and works on macOS too. But that's the only 2 hosts I know that support it.

Are you using the latest available juce? I remember doing those kind of changes you mentioned. If you're using a slightly older version of juce, maybe you had to revert some changes. In any case, will be nice to access those so I can see if I can import them.

[pierreguillot]

hm? who doesn't recommend to use LV2 on macOS?

From the Ardour documentation.

My own host Carla supports LV2 and works on macOS too. But that's the only 2 hosts I know that support it.

That's great! I will try it :) (and there is also Mixbus but I never tried)

Are you using the latest available juce? I remember doing those kind of changes you mentioned. If you're using a slightly older version of juce, maybe you had to revert some changes.

Yes. Not the dev branch but the master. For example, you use the MACRO JucePlugin_MaxNumInputChannels but this MACRO is not defined since JUCE 5 if you don't use preferredchannelConfiguration so you should prefer to use filter->getTotalNumInputChannels().

In any case, will be nice to access those so I can see if I can import them.

The code is in the LV2 folder on the v1.0.2-lv2 branch but I'm still exploring so for the moment it's a bit dirty. But I'll keep you informed and I'll create a PR if you want.

[falkTX]

I would like to resume the talks here :) I applied the changed needed for camomile in my juce fork.

Likely I will add support to ProJucer to export LV2 too, so this can become more official.

Note: In the beginning of July I have the target to make camomile work for the MOD Duo device. My distrho-ports project allows to build juce based plugins without UI. But they need to be copied over so I can make the needed local changes (just a macro to disable some things usually). Would you be interested on these changes too? They are not very useful as-is to you, but wont break anything.

[pierreguillot]

I applied the changed needed for camomile in my juce fork.

Great ! Thanks ! The v1.0.6 is almost ready so I hope I'll publish it very soon so we can plan the LV2 support for v1.0.7 :)

Likely I will add support to ProJucer to export LV2 too, so this can become more official.

That would be great ! Anyway, for the moment I think we can already start with a "parallel" project/target (makefile/xcode/MSVC). Like there is Camomile and CamomileFx, we can create two new projects CamomileLV2 and CamomileFxLV2 that will share the code of the two previous projects. I have to read the LV2 specification again but is there any difference between LV2 instruments and LV2 effects?

Note: In the beginning of July I have the target to make camomile work for the MOD Duo device.

Another good news :).

My distrho-ports project allows to build juce based plugins without UI. But they need to be copied over so I can make the needed local changes (just a macro to disable some things usually). Would you be interested on these changes too? They are not very useful as-is to you, but wont break anything.

I guess if we start with parallel targets, we can add this feature - there won't be much more modifications. I admit I don't really see how this works and what it does. But if it simplifies your port, lets try it. And in fact I think we can even have two JUCE distribution inside the repository if we find a good way to maintain both, waiting for JUCE to officially include your work...

Thanks a lot !

[pierreguillot]

So I managed to compile an LV2 plugin (Mac & Linux). I've done a dirty implementation and I need to clean a lot of things but it works! I chose to copy your code and to create an external Juce module. This way I don't have to manage with two Juce distribution. So to compile an LV2 plugin, you have to create a dynamic library project and to include this Juce module. In the code, I changed few things:

• The files creator are placed in a 2nd source file Juce_LV2_FileCreator.cpp and use a preprocessor definition JucePlugin_Build_LV2_FileCreator. This way if you don't need it, you won't compile it.

• I placed all the files creation functions in a class with static methods.

• I removed the preprocessor definitions JucePlugin_WantsLV2TimePos, JucePlugin_WantsLV2Latency and the use of JucePlugin_WantsMidiInput and JucePlugin_ProducesMidiOutput because as Camomile enables these options dynamically, the plugin crashed. So now it's not really optimized but it works. I guess a better solution would be to re-used the preprocessor definitions at compile time but also to using the AudioProcessor method at runtime.

• I updated the code for the new parameter approach.

Do you think that using a Juce module would be a good alternative waiting an official integration ? Are you interresting in some of the changes ? Would you like me to create a PR ?

The code is located in the folder Dependencies/juce_audio_plugin_client_LV2 on the dev/v1.0.6-lv2 branch.

Cheers

[pierreguillot]

The LV2 plugin in Carla !

[falkTX]

Ok, I have to ask some questions then...

1. why separate things into a new file? more often than not, you will need it.. EDIT: I see why, you are creating the ttl files manually, without the generator. that is quite handy.

2. I understand not using JucePlugin_WantsMidiInput like macros, but some code still assumes a few things... disabling midi in/out is important, as the host should not create unnecessary ports. why remove JucePlugin_WantsLV2Latency ? just set it to 0 in your project... also, does puredata have any concept of timeline or transport? if not, just setting JucePlugin_WantsLV2TimePos to 0 in the project file is enough, I dont want the code to deviate too much.

3. what do you mean by "new parameter approach" ?

no need for PR at the moment, I will split the code of the ttl generator into its own files so it matches your idea. I can also add in some changes I already see from you that make sense. but I need to say that time-info and latency macros need to remain. they are sorta expensive for hosts to handle and so are better enabled only on request.

[pierreguillot]

Sorry, my explanation was not really clear. I won't keep the code as it. I made "hard" modifications to quickly solve the crashes. So:

1 - For the moment I still use your code but indeed, I would like to generate the file using a script to avoid too many steps. Anyway I think it's good idea to split the two parts - as they can be independents.

2 - It will put back these macros. This was just an easy/dirty fix because even if the macros is enable sometimes the plugins don't manage MIDI events (or whatever) so the ttl files are not consistent with the plugins' binaries. So I think it's better to check if the plugin manages a feature using the AudioProcessor's methods (for example: filter->producesMidi() or acceptsMidi() instead of using macros). (And, yes, Camomile manages the latency and time position).

3 - The old methods such as filter->setParameter(index, value) are deprecated. Now you should get an array of parameters filter->getParameters() and access directly the parameters.

I will now clean the code (and put back the macro). The PR was not for the full code that I made but if you want some specific changes I can create small PRs (for the parameters for example). Cheers

[falkTX]

ok, I split the LV2 code now. so you can do a PR against https://github.com/DISTRHO/juce and I will leave comments on the relevant bits.

I need to ask, does juce handle the new parameter stuff internally? Will this work for plugins made with the older API? I need to keep the current plugins working...

[pierreguillot]

I need to ask, does juce handle the new parameter stuff internally?

yes

Will this work for plugins made with the older API?

No I don't think

I need to keep the current plugins working...

Alright, I will leave this behind

[pierreguillot]

The pre-release v1.0.6-beta2 offers a first LV2 version! I close this issue and will re-open new ones for more specific problems or improvements.