search

utokusa / OS-251

OS-251 is a synthesizer plugin
https://onsenaudio.com/products/os251
GNU General Public License v3.0
99 stars 5 forks source link

Present presets to LV2 host #38

Open riban-bw opened 2 years ago

riban-bw commented 2 years ago

There are some preset patches available to be selected using the GUI but none of these are presented to LV2 hosts which do not (or cannot) display the GUI. It would be advantageous to expose or be able to export these presets to LV2 preset TTL.

atsushieno commented 1 year ago

I was going to record the same issue. It is not specific to LV2. image

It is all about implementing PluginProcessor::getNumPrograms() method etc. which currently look like: https://github.com/utokusa/OS-251/blob/6087700444e946510f663aa68ca86f1fd0447a0c/src/PluginProcessor.cpp#L123 Since there is already onsen::PresetManager it would be easy to implement (I'm not sure how "stable" the preset indices should be though, among system presets and user presets which may grow).

The sshot above shows the results from "Show all programs" which is useful on development.

utokusa commented 1 year ago

Thanks you for the reports. Since now I got multiple reports, let me think what I can do.

getNumPrograms() needs to return a same value for the AudioProcessor's lifetime. It might be problematic because the number of user presets can grow as @atsushieno pointed out. I'll start from see what other plugins do.

atsushieno commented 1 year ago

I was also curious on how others handle it, and surprisingly(?) not a few plugins actually do not support the feature either (Surge XT, Odin2, Vital etc.)

utokusa commented 1 year ago

Also checked several plugins I have using Reaper or AudioPluginHost:

As far as I found, only plugins which handle programs and banks in the plugin GUI handle program list. I think it's worth to support program list if it suits to OS-251's preset management model. But since it's not the case I'll leave it for now.

atsushieno commented 1 year ago

Yeah fair enough. If I find anything relevant I would share with you (it might not be here!)

riban-bw commented 1 year ago

The point of the request is that there are presets in the plugin which are not exposed to LV2. The presets accessible from the native GUI should also be accessible via any LV2 host. I guess the native presets are in some proprietary native format. There is a standard for exposing LV2 plugin presets. It may be advantageous to implement a mechanism for saving to LV2 format which would allow any presets or settings to be exported / exposed to LV2 hosts.

utokusa commented 1 year ago

Thanks for the clarify. Let me explain in a bit more details.

The point of the request is that there are presets in the plugin which are not exposed to LV2.

The factory presets are not exposed through plugin-host/DAW by design.

I guess the native presets are in some proprietary native format.

Yes, the preset files are in a proprietary format. (But OS-251 is still able to let DAWs to save the plugin state as a preset in the DAW's own format. e.g. saving a preset as 'preset.vst3' using Ableton Live and the files is possible to be managed within the DAW. This is probably not the point you are talking about though.)

There is a standard for exposing LV2 plugin presets. It may be advantageous to implement a mechanism for saving to LV2 format which would allow any presets or settings to be exported / exposed to LV2 hosts.

Yes I think I understand the merit of this. But the problem which I discussed with @atsushieno is that I use JUCE as the framework to support LV2, VST3, AU with single source course. JUCE's API has a limitation that it only can expose a static number of preset. It's very problematic considering that OS-251 has a feature to add user presets. When users add a user preset, OS-251 would not be able to expose the new plugin to the host. I could use some workaround like showing dummy preset when number of presets are small and using banks for the case where the number is large etc. But I think such workaround would lead to confusing user interface. Also I could develop LV2 without JUCE, but it would make it much harder to maintain.

atsushieno commented 1 year ago

Yes, pretty much what @utokusa wrote. Besides, there is some mismatch between numbered presets/programs (JUCE) and unordered presets (LV2). Every time I instantiate LV2 presets in my host, the order changes. Therefore I cannot reliably specify preset by index across LV2 instances of the same plugin. (Hosting is irrelevant, but I wanted to note that how different those two models are.)

I am (probably we are) not saying it is impossible to implement it. But there seems no established methodology for JUCE plugins on how to support presets that grows on both factory (plugin's) and user ends.

(LV2-only support for presets does not make sense here. It's an issue on all plugin formats.)