Sneak Preview: LV2 Create

[male]

FTR, I would also be interested in knowing what LV2 (FX) plugins people think they can't do without. I use zero LV2 plugins in my own work and don't find it to be the slightest hinderance.

I like using lv2 plugins for their guis because I feel much more comfortable with visual feedback, especially seeing graphical EQs and compressor graphs.

I assume you're referring to the Calf plugins then. Well, I can't use logic against feelings. All I can say is that the the utility of such displays is as questionable as their accuracy is suspect . I'd just like to note that there's no reason that a host couldn't provide such an interface for a ladspa plugin automatically if given the appropriate hints--without suffering from the integration and usability issues that plugin-provided GUIs entail.

[falken]

@ssj71: thanks, ya, it seems I understood the modularity already from many forum posts here, its OK

@male: I completly agree that host-generated UI is perfect, having good metadata/discoverability from plugin (not knowing details); only pro-engineers out of this nice little linux things often want really overloaded graphics, driven by marketing and fruities

PEtr

[tatch]

I assume you're referring to the Calf plugins then. Well, I can't use logic against feelings. All I can say is that the the utility of such displays is as questionable as their accuracy is suspect .

I've actually wondered about the accuracy of the calf analyzer because its behavior seems a little strange, but the spectrum is useful as it is and better than *ahem* nothing. The calf compressor graph is accurate enough for me (it'd be even better if it provided a fabfilter-or-ableton-type graph). The calf EQ (and also eq10q, disappointingly) doesn't have a builtin analyzer that you can look to EQ off, but the way the knobs and buttons are organized is much more intuitive than most host-generated UIs I've seen (especially eq10q), and having the EQ laid out visually like that is helpful even without a builtin analyzer.

Also, if you mean to suggest that such graphical feedback is actually irrelevant and you "only need audio to edit audio", I disagree with you. For example, do you only need your eyes to accurately color correct video footage and stills? (The answer is no. Many editors use vectorgraphs that detail color information in the frame. Without that visual feedback it would take much longer to color correct as accurately as with it.) Try to find one relevant OS X/Windows DAW with a builtin EQ/compressor that does not offer some sort of visual information or frequency spectrum. The reason for that is not "because they want to smear their branding on everything", it's because visual feedback can be incredibly helpful and often time-saving. Here's a video demonstrating a very common scenario that would be much more difficult without being able to see a frequency spectrum.

I'd just like to note that there's no reason that a host couldn't provide such an interface for a ladspa plugin automatically if given the appropriate hints--without suffering from the integration and usability issues that plugin-provided GUIs entail.

I've seen people discussing this idea and I am entirely receptive to that possibility. But as far as I am aware it is still only talk; there are no hosts that currently do that and furthermore no plugins that try to. In the meanwhile, instead of waiting 3 years for that to happen and using feedback-deprived LADSPA plugins until then, I prefer the current LV2 offerings, even if they are lacking.

[male]

I assume you're referring to the Calf plugins then. Well, I can't use logic against feelings. All I can say is that the the utility of such displays is as questionable as their accuracy is suspect .

I've actually wondered about the accuracy of the calf analyzer because its behavior seems a little strange, but the spectrum is useful as it is and better than *ahem* nothing. The calf compressor graph is accurate enough for me (it'd be even better if it provided a fabfilter-or-ableton-type graph). The calf EQ (and also eq10q, disappointingly) doesn't have a builtin analyzer that you can look to EQ off, but the way the knobs and buttons are organized is much more intuitive than most host-generated UIs I've seen (especially eq10q), and having the EQ laid out visually like that is helpful even without a builtin analyzer.

Layout is poor because hints are lacking. This is more room for improvement in the plugin API--not the plugins themselves. I think plugin authors would be happy to do anything that would allow hosts to provide a better interface.

Also, if you mean to suggest that such graphical feedback is actually irrelevant and you "only need audio to edit audio", I disagree with you. For example, do you only need your eyes to accurately color correct video footage and stills? (The answer is no. Many editors use vectorgraphs that detail color information in the frame. Without that visual feedback it would take much longer to color correct as accurately as with it.) Try to find one relevant OS X/Windows DAW with a builtin EQ/compressor that does not offer some sort of visual information or frequency spectrum. The reason for that is not "because they want to smear their branding on everything", it's because visual feedback can be incredibly helpful and often time-saving. Here's a video demonstrating a very common scenario that would be much more difficult without being able to see a frequency spectrum.

There are plenty of tools to do this. I use Fons' jaaa a lot myself. But FWIW, I never look at histograms when editing photos and I only look at frequency plots when testing DSP code, not when actually making music or mixing. I'd think this would be true of anyone without severe hearing (or vision) loss. If you're tweaking things that no one can hear or see, you're just killing time. A justification by the relevance of anything on OS X/Windows is by its nature flawed. Free software doesn't (shouldn't) suffer from the same perverted incentives that cause things to be the way they are on those platforms.

I'd just like to note that there's no reason that a host couldn't provide such an interface for a ladspa plugin automatically if given the appropriate hints--without suffering from the integration and usability issues that plugin-provided GUIs entail.

I've seen people discussing this idea and I am entirely receptive to that possibility. But as far as I am aware it is still only talk; there are no hosts that currently do that and furthermore no plugins that try to. In the meanwhile, instead of waiting 3 years for that to happen and using feedback-deprived LADSPA plugins until then, I prefer the current LV2 offerings, even if they are lacking.

Well, that's not entirely true... Some plugins do try, but there's nothing in the standard about it and the way they have tried has been in several ways inadequate (the CAPS plugins suite, for example, uses a non-standard method of hinting at named control port groups). Obviously a host can't auto generate a GUI for anything, but the most common wants of a graphical EQ or compressor curve are well within the realm of possibility.

[tramp]

Layout is poor because hints are lacking. This is more room for improvement in the plugin API--not the plugins themselves. I think plugin authors would be happy to do anything that would allow hosts to provide a better interface.

That is exactly one of the reasons pro LV2,
http://lv2plug.in/wiki/WhyLV2

While LADSPA has been quite successful with many plugins and hosts, it is quite limited and can't be extended without breaking existing implementations. LV2 in contrast is designed with extensibility in mind right from the start. Instead of a monolithic design that can only be improved by a central authority, new functionality (an "extension") can be added to LV2 by anyone, making distributed development of the plugin API itself possible.

Truly the open design leads to some obscure Extensions which makes live in the long term difficult, but that the way it is.
LV2 comes right now with a couple more of useful hint possibility, which allow host authors to skip support for Plug-in owns GUI's and provide usable internal UI's.

Have a look at MOD-host for example, which only provide internal (remote) UI's and use only LV2 plugs.
http://portalmod.com/en/index.html

[tramp]

LV2 being extensible is very cool, but it doesn't always work.
Most plugins and hosts will only implement "official" extensions, and getting a random extension being accepted "officially" means you have to come with agreement with drobilla.

Well, but have you ever try to extent the LADSPA API ? It is simply impossible to get any extension into "official".

I made a custom lv2 extension myself because I felt something was missing, that is, plugin-side MIDI programs.
DSSI has it, VST has it, AU has it, my own (Carla) internal API has it too, and I believe it makes sense for LV2.
Currently the only code outside of my own that implements this custom extension is Qtractor, everyone else seems to be afraid to be a black sheep by using it or something...

So, even if someone designed an API for host-generated UIs, I worry it will be ignored for:
1. not being "official"
2. not doing things the lv2-way (using turtle mess)
3. disagreements on the API design

I guess most of the trouble about custom extensions exist because they didn't take care of the host implementation. That means, any plugin must be able to run without a custom GUI (remote control from elsewhere), the host need to receive any needed information to provide the functionality of the Plugin GUI by a internal UI. If a extension is implemented "official", it will be very, very hard to remove this support later, so it must be cleared that the extension in question didn't harm in the long run. I haven't look at your extension for now, still it is the first time I hear of it, so my words wasn't about your extension specially.
I guess you know it by yourself, a solution which seems today reasonable, may make you feel next year "ups, why was I so stupid"
So I didn't understand your arg about the "API for host-generated UIs", isn't that were all the turtle is about?

[tramp]

I don't think LV2 does right. turtle data is static, and there are times we want dynamic.
this is why we don't have dynamic control ports right now.

Indeed, that is a burning point, and I agree that we need dynamic ports. But, it should be possible even with "static turtle data". Imagine, that the turtle data only be used to open/load a plug, when it is loaded, plug and host can communicate about such a request. This could be placed in the instantiate() call, so that additional ports could created before a plug run() to reflect a possible loaded sate.
I know, we haven’t such a extension jet, I just say it, because I mean it have less to do with turtle or not.

host-generated UIs will for sure need some dynamic widgets.
a combo-box might change the type of an analyzer, or different kinds of meters, etc.
I don't think static data would be a good choice for this.

mmm, the changes will be static, always the same action leads to the same change, that is static by my understand. The only question here is, have the host enough information about how to act on a special port value change,that is in the first point a question of Metadata, which will be static again, . . . and have the host the function to create the needed widget ( a plot or a meter, or what ever). Right now, we have the possibility to let the host know, that "this button" will open a file browser and request a file path in return. That is a step in this direction.

[tramp]

what you are describing evolves "C structs and functions" instead of static data
a mix of static and dynamic data should work as you describe yes, but you still have to deal with hosts not supporting the extension

Well, that is the usual way how hosts and plugs communicate/interact, after the turtle is read, isn't it?
Plugins need to check if a extension is supported, host must checks if a plug will run with the provided extensions, and then they change information’s and start to work together with the help of some "C structs and functions". So no reason for drobilla "to punch you to death"
But, yea, I know as well it will be hard ride to get his "bless" for such a extension.

I've heard about this, but haven't seen it in action yet. Which plugins and hosts support this?

It's convolveLv2
https://github.com/x42/convoLV2
and it's supported in jalv.

[tramp]

read here:
http://drobilla.net/2013/01/10/host-gen ... -choosers/

When host support becomes established, we can also move towards using messages for numeric parameters, which will finally allow for dynamic parameters, control ramps, and so on.

[male]

FWIW, drobilla has a specific agenda for TTL. It's not there by accident or really because it needs to be. It is there to support his intensions of being able to export Ingen graphs as TTL files that can be loaded in LV2 hosts. That means that we all must suffer in order to support a single use case, which is probably the most repulsive thing about LV2's design. EDIT: as presented as a general purpose plugin API to replace LADSPA, that is.

[tramp]

That means that we all must suffer in order to support a single use case

What exactly makes you suffer? If you didn't like LV2, you can still use LADSPA.
LADSPA isn't dead, as you properly know, Tim Goetze have just released CAPS 0.9.13, and Fons Adriaensen released a famous update of the REV plugins.
Even here, j_e_f_f_g decided for himself to add LADSPA support to his LV2 Create tool. The only project I'm aware of, which skips LADSPA support is CALF, but fortunately there is the fork maintained by falk, which add LADSPA support back.
Ah, well, Ingen skips LADSPA as well

Or do you suffer when you see LV2 accepted to, by more and more applications (and host and plug developers)?
Didn't you point out you don’t need any of the LV2 plugs?

[male]

That means that we all must suffer in order to support a single use case

What exactly makes you suffer? If you didn't like LV2, you can still use LADSPA.
LADSPA isn't dead, as you properly know, Tim Goetze have just released CAPS 0.9.13, and Fons Adriaensen released a famous update of the REV plugins.
Even here, j_e_f_f_g decided for himself to add LADSPA support to his LV2 Create tool. The only project I'm aware of, which skips LADSPA support is CALF, but fortunately there is the fork maintained by falk, which add LADSPA support back.
Ah, well, Ingen skips LADSPA as well

Or do you suffer when you see LV2 accepted to, by more and more applications (and host and plug developers)?
Didn't you point out you don’t need any of the LV2 plugs?

The developers/users of LV2 for non-embedded-ingen purposes suffer from the use of TTL. The design itself suffers from the burden of supporting that one use case.

[tramp]

The developers/users of LV2 for non-embedded-ingen purposes suffer from the use of TTL. The design itself suffers from the burden of supporting that one use case.

I'm as well not a fan of the turtle syntax, I would prefer json
However, I see a advance in the use of "config files" to load plugs. Even in LADSPA we have the RDF files with the xml syntax, to get default values, ranges, and other port hints.
For the special case of the "non-embedded-ingen" use, it didn't matter if it is ttl, xml, json, or, a crazy self develop syntax. So your arg suffer a bit of substance, given, that we would have a way to describe the state of a plug in a external "config" file.

A example were users benefit from the ttl files is: save a preset in Ardour and use it latter in qtractor, or any other lv2 host.

[male]

The developers/users of LV2 for non-embedded-ingen purposes suffer from the use of TTL. The design itself suffers from the burden of supporting that one use case.

I'm as well not a fan of the turtle syntax, I would prefer json
However, I see a advance in the use of "config files" to load plugs. Even in LADSPA we have the RDF files with the xml syntax, to get default values, ranges, and other port hints.
For the special case of the "non-embedded-ingen" use, it didn't matter if it is ttl, xml, json, or, a crazy self develop syntax. So your arg suffer a bit of substance, given, that we would have a way to describe the state of a plug in a external "config" file.

The RDF cruft is a wart on LADSPA. It expresses nothing, literally nothing, that could not have been just as easily (in fact more easily) expressed in C, as an extension to the existing API. Is it any coincidence that the person who brought RDF to LADSPA is the same one who brough TTL to LV2?

A example were users benefit from the ttl files is: save a preset in Ardour and use it latter in qtractor, or any other lv2 host.

This is illogical. Just because TTL is used for presets, doesn't mean that presets require TTL. There are an infinite number of other ways to accomplish the same thing.

[tramp]

It expresses nothing, literally nothing, that could not have been just as easily (in fact more easily) expressed in C, as an extension to the existing API.

Theoretical it is possible to wrote a extension which replace the plug.ttl file, (maybe not the manifest.ttl, but this is indeed not a big deal)