On 05/14/2013 12:04 PM, Julien Claassen wrote: That's one thing that always irks me about all these custom guis. They make accessibility a pain in the butt. I think it was Robin Gareus that mentioned to me on IRC that there might be a way in the LV2 pipeline to at least make patch_set messages generic. That would be awesome as it would make both the example sampler plugin in the LV2 distro (and my own little experimental LV2 plugin) accessible given that the host has a way to expose the patch set interface in a non-gui way (for stuff like console only lv2 hosts). Flo P.S.: Putting Dave on CC. Maybe he has some more info on the subject.. -- Florian Paul Schmidt http://fps.io

On 05/14/2013 12:26 PM, Julien Claassen wrote: Well, I'm no expert on LV2 and especially not the patch extension. But from my limited knowledge the message comes into the plugin the same way midi messages come into it (via a "notification" port?). I ripped the code for my plugin straight from the example sampler plugin from the LV2 distribution. So since it uses a gtk gui to offer the user a way to select a patch file, that's what my plugin does. These are the involved extensions afact: http://lv2plug.in/ns/ext/patch/patch.html http://lv2plug.in/ns/ext/state/ Only because you explicitly ask I will elaborate a little bit on my plugin ladspa.m.lv2 (interest was pretty limited, so I actually kind of accepted that it's a personal project interesting only to me ;D). It is a simple little modular synthesis plugin which can run synthesis graphs made up of LADSPA plugins. These synthesis graph definitions are in the form of little files describing the graph. This is the protobuf definition for the files: https://github.com/fps/ladspa.m.proto/blob/master/ladspam.proto You can use the generated python bindings to define instruments. This is an example python program that builds up the instrument definition for a simple 5-voice polyphonic instrument that has a sawtooth oscillator per voice and modulation wheel controlled autopanning per voice (where each voice uses a different panning rate): https://github.com/fps/ladspa.m.proto/blob/master/examples.py/simple_sawtoo… The plugin and the involved libraries/tools are still work in progress. But since not a single other part of this chain depends on any graphical toolkit and this is quite accessible it is a pity that the patch selection part to actually make use of an instrument in an LV2 host has this accessibility issue of requiring a custom GUI. And I would love for that to change.. https://github.com/fps/ladspa.m.lv2 Regards, Flo -- Florian Paul Schmidt http://fps.io

Hi J.! Thanks for the explanation. So that does clear it once and for all and means, that I must be careful in my choice of LV2 plugins. :-( At least it's a definite answer to what I - so inexpertly - wanted to ask in the first place. Kindly yours Julien ---------------------------------------- http://juliencoder.de/nama/music.html

Hello Hermann! In the end it almost comes down to the same point. At least from my point of view. The host might - in theory - have a go at receiving and sending such extra messages, but since they are not normed in any way, the plugin and its UI can practically do what they want. There are a couple of plugins, that load files (samplv2, zyn, I think the IR convolver,...) and they all rely on their GUIs. It seems to me, that it's mostly loading and saving of files, that is done outside the LV2 plugin ports. So in more general terms, I ask myself: why is that so? Was there no room in the specification to allow "sntadardised" transmission of strings? It's not an abnormal thing one wants to do? I think there is an LV2 version of Guitarix, is there not? Can you load files into anything or give names to something? If so, how do you do it? Warm regards Julien ---------------------------------------- http://juliencoder.de/nama/music.html

On 2013-05-14 22:58, Harry van Haaren wrote: probably referring to samplv1 ? and no, samplv1 does not make use of the lv2:filename port attribute or whatever it's called. samplv1 makes use of the evil instance-access extension and the unix sockets are there only for notification purposes--to let the gui update its waveform display or refresh when a new sample file gets loaded at the dsp side (eg. state presets). byee -- rncbc aka. Rui Nuno Capela -- rncbc aka. Rui Nuno Capela

On Tue, May 14, 2013 at 10:31 PM, hermann meyer <brummer-(a)web.de> wrote: I think Jonathan Liles was referring to the "instance access" extension, which provides direct access to the DSP from the UI. Hence no messaging, just function calls / some other nasty hack. It should not be used, for reasons like this thread, and separation of UI / DSP threads etc. It is a problem, and it does exist, and it is used by some plugins with fancy UI's and some others.

On Wed, May 15, 2013 at 2:16 AM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote: Regarding (A), expensive in terms of what? Pulling the libs for a giant GUI toolkit into my host process is expensive. Expensive in terms of communication? No. A few knobs and sliders and even a scope or eq graph are not going to present any bandwidth problems even on modest hardware. And how many plugin GUIs are you going to have open simultaneously anyway? Regarding (B), I would say it's smartly complex. Avoiding *necessary* complexity for short term gains is stupid. It doesn't *have* to be complex, either for the host or the plugin, as the plugin author is free to provide shitty hints, and the host is free to provide a shitty GUI. But what this complexity buys is robustness, stability, and guarantee that the host can see all communication with the GUI. Regarding (C), I believe it expands host options. With better hints and a complete view of plugin capabilities, the host can generate a more usable interface than the plugin author is ever likely to, and the host can do this for *all* plugins. If it's things like embedded windows that you desire, don't forget that XEMBED still works across process boundaries.