Sneak Preview: LV2 Create

[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

[falkTX]

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.
Previous experience shows that it may be impossible... http://linuxaudio.org/mailarchive/laa/2012/8/21/192325

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

btw, Although we see some new LV2 plugins being released lately, we can't say the same for hosts.

[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?

[falkTX]

So I didn't understand your arg about the "API for host-generated UIs", isn't that were all the turtle is about?

sorry I wasn't clear enough. the comment was about the fact that, if you try to do things outside the turtle business, drobilla will punch you to death
this can be any random data. instead of using turtle static data, we could use C structs and functions.

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.

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.

[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.

[falkTX]

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 state.

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 (but some plugin authors only have interest to see their plugins working in 1 single host).

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.

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

[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.

[falkTX]

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.

from the code I saw the plugin registers an UI, and that UI has a button that triggers a gtk-file-path. I suppose that's a backwards-compatible thing.
I see the parameter path in there sure, but it doesn't specify file extensions, dirs vs files, multiple vs single file or any hint like this.
So although this is a step in the right direction, even this bit is far from finished.

[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)