Re: [linux-audio-dev] LADSPA needs wishes
On 30 Jan 2007, at 01:25, Fraser wrote: Hi Steve, Ah, well the host is not supposed to change port values during run() anyway, the idea in LADSPA (and LV2) is that the host should chop the run() block where port values change. In practice not all hosts do that, some just pick a suitably small block size, eg. 32 frames and quantise the changes to that rate. I didn't realise that - perhaps I glossed over that bit of the spec. A block size of 32 frames would really exagerate unnecessary paramter conversion... Sure, which is why people do tend to do the if (oldval != newval) thing on expensive parameter calculations. 32 is really the extreme end, I would think that typically its higher than that. JACK systems do run down to the 32 frame buffer level, so you have to be able to handle it anyway. It's quite inefficient as the cost of calling the run() function of every plugin for every block is significant. - Steve
Re: [linux-audio-dev] LADSPA needs wishes
On 29 Jan 2007, at 02:18, Fraser wrote:
Hi Steve,
Hi Fraser,
Sure. This was an issue in LADSPA, though not a significant enough
one that anyone wanted it changed. I would suspect you're
overestimating the burden compared to the function call overhead and
cache thrashing. I'd be interested to see figures indicating
otherwise though. There will obviously be cases where it's faster to
set values using callbacks, but I'll bet it's not universal.
I had a thought last night about this - if I am worried about the load
from converting parameters I can always do something like:
if(current_control_value1 != last_control_value1)
{
recalculate internal_value1
}
in the run loop
Yes, exactly. It's slightly more expensive as you have a conditional,
but you save the function call overhead, which is something like
1000-1500 cycles IIRC.
3) changes to parameters can be presented to the run() function
immediately
I don't see how it makes any difference in this area?
in the example code this line:
const float gain = *(plugin_data-gain);
is outside the for loop in the run() function
so changes to the gain are not picked up till the next run() call.
Ah, well the host is not supposed to change port values during run()
anyway, the idea in LADSPA (and LV2) is that the host should chop the
run() block where port values change. In practice not all hosts do
that, some just pick a suitably small block size, eg. 32 frames and
quantise the changes to that rate.
- Steve
Re: [linux-audio-dev] LADSPA needs wishes
On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote: Chris Cannam [EMAIL PROTECTED] writes: What are they? Do they do anything else, besides host LV2 plugins? I'm aware of these LV2 hosts: * jack_host from libslv2 project, by Dave Robillard * elven from ll-plugins project, by Lars Luthman * zynjacku, by me * maybe ingen (om), by Dave Robillard, LV2 support is ready too Thanks. Is there any more information about Elven (besides the code)? Is Zynjacku specific to Zyn in any way, or is it just named that way because you wanted an LV2 host when you happened to be working on Zyn-based plugins? What else you want them to do? (zynjacku feature list is still open) Oh, I don't mind. I was just wondering. I suppose I was also wondering if any previously-existing applications besides Om/Ingen had started adding LV2 support yet. It's evident from my and Robert's posts in this thread that Rosegarden and MusE haven't, but there are plenty of others that might have. What about Dino? P.S. Antisocial humans don't read mailing lists. Yeah, they do. Me for example. Sorry for being so grumpy. Chris
Re: [linux-audio-dev] LADSPA needs wishes
On Mon, 2007-01-29 at 13:49 +, Chris Cannam wrote: On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote: Chris Cannam [EMAIL PROTECTED] writes: What are they? Do they do anything else, besides host LV2 plugins? I'm aware of these LV2 hosts: * jack_host from libslv2 project, by Dave Robillard * elven from ll-plugins project, by Lars Luthman * zynjacku, by me * maybe ingen (om), by Dave Robillard, LV2 support is ready too Thanks. Is there any more information about Elven (besides the code)? Elven is not really meant to be used. It's an experimental host and a perpetual work-in-progress that I'm writing to test new extensions and to see how hard it is to write a basic LV2 host from scratch, including Turtle parsing and RDF subgraph querying (conclusion: not very hard). What about Dino? Dino doesn't do audio. It could maybe use LV2 for filtering and generating MIDI, but I can't think of any real uses for that that wouldn't be easier to do as a part of the actual program instead of a plugin. --ll signature.asc Description: This is a digitally signed message part
Re: [linux-audio-dev] LADSPA needs wishes
On 29 Jan 2007, at 14:41, Lars Luthman wrote: On Mon, 2007-01-29 at 13:49 +, Chris Cannam wrote: On Monday 29 Jan 2007 07:39, Nedko Arnaudov wrote: Chris Cannam [EMAIL PROTECTED] writes: What are they? Do they do anything else, besides host LV2 plugins? I'm aware of these LV2 hosts: * jack_host from libslv2 project, by Dave Robillard * elven from ll-plugins project, by Lars Luthman * zynjacku, by me * maybe ingen (om), by Dave Robillard, LV2 support is ready too Thanks. Is there any more information about Elven (besides the code)? Elven is not really meant to be used. It's an experimental host and a perpetual work-in-progress that I'm writing to test new extensions and to see how hard it is to write a basic LV2 host from scratch, including Turtle parsing and RDF subgraph querying (conclusion: not very hard). I would hope that there aren't many more than this, as it's still a draft spec, and it's not all nailed down. I'd hate for too many people to implement a draft before it's finalised. - Steve
Re: [linux-audio-dev] LADSPA needs wishes
On Mon, Jan 29, 2007 at 08:08:37AM +, Steve Harris wrote: Ah, well the host is not supposed to change port values during run() anyway, the idea in LADSPA (and LV2) is that the host should chop the run() block where port values change. /delurk What does chop the run block mean? /relurk -- Paul Winkler http://www.slinkp.com
Re: [linux-audio-dev] LADSPA needs wishes
On 29 Jan 2007, at 15:23, Paul Winkler wrote: On Mon, Jan 29, 2007 at 08:08:37AM +, Steve Harris wrote: Ah, well the host is not supposed to change port values during run() anyway, the idea in LADSPA (and LV2) is that the host should chop the run() block where port values change. /delurk What does chop the run block mean? /relurk Imagine you have a block of 1024 samples, and at sample 24 a control value changes from 1 to 2, you could do: plugin-port = 2.0; plugin-run(1024); which puts the control value change in slightly the wrong place, or you could do: (chopping) plugin-port = 1.0; plugin-run(24); plugin-port = 2.0; plugin-run(1000); It's not a technical term or anything, I just needed a word :) - Steve
Re: [linux-audio-dev] LADSPA needs wishes
On Mon, 2007-01-29 at 10:23 -0500, Paul Winkler wrote: On Mon, Jan 29, 2007 at 08:08:37AM +, Steve Harris wrote: Ah, well the host is not supposed to change port values during run() anyway, the idea in LADSPA (and LV2) is that the host should chop the run() block where port values change. What does chop the run block mean? If the host is normally running with period size 1024 (mandated by JACK for example) but at some point wants to change one of the plugin's control parameters 326 frames into a period, it will have to chop the period into two pieces, [0-325] and [326-1023]. It will then call run(326) in the plugin to generate/process the first 326 frames, then change the control parameter value, then call run(698) to generate/process the rest of the frames. --ll signature.asc Description: This is a digitally signed message part
Re: [linux-audio-dev] LADSPA needs wishes
Chris Cannam [EMAIL PROTECTED] writes: Is Zynjacku specific to Zyn in any way, or is it just named that way because you wanted an LV2 host when you happened to be working on Zyn-based plugins? It is not specific. I loaded and produced sound with some of LV2 plugins From ll-plugins and with one LV2 sampler plugin. ATM zynjacku cannot show UIs for plugins that don't support the lv2dynparam extension and currently the only synth that supports lv2dynparam extension is zynadd. It will be able to generate generic UI for any plugin (based on its RDF file) and to show custom UIs once approach for them is stable enough. AFAIK only Lars Luthman is working on custom UI approach and once he publishes the extension I'll add support for it. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpV4YvgL74j1.pgp Description: PGP signature
Re: [linux-audio-dev] LADSPA needs wishes
Hi Steve, Ah, well the host is not supposed to change port values during run() anyway, the idea in LADSPA (and LV2) is that the host should chop the run() block where port values change. In practice not all hosts do that, some just pick a suitably small block size, eg. 32 frames and quantise the changes to that rate. I didn't realise that - perhaps I glossed over that bit of the spec. A block size of 32 frames would really exagerate unnecessary paramter conversion... regards, Fraser
Re: [linux-audio-dev] LADSPA needs wishes
On 1/28/07, Chris Cannam [EMAIL PROTECTED] wrote: On Saturday 27 Jan 2007 18:57, Nedko Arnaudov wrote: Robert Jonsson [EMAIL PROTECTED] writes: On Saturday 27 January 2007 06:47, Loki Davison wrote: why are you coding new stuff for a depreciated system? Why not LV2? And why should you code for a plugin standard that nothing supports? [...] nothing? i'm aware of 3 hosts that can host lv2 plugins. What are they? Do they do anything else, besides host LV2 plugins? There does seem to be a habit here for people to describe things as deprecated, when what they mean is they don't like them very much themselves, they no longer consider them state of the art, and there's a technically better alternative that isn't widely supported yet. (The ALSA sequencer API is another current example.) It's an arrogant and antisocial habit. mmm. I'm sorry for my arrogant and antisocial habits. I had once again a little bit of food poisioning or something and i'd just been hiking near tibet and hadn't had a shower for 1 and half weeks. I was more aiming at getting at there is not point in suggesting problems/issues with the ladspa spec as it is no longer being developed. So either you deal with it's downsides or you write LV2 plugins. It's not like i can really talk as i haven't ported any of my own ladspa plugins to LV2. As far as hosts go ingen supports lv2 and is a quite powerful host. Then again no sequencer or DAW that i know of... ;) then again i'm quite out of the loop at the moment. Loki p.s i hope this doesn't come across as arrogant, your comments about nothing may seem that way to the authors of those hosts.
Re: [linux-audio-dev] LADSPA needs wishes
On 28 Jan 2007, at 05:07, Fraser wrote: however, it and i think all the other issues you raise are all solved by LV2 (LADSPA Version 2), which has come about in part from other people's difficulties with the same range of problems as you. ahh, so there is a V2 coming, not too much info about it yet out there (unless you know where to look) Which is deliberate, as it's not quite finished yet. There was quite a lot of discussion here though. On the natural parameter values, I really rather like it that way. Sure, it costs a bit of CPU to do the conversion, but it means that different plugins of the same type are more likely to be compatible, and it makes wiring up things in a modular synth style easier. It also means that things like preset files contain the same values as the live display, which is helpful. When it comes to burning a bit of extra CPU power to make the users life easier, I'm all for it. From my quick look at the LV2 spec there's something I'd like to see (this is just my 2c): The plugin doesn't know when a parameter has changed, so it must calculate it's internal values from the displayed parameter 'as often as possible' - once per run() call (doing it in the for loop itself is just too extreme). Sure. This was an issue in LADSPA, though not a significant enough one that anyone wanted it changed. I would suspect you're overestimating the burden compared to the function call overhead and cache thrashing. I'd be interested to see figures indicating otherwise though. There will obviously be cases where it's faster to set values using callbacks, but I'll bet it's not universal. It's also quite convenient for both the plugin and host not to have to provide/call callbacks for every parameter. ... This has the following advantages 1) run() just runs (saved a bit of cpu) But costs you some extra function calls, and makes the CPU load dependent on the frequency of changes, which makes predictably hitting RT deadlines harder. 2) internal values are only calculated when the parameter they are associated with changes True. 3) changes to parameters can be presented to the run() function immediately I don't see how it makes any difference in this area? 4) the plugin knows when a parameter changed and so can smooth jumps in values itself (rather then hoping to host is doing it) Either way the plugin is free to do parameter smoothing. Typically I just do a linear interpolation and/or a 1st order LP filter. - Steve
Re: [linux-audio-dev] LADSPA needs wishes
Hi Steve,
ahh, so there is a V2 coming, not too much info about it yet out there
(unless you know where to look)
Which is deliberate, as it's not quite finished yet. There was quite
a lot of discussion here though.
I took me a while to find this list.
The http://www.ladspa.org site refers to the linux audio developers
mailing list as being here: http://www.linuxaudiodev.com/ which has had
nothing but a holding page since the middle of last year...
Sure. This was an issue in LADSPA, though not a significant enough
one that anyone wanted it changed. I would suspect you're
overestimating the burden compared to the function call overhead and
cache thrashing. I'd be interested to see figures indicating
otherwise though. There will obviously be cases where it's faster to
set values using callbacks, but I'll bet it's not universal.
Perhaps I am yes.
I am more thinking about the consequences of this when running 40+ plugins
as the same time (mixing in VST for example I'll use that many plugins
easily). With that many the conversions would add up to something but like
you say it could be neglible. I'll try to benchmark it and post some
results.
I had a thought last night about this - if I am worried about the load
from converting parameters I can always do something like:
if(current_control_value1 != last_control_value1)
{
recalculate internal_value1
}
in the run loop
BTW this all came about from one of the plugins I'm working one - 10
parameters from which 50 internals are calculated - lots of
sin,cos,tan,pow sqrt's going on. By keeping track of the previous values
at least I can recalculate when I detect a change rather than every run()
call.
3) changes to parameters can be presented to the run() function
immediately
I don't see how it makes any difference in this area?
in the example code this line:
const float gain = *(plugin_data-gain);
is outside the for loop in the run() function
so changes to the gain are not picked up till the next run() call.
whereas in my example I had my (magically converted) parameter inside the
for loop - so any changes are picked up immediately:
for (pos = 0; pos sample_count; pos++) {
output[pos] = input[pos] * plugin_data-MyTranslatedGain;
}
When you consider plugin parameters can be automated and music is all
about timing, having an unpredictable delay between when a parameter is
changed and when the new value is applied could be an issue (ie you can't
make the sound being produced by a plugin change 'on the beat').
With my setup, blocks of audio are 2048 fames in size, so my run()
function will pick up changes every 46ms - which is an audible delay
(yes I agree this is a small deal and if really matters to the plugin
there are ways around it)
regards,
Fraser
Re: [linux-audio-dev] LADSPA needs wishes
Fraser [EMAIL PROTECTED] writes: The plugin doesn't know when a parameter has changed, so it must calculate it's internal values from the displayed parameter 'as often as possible' - once per run() call (doing it in the for loop itself is just too extreme). dynparam LV2 extension handles parameter changes using callbacks. It is not finished yet (but it is working at some degree). http://home.gna.org/lv2dynparam/ Recalculating params on each run would be pain for zynadd, because it has *many* parameters. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpwppUvg5HXK.pgp Description: PGP signature
Re: [linux-audio-dev] LADSPA needs wishes
On Saturday 27 January 2007 06:47, Loki Davison wrote: On 1/27/07, Fraser [EMAIL PROTECTED] wrote: Hi All, I've been converting my old VST plugins over to LADSPA and have come across something in the api which I really miss - the inability separate the algorithmic to the displayed value of a parameter. I'm finding this inability is leading to non-ideal programming habits. why are you coding new stuff for a depreciated system? Why not LV2? And why should you code for a plugin standard that nothing supports? Besides, is LV2 even finished? Suggesting that LADSPA is deprecated is a bit of a stretch. It may not be perfect, but it's well supported. /Robert It's extensible so if anything is missing you can add it. http://lv2plug.in/ Loki p.s. hiking in yunnan / tibet border area is pretty awesome!
Re: [linux-audio-dev] LADSPA needs wishes
On Sat, 2007-01-27 at 16:05 +1100, Fraser wrote: Hi All, I've been converting my old VST plugins over to LADSPA and have come across something in the api which I really miss - the inability separate the algorithmic to the displayed value of a parameter. I'm finding this inability is leading to non-ideal programming habits. the first issue you raise is a basic flaw in LADSPA's design that we tried to patch over with the hint stuff. there is no real solution for it that i know of - its just a dumb piece of design on our part. however, it and i think all the other issues you raise are all solved by LV2 (LADSPA Version 2), which has come about in part from other people's difficulties with the same range of problems as you. i would personally recommend: 1) do a LADSPA version and just suck up to the nasty display issues of showing the user the raw value unless its an SR-related parameter 2) be ready to take the core of your plugin and release it as an LV2 plugin once adoption of it by a couple of hosts emerges. it will be very easy to do this, and will open up a world of new possibilities. the bottom line is that the problems you have identified have been identified before, and the solution is LV2. they will not be fixed as part of LADSPA v1 because the fix has already been designed and in some senses implemented. --p
Re: [linux-audio-dev] LADSPA needs wishes
Robert Jonsson [EMAIL PROTECTED] writes: On Saturday 27 January 2007 06:47, Loki Davison wrote: On 1/27/07, Fraser [EMAIL PROTECTED] wrote: Hi All, I've been converting my old VST plugins over to LADSPA and have come across something in the api which I really miss - the inability separate the algorithmic to the displayed value of a parameter. I'm finding this inability is leading to non-ideal programming habits. why are you coding new stuff for a depreciated system? Why not LV2? And why should you code for a plugin standard that nothing supports? Besides, is LV2 even finished? Suggesting that LADSPA is deprecated is a bit of a stretch. It may not be perfect, but it's well supported. nothing? i'm aware of 3 hosts that can host lv2 plugins. maybe there are others i'm not aware of. -- Nedko Arnaudov GnuPG KeyID: DE1716B0 pgpZZNLIch0bk.pgp Description: PGP signature
Re: [linux-audio-dev] LADSPA needs wishes
On Saturday 27 Jan 2007 18:57, Nedko Arnaudov wrote: Robert Jonsson [EMAIL PROTECTED] writes: On Saturday 27 January 2007 06:47, Loki Davison wrote: why are you coding new stuff for a depreciated system? Why not LV2? And why should you code for a plugin standard that nothing supports? [...] nothing? i'm aware of 3 hosts that can host lv2 plugins. What are they? Do they do anything else, besides host LV2 plugins? There does seem to be a habit here for people to describe things as deprecated, when what they mean is they don't like them very much themselves, they no longer consider them state of the art, and there's a technically better alternative that isn't widely supported yet. (The ALSA sequencer API is another current example.) It's an arrogant and antisocial habit. For someone who wants to write effects plugins for a reasonably large audience of Linux users to use right now, there's one choice: LADSPA. DSSI has been a technically better choice for a few years now, but it has few hosts and I'm not sure whether all of those even support DSSI plugins as effects -- although they should. LV2 is also a technically better choice, but even less widely supported so far. That will change, but it's far too soon to be suggesting it's the only Linux plugin API worth writing for, especially as porting from LADSPA to LV2 (and/or supporting both) should be easy enough. You can argue for driving adoption of LV2 by writing cool plugins for it, but that's quite different from saying you shouldn't be writing for LADSPA at all. Chris
RE: [linux-audio-dev] LADSPA needs wishes
Suggesting that LADSPA is deprecated is a bit of a stretch. It may not be perfect, but it's well supported. What would be really nice for LA scene is to clean up the available Ladspa plugins so that they all just work while there is still a momentum to maintain these. Unless this has changed recently, LADSPA libs are like a minefield--some work while others crash bringing down the whole audio setup with them. Has there been any progress made on this? Best wishes, Ico
Re: [linux-audio-dev] LADSPA needs wishes
Hi Paul,
however, it and i think all the other issues you raise are all solved by
LV2 (LADSPA Version 2), which has come about in part from other people's
difficulties with the same range of problems as you.
ahh, so there is a V2 coming, not too much info about it yet out there
(unless you know where to look)
From my quick look at the LV2 spec there's something I'd like to see (this
is just my 2c):
The plugin doesn't know when a parameter has changed, so it must calculate
it's internal values from the displayed parameter 'as often as possible' -
once per run() call (doing it in the for loop itself is just too extreme).
ie from http://lv2plug.in/plugins/Amp-example.lv2/amp.c
#define DB_CO(g) ((g) -90.0f ? powf(10.0f, (g) * 0.05f) : 0.0f)
static void runAmp(LV2_Handle instance, unsigned long sample_count) {
Amp *plugin_data = (Amp *)instance;
const float gain = *(plugin_data-gain);
const float * const input = plugin_data-input;
float * const output = plugin_data-output;
unsigned long pos;
float coef = DB_CO(gain); -
for (pos = 0; pos sample_count; pos++) {
output[pos] = input[pos] * coef;
}
}
better (to me anyway) is to get the run loop down to actually processing
audio and do the conversion elsewhere
ie
static void runAmp(LV2_Handle instance, unsigned long sample_count) {
Amp *plugin_data = (Amp *)instance;
const float * const input = plugin_data-input;
float * const output = plugin_data-output;
unsigned long pos;
for (pos = 0; pos sample_count; pos++) {
output[pos] = input[pos] * plugin_data-MyTranslatedGain;
}
}
To do that though the plugin needs to be told when a parameter has changed
so it can work out the new internal value.
#define DB_CO(g) ((g) -90.0f ? powf(10.0f, (g) * 0.05f) : 0.0f)
static void paramAmp(LV2_Handle instance, unsigned long port) {
Amp *plugin_data = (Amp *)instance;
switch (port) {
case AMP_GAIN:
plugin_data-MyTranslatedGain = DB_CO(*(plugin_data-gain));
break;
}
}
and a new function in the descriptor
ampDescriptor-param = paramAmp;
This has the following advantages
1) run() just runs (saved a bit of cpu)
2) internal values are only calculated when the parameter they are
associated with changes
3) changes to parameters can be presented to the run() function immediately
4) the plugin knows when a parameter changed and so can smooth jumps in
values itself (rather then hoping to host is doing it)
with 1 param it's not a big deal, but when you have 10 and end up with
half a page of complex maths in your run() just in case a parameter
changed from the last call you begin to wish it was elsewhere...
i would personally recommend:
1) do a LADSPA version and just suck up to the nasty display issues
of showing the user the raw value unless its an SR-related parameter
2) be ready to take the core of your plugin and release it as an LV2
plugin once adoption of it by a couple of hosts emerges. it will be very
easy to do this, and will open up a world of new possibilities.
ok will do,
looking forward to LV2
regards,
Fraser
[linux-audio-dev] LADSPA needs wishes
Hi All,
I've been converting my old VST plugins over to LADSPA and have come
across something in the api which I really miss - the inability separate
the algorithmic to the displayed value of a parameter.
I'm finding this inability is leading to non-ideal programming habits.
Let me show what I mean with a few examples.
I have a control that represents a gain knob (say -12dB - 12dB):
What's best for the run function is a value that represents the ratio
which I can simply multiply the audio by as it it keeps the maths simple
(0.25 - 4). What's best for display is decibels (as that is way gain is
understood).
I can't do this with LADSPA - so as I programmer I'm left with a lose-lose
choice.
* I either choose a parameter range of -12 - 12 (dB) and convert that to
a ratio every time the run function is called:
fGain = pow(10, *(psMyPlugin-m_pfControlGain) /20);
Which is an unnecessary use of cpu. (and as someone who has mixed many
albums on computers you need every scap of cpu you can get)
* Or I choose to use 0.25 - 4 as my range. Now users are faced with a
parameter they don't intuitively understand (it is contrary to every other
bit of audio gear they have ever used) - most people cannot do
20*Log10(Gain) in their heads to work out the equivalent value in dB.
Of the two choices I choose the first, better to eat up too much cpu than
to have an interface that is unintuitive, but this is not ideal.
This gets worse when you have a control for something like 'warmth'. The
user does not need to know the range of values required to apply warmth in
an efficient manner (it won't mean anything to them), they just need to
know how much (0%-100%).
Another example - presets
I have a control that allows an operator to chose one of fifty presets
(say a reverb with small room, medium room, large room, hall etc). I don't
have a choice this time. Internally using an integer to represent the
different presets is fine, it's exactly all I need.
However even though I know what the preset is, I cannot display it's name
back to the user, so our user is left with a set of meaningless numbers
which they must resolve into names by some other means (print the doco out
and stick it on the wall?)
What I'd find useful in the api is an optional 'get_display' function
which allows the host app to get a human interpretation of a parameter for
display. It would only need to be called when a plugin windows is opened
or when a parameter is changed. Since the host has to convert the
parameter to a string in order to display it anyway, this is not a extra
step overall. We are just bringing it into the realm of the plugin.
/* pseudo code */
void GetMyDisplay(char *stDisplay, int Size, unsigned long Port)
{
stTemp[LADSPA_MAX_EVER_DISPLAY_SIZE);
switch(Port) {
case MY_GAINCONTROL:
sprintf(stTemp,%4.1f dB,20*log10(PortValue));
stTemp[Size-1]='\0'; /* truncate it to what the host wants*/
strncopy(stDisplay,stTemp,Size);
break;
case MY_WARMTHCONTROL:
sprintf(stTemp,%4.1f %%,some_complex_function(PortValue));
stTemp[Size-1]='\0'; /* truncate it to what the host wants*/
strncopy(stDisplay,stTemp,Size);
break;
}
}
Now for a wish.
GUI - under OSX or windows this isn't such a big drama, there's only one
GUI environment to deal with. under Linux it's a different matter.
I sometimes think the best thing to do is to provide enough hints to the
host so it can render a more comprehensive gui, if it desires, rather than
the plugin drawing the gui as is traditionally done. This would entail a
few things.
1) Utilize ports of type: LADSPA_PORT_OUTPUT | LADSPA_PORT_CONTROL
what is that?
- it's a meter, a light, etc
We'd just need some hints defined and the rest is up to the host
(most host apps already have their own audio specific widgets. we just
need to tell them which ones we want to use). These all need to be bounded
as any other control would be.
/* a peak meter, expects a ratio not a dB value */
LADSPA_HINT_METER_PEAK
/* a vu meter, expects a ratio not a dB value */
LADSPA_HINT_METER_VU
/* Some meters like gain reduction meters in a compressor meter backwards,
ie illuminated from max value downwards rather than minimum value upwards
*/
LADSPA_HINT_METER_REVERSED
/* a simple on/off light */
LADSPA_HINT_LIGHT_ONOFF
/* a light which has intesity */
LADSPA_HINT_LIGHT_INTENSITY
2) Add control layout to the port definitions
Could be done as by defining arbitrary bounding boxes.
/*
* +--+--+
* | gain | |
* +--+ meter|
* | warmth | |
* +--+--+
*/
PortLayoutHints[MY_GAIN].top=0;
PortLayoutHints[MY_GAIN].bot=1;
PortLayoutHints[MY_GAIN].left=0;
PortLayoutHints[MY_GAIN].right=3;
PortLayoutHints[MY_WARMTH].top=1;
PortLayoutHints[MY_WARMTH].bot=2;
PortLayoutHints[MY_WARMTH].left=0;
PortLayoutHints[MY_WARMTH].right=3;
PortLayoutHints[MY_METER].top=0;
PortLayoutHints[MY_METER].bot=2;
PortLayoutHints[MY_METER].left=3;
Re: [linux-audio-dev] LADSPA needs wishes
On 1/27/07, Fraser [EMAIL PROTECTED] wrote: Hi All, I've been converting my old VST plugins over to LADSPA and have come across something in the api which I really miss - the inability separate the algorithmic to the displayed value of a parameter. I'm finding this inability is leading to non-ideal programming habits. why are you coding new stuff for a depreciated system? Why not LV2? It's extensible so if anything is missing you can add it. http://lv2plug.in/ Loki p.s. hiking in yunnan / tibet border area is pretty awesome!
Re: [linux-audio-dev] LADSPA needs wishes
On Sat, 2007-01-27 at 16:05 +1100, Fraser wrote: Hi All, I've been converting my old VST plugins over to LADSPA and have come across something in the api which I really miss - the inability separate the algorithmic to the displayed value of a parameter. I'm finding this inability is leading to non-ideal programming habits. There is the LADSPA_HINT_LOGARITHMIC port hint, which does part of what you want - it tells the host that any knob or slider should use a logarithmic mapping, but it doesn't give any display values. In LV2 this will be done with the :scalePoint property, which you can use to label the real value 1 as 0dB, 0.5 as -3dB and so on. Another example - presets I have a control that allows an operator to chose one of fifty presets (say a reverb with small room, medium room, large room, hall etc). I don't have a choice this time. Internally using an integer to represent the different presets is fine, it's exactly all I need. However even though I know what the preset is, I cannot display it's name back to the user, so our user is left with a set of meaningless numbers which they must resolve into names by some other means (print the doco out and stick it on the wall?) Presets are done in LADSPA using the additional library liblrdf, which a number of hosts (though not all) support. Internal presets could be done in LV2 using an integer port and scalePoint labels. Now for a wish. GUI - under OSX or windows this isn't such a big drama, there's only one GUI environment to deal with. under Linux it's a different matter. I sometimes think the best thing to do is to provide enough hints to the host so it can render a more comprehensive gui, if it desires, rather than the plugin drawing the gui as is traditionally done. This would entail a few things. There have been some suggestions for GUI markup standards for LADSPA, I don't know if any real hosts have supported them. It's not a bad idea as such. Another approach is DSSI (http://dssi.sf.net, an instrument extension of the LADSPA spec) which does GUIs using standalone programs distributed with the plugin that communicates with the host using OSC. --ll signature.asc Description: This is a digitally signed message part
Re: [linux-audio-dev] LADSPA preset musings
Yes, it seems to be great! But the project would be xx times greater if there were some screen shots plus a simple example host so that it'll be easier for us to add FLAM into our own software. Thanks for the advice, but I am still in the process of adding basic functionality, as stated in my first post. There is a step-by-step tutorial with screenshots in the TODO list before the time for a official release comes. As hosting is concerned, you just have to extend the DSSI GUI protocol to LADSPA plugins. This works already in Rosegarden. There are some hints at the README file on how to design and install a GUI. Cheers, Luis
Re: [linux-audio-dev] LADSPA preset musings
On Sun, Sep 17, 2006 at 11:22:29 +0200, Luis Garrido wrote: I have also thought of RDF/turtle as per the new LV2 spec but, if I am not mistaken, raptor doesn't write turtle and, to be honest, all this subject/predicate/object/ontology stuff seems like a bit of overkill just to store groups of (int, float) pairs, although this may change in LV2 if float is not the only type supported anymore. Raptor writes NTriples, which is a subset of Turtle. - Steve
Re: [linux-audio-dev] LADSPA preset musings
Luis Garrido: Hi there! I am in the process of adding preset management to my project FLAM (custom GUIs for LADSPAs, flam.sf.net) which, by the way, is already running under Rosegarden, checkout the SVN repo if you want to give it a try. ... I would be grateful for any advice on this subject. Yes, it seems to be great! But the project would be xx times greater if there were some screen shots plus a simple example host so that it'll be easier for us to add FLAM into our own software. (And in case those things already exist, make them easier to find on the web-page)
[linux-audio-dev] LADSPA preset musings
Hi there! I am in the process of adding preset management to my project FLAM (custom GUIs for LADSPAs, flam.sf.net) which, by the way, is already running under Rosegarden, checkout the SVN repo if you want to give it a try. For those interested I include below the specifications I have came up with regarding preset management. First I toyed with the idea of using SQLite to store the presets, but there were some drawbacks to it (adding an extra dependency, difficulties to manage list order, etc.) I was driven to it by the wish of providing concurrent access from different instances of FLAM but, in the end, I decided this feature was not worth the effort and downgraded it to the possibility of reloading the preset list to get the most up to date version at a certain point. Then I gave a look at the preset API provided by lrdf but I don't like it very much (makes use of uids -for retrieving the presets and for avoiding triplet conflicts-, resulting file difficult to read by a person.) OTOH it is somehow a standard (i.e., ardour uses it, any other app?) I have also thought of RDF/turtle as per the new LV2 spec but, if I am not mistaken, raptor doesn't write turtle and, to be honest, all this subject/predicate/object/ontology stuff seems like a bit of overkill just to store groups of (int, float) pairs, although this may change in LV2 if float is not the only type supported anymore. Another thing I find awkward regarding preset management is that all kind of ports share a common index space, so you have to pick the input control ones among them. This makes the programmer resort to convoluted data structures for what could be expressed, after all, with just an array. Not really a big deal, but having the list of input control ports singled out would make preset management easier. I would be grateful for any advice on this subject. Cheers, Luis - - Presets management interface: - - Keyboard accelerators: Ctrl+[0-9] loads one of the first ten presets in the list (1-based, Ctrl+0 loads item #10.) Ctrl+Shift+[0-9] saves the current status of the plugin in the corresponding position of the list (optional confirmation dialog.) - Context menu: there is a Preset entry in the context menu with three submenus: preset manager, load and save. Load and save unfold a list of the available presets to load or save respectively. Preset manager opens or brings to front the preset manager. - Preset manager is a non-modal dialog that displays a list of the available presets and the following buttons: - Save list dumps the preset list to the default disk location. - Reload list reloads the preset list from the default list location. Useful to share changes created in other instances of that FLAM. - Export exports the selected preset(s) to a user chosen file in a certain exchange format. - Import imports (adds) to the list the presets stored at user chosen file in a certain exchange format. - Apply/Load/Retrieve/Set/Restore? sets the plugin ports to the values stored in the preset (accelerator: doubleclick on the list.) - Store/Save/Overwrite? saves the status of the plugin to the selected preset (optional confirmation dialog.) - New creates a new preset from the current status of the plugin with a default name and enters immediately into rename mode. - Delete deletes the selected preset(s) from the list. - Rename changes the name of the preset (accelerator: click a selected item on the list.) - Up moves the selected preset one position up the list. - Down moves the selected preset one position down the list. Buttons Save List, Reload List, New, Import are always enabled. Buttons Apply, Store, Rename, Up, Down are enabled when only one item in the list is selected. Buttons Export, Delete are enabled when one or more items in the list are selected. Every plugin has two presets files (system and user) organized in a tree following the DSSI recommendation.
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote: Basically all you've added is port grouping. Sure, there's no binary breakage now - no kidding, you havn't had to change anything yet. All you've done is added a bunch of metadata that has no reason to be in binary code at all, but you've done it in a way that's going to break horribly as soon as you try to add something. No, it also adds rendering of port values. Though that is somewhat limited. Plus, it's completely useless for GUIs in a separate process, while LV2 is not (it's just a data file, anything can load it, it's not even architechture dependent). Just my two cents, but definitely not the right thing. That's possibly a bit harsh. I think it's reasonable to say that based on our experiences of LADSPA we know that's not the best way to go. - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 26, 2006 at 09:07:11AM +0100, Steve Harris wrote: On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote: Plus, it's completely useless for GUIs in a separate process, while LV2 is not (it's just a data file, anything can load it, it's not even architechture dependent). Just my two cents, but definitely not the right thing. That's possibly a bit harsh. I think it's reasonable to say that based on our experiences of LADSPA we know that's not the best way to go. If the GUI is in a separate process and connected by e.g. OSC, it could as well be on a machine that doesn't have the plugin files. Or that has a different version of them (for perfectly good reasons). To ensure consistency the GUI should get its plugin descriptions from the host anyway. This works even with POL (Plain Old Ladspa). -- FA Follie! Follie! Delirio vano e' questo!
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote: On Mon, Jun 26, 2006 at 09:07:11AM +0100, Steve Harris wrote: On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave Robillard wrote: Plus, it's completely useless for GUIs in a separate process, while LV2 is not (it's just a data file, anything can load it, it's not even architechture dependent). Just my two cents, but definitely not the right thing. That's possibly a bit harsh. I think it's reasonable to say that based on our experiences of LADSPA we know that's not the best way to go. If the GUI is in a separate process and connected by e.g. OSC, it could as well be on a machine that doesn't have the plugin files. Or that has a different version of them (for perfectly good reasons). To ensure consistency the GUI should get its plugin descriptions from the host anyway. This works even with POL (Plain Old Ladspa). True enough, but with POL if the frontend and backend mahcines are different architectures or operating systems then you have a problem. - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 26, 2006 at 01:19:21PM +0100, Steve Harris wrote: On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote: If the GUI is in a separate process and connected by e.g. OSC, it could as well be on a machine that doesn't have the plugin files. Or that has a different version of them (for perfectly good reasons). To ensure consistency the GUI should get its plugin descriptions from the host anyway. This works even with POL (Plain Old Ladspa). True enough, but with POL if the frontend and backend mahcines are different architectures or operating systems then you have a problem. If send the raw binary data, yes, that's Inviting Trouble (IT). But if it's correctly OSC encoded there shouldn't be a problem. Anyway I guess a host would not use the raw LADSPA data, but a rather a more general format that it could use to describe its internal modules or other plugin formats as well. The GUI doesn't need to know if a module is built-in, LADSPA, LV2, or any other format. One more reason for not having it read the LV2 itself. -- FA Follie! Follie! Delirio vano e' questo!
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
To ensure consistency the GUI should get its plugin descriptions from the host anyway. This works even with POL (Plain Old Ladspa). rather a more general format that it could use to describe its internal modules or other plugin formats as well. The GUI doesn't in theory, this (client-readable metadata) shouldnt be a selling point. i mean if most hosts provided a nice API to query for plugin parameters. most don't.. it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace ..
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace In my mind every plugin parameter should be automatable, therefore every parameter update should be visible to the host ...therefore every plugin GUI should connect to the host (not directly to the plugin)...therefore to support such GUIs every host *SHOULD* provide some kind of query-of-plugin-namespace. Jeff Message: 3 Date: Mon, 26 Jun 2006 18:05:37 + From: carmen [EMAIL PROTECTED] Subject: Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data To: linux-audio-dev@music.columbia.edu Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii To ensure consistency the GUI should get its plugin descriptions from the host anyway. This works even with POL (Plain Old Ladspa). rather a more general format that it could use to describe its internal modules or other plugin formats as well. The GUI doesn't in theory, this (client-readable metadata) shouldnt be a selling point. i mean if most hosts provided a nice API to query for plugin parameters. most don't.. it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace ..
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, 2006-06-26 at 15:03 +0200, Alfons Adriaensen wrote: On Mon, Jun 26, 2006 at 01:19:21PM +0100, Steve Harris wrote: On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons Adriaensen wrote: If the GUI is in a separate process and connected by e.g. OSC, it could as well be on a machine that doesn't have the plugin files. Or that has a different version of them (for perfectly good reasons). To ensure consistency the GUI should get its plugin descriptions from the host anyway. This works even with POL (Plain Old Ladspa). True enough, but with POL if the frontend and backend mahcines are different architectures or operating systems then you have a problem. If send the raw binary data, yes, that's Inviting Trouble (IT). But if it's correctly OSC encoded there shouldn't be a problem. Anyway I guess a host would not use the raw LADSPA data, but a rather a more general format that it could use to describe its internal modules or other plugin formats as well. The GUI doesn't need to know if a module is built-in, LADSPA, LV2, or any other format. One more reason for not having it read the LV2 itself. As the author of such a host, I can tell you it's definitely an absolute godsend to be able to have the client read the data file directly. -DR-
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, 2006-06-26 at 18:05 +, carmen wrote: To ensure consistency the GUI should get its plugin descriptions from the host anyway. This works even with POL (Plain Old Ladspa). rather a more general format that it could use to describe its internal modules or other plugin formats as well. The GUI doesn't in theory, this (client-readable metadata) shouldnt be a selling point. i mean if most hosts provided a nice API to query for plugin parameters. most don't.. For one this is a really complicated thing to do (unless you want to just fire SPARQL queries directly over OSC which is a bit.. well.. different), and two this assumes the transport is reliable, which in the case of OSC over UDP isn't true. Trust me. :) it would be great for people to be able to make controllers for plugins, without the author of RoseGarden or Seq24 needing to ad some OM-style OSC-query-of-plugin-namespace I agree, and a good metadata querying system would be a very handy thing, but the nice thing about the data file is that it doesn't HAVE to be done that way, and flexibility is always good. As an example of where this is handy I'm going to do node previewing in Om's (now Ingen's) load plugin dialog by reading the data file directly. There's no node to query yet, and instantiating one is no good. There are solutions (making plugins a first class object and querying that), but why should the engine have to change to accomodate purely GUI related features? Plus, there's tons of other super fun things to be done with all that tasty graph data client side :] -DR-
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, 2006-06-19 at 19:31 +1000, Jez Kabanov wrote: The idea itself isn't stupid, but the implementation is.. let's say less than wise. (Consider my personal blatant bias, but...) I'd suggest taking a look at LV2. There is a data file you can add all this information to (whatever information you want to), without defining any APIs, changing any host code, etc, etc. You definitely shouldn't have to break binary compatibility of things just to add some hints for hosts, this is the problem LV2 is meant to solve... -DR- while i'm no expert in this area, i'm having some trouble understanding your rationale. how is it breaking binary compatibility? is binary compatibility even an issue? shouldn't the host just look for the plugin and load it and check for the existence of a symbol, if it exists then call it, otherwise it doesn't and everything is just as it was. the host never need know anything about the binary structure of the plugin except to know that there's a function called ladspa_descriptor, adding ladgui certainly doesn't stop old hosts from loading and using the plugin, i've modified nekobee to use ladgui and it runs exactly as it used to in an unmodified rosegarden, so how is binary compatibilty an issue? whereas LV2 breaks compatibilty with old plugins (this seems like more of an issue to me), adds a lot of complexity and requires the host to use an additional liblv2 library. Basically all you've added is port grouping. Sure, there's no binary breakage now - no kidding, you havn't had to change anything yet. All you've done is added a bunch of metadata that has no reason to be in binary code at all, but you've done it in a way that's going to break horribly as soon as you try to add something. Plus, it's completely useless for GUIs in a separate process, while LV2 is not (it's just a data file, anything can load it, it's not even architechture dependent). Just my two cents, but definitely not the right thing. -DR-
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Tue, 2006-06-20 at 00:57 +0200, Fons Adriaensen wrote: On Mon, Jun 19, 2006 at 11:25:52PM +0100, Steve Harris wrote: A well-designed set of tags like the ones you show above would probably solve 99.9% of all cases. But you can't expect anyone to dream that up in a day. Which leads me to my main gripe with LV2: it was defined much too fast. In a normal RFC process, you present the problem, give interested parties at least a month to consider it and write something that exceeds the quality of a whim, and then take at least as much time to study the results and comment on them before anything is decided. Sorry, but you're _really_ missing the whole point here, Fons. Noone expects anyone to be able to dream up something like the units definition in a day - that's the whole point! We don't _have_ to bicker and argue on a mailing list for days on end about some units definition problem that's completely orthogonal to the plugin specification itself. If the spec had to wait on every single thing that everybody wanted in it, it'd be waiting forever (See: GMPI). You are free to go through a formalized RFC process to define such a thing if you want. You're also free to just bang out a quick one in 5 minutes that gets the information you need in there. A few people already have extensions up their sleeve. LV2 doesn't need to wait on them, because extensions have no influence on the spec at all. RDF data can always be extended with other RDF data (eg your units information) - there is no possibility for clashes or anything like that. (I use quotes because these terms aren't really good descriptions of what's happening) As for giving interested parties a chance to weigh in, as Steve said the spec is still completely open to discussion. You are confused abut the scope of the spec itself though - there are a few things to discuss, but not many. The reason LV2 came about so quickly is because it's just LADSPA, translated into a saner extensible format, more or less verbatim. There's not much to weigh in about because noone's added anything new - just the ability to add something new in the future without breaking anything. Which is all we need... -DR-
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Tue, Jun 20, 2006 at 12:57:43 +0200, Fons Adriaensen wrote: :somePort lv2:unit unit:octavePitch ; lv2:baseFreq 264.0 . It's not beyond the realms of the possible to describe the mathematical relationship between the octave pitch unit and Hz, but it's probably excessive. A well-designed set of tags like the ones you show above would probably solve 99.9% of all cases. But you can't expect anyone to dream that up in a day. Which leads me to my main gripe with LV2: it was defined much too fast. In a normal RFC process, you present the problem, give interested parties at least a month to consider it and write something that exceeds the quality of a whim, and then take at least as much time to study the results and comment on them before anything is decided. I hope you dont have that impression, LV2 is not finalised, I tried to make sure I had draft and provisional in the text, but I guess I wasn't sufficiently clear, it is very much still up for discussion. My feeling is that it is somewhere around the Last Call stage in W3C speak. l-a-d fortunatly not having a formal standards process ;) Also, the units stuff I alluded to obove is not, and will not be part of the LV2 1.0 spec, it will come soon after and live as an extension. My plan was to crib from the scientific communities work on representing unit values in RDF, write an early draft and post it here. It is somewhat orthogonal to LV2 itsself, so if someone else with more time feels motivated to work on it, please do. The situation with LV2 is that I have ported most of my LADSPA plugins (to verify there were no blatant problems) to a version of the draft, and we now have 2-3 partial host implementations of the current draft. That doesn't cover the requirements of reference implementations to my satisfaction. So, just to be clear, nothing has been decided. The purpose of the website it to encourage discussion. - Steve
[linux-audio-dev] LADSPA Extension for Extra GUI Data
Hello, i'm new here, i've been working on a very simple, backward-forwards compatible extension to LADSPA/DSSI to allow hosts to display more meaningful gui's with a describe_value function which takes the port index and a LADSPA_Data and allows the plugin to return a meaningful description. eg. for a waveform port it might return SAW, SIN, SQR etc for a cutoff filter it might return the frequency in Hz for a tuning port it might return -4 semitones also wanting to add a mechanism to group ports into logical sections. without changing the underlying APIs, only by adding more layers on top this way preserving backwards compatibility, the host simply dlsyms for ladgui_descriptor and if it's there it makes use of the extra data, otherwise it falls back to how it previously did things once the API is done i plan to make a reference gui the idea behind this is that plugins will not need any of their own gui code as a useful gui can be constructed on the fly as a part of the host or a separate process that will work for any plugin so plugin developers never need worry about constructing a gui and can instead just make nice useable algorithms and test them quickly and easily. nicknamed LADGUI for now. API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h what i'd like to know is, if this is a stupid idea ^_^ it seems like a good one to me, but when i joined here to post this i noticed lots of talk about LADSPA2, i've tried to read up on it but i can't seem to find much information about it, and it doesn't seem to be backwards compatible and doesn't seem to add anything to help create guis in the host? is there a page somewhere which explains it all? i'm sure there's lots of useful stuff that i'm missing, what other things would be useful in such an extension? thanks Jez Kabanov
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 06:03:43 +1000, [EMAIL PROTECTED] wrote: Hello, i'm new here, i've been working on a very simple, backward-forwards compatible extension to LADSPA/DSSI to allow hosts to display more meaningful gui's with a describe_value function which takes the port index and a LADSPA_Data and allows the plugin to return a meaningful description. eg. for a waveform port it might return SAW, SIN, SQR etc for a cutoff filter it might return the frequency in Hz for a tuning port it might return -4 semitones This is handled in LADSPA+RDF and LV2 (aka LADSPA2) using scalePoints, eg. http://lv2plug.in/plugins/Amp-example.lv2/amp.ttl, search for lv2:scalePoint. That one's a silly example, but it makes the point. Things like -4 semitones will be handled by a units extensions, which will also allow hosts to use things like native gain control sliders for decibel ports, and BBT controls for time inputs. This idea is better in some ways, though though overall I prefer doing it though description, rather than programatically. - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, 2006-06-19 at 18:03 +1000, [EMAIL PROTECTED] wrote: Hello, i'm new here, i've been working on a very simple, backward-forwards compatible extension to LADSPA/DSSI to allow hosts to display more meaningful gui's with a describe_value function which takes the port index and a LADSPA_Data and allows the plugin to return a meaningful description. eg. for a waveform port it might return SAW, SIN, SQR etc for a cutoff filter it might return the frequency in Hz for a tuning port it might return -4 semitones also wanting to add a mechanism to group ports into logical sections. without changing the underlying APIs, only by adding more layers on top this way preserving backwards compatibility, the host simply dlsyms for ladgui_descriptor and if it's there it makes use of the extra data, otherwise it falls back to how it previously did things once the API is done i plan to make a reference gui the idea behind this is that plugins will not need any of their own gui code as a useful gui can be constructed on the fly as a part of the host or a separate process that will work for any plugin so plugin developers never need worry about constructing a gui and can instead just make nice useable algorithms and test them quickly and easily. nicknamed LADGUI for now. API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h what i'd like to know is, if this is a stupid idea ^_^ The idea itself isn't stupid, but the implementation is.. let's say less than wise. (Consider my personal blatant bias, but...) I'd suggest taking a look at LV2. There is a data file you can add all this information to (whatever information you want to), without defining any APIs, changing any host code, etc, etc. You definitely shouldn't have to break binary compatibility of things just to add some hints for hosts, this is the problem LV2 is meant to solve... -DR-
[linux-audio-dev] LADSPA Extension for Extra GUI Data
The idea itself isn't stupid, but the implementation is.. let's say less than wise. (Consider my personal blatant bias, but...) I'd suggest taking a look at LV2. There is a data file you can add all this information to (whatever information you want to), without defining any APIs, changing any host code, etc, etc. You definitely shouldn't have to break binary compatibility of things just to add some hints for hosts, this is the problem LV2 is meant to solve... -DR- while i'm no expert in this area, i'm having some trouble understanding your rationale. how is it breaking binary compatibility? is binary compatibility even an issue? shouldn't the host just look for the plugin and load it and check for the existence of a symbol, if it exists then call it, otherwise it doesn't and everything is just as it was. the host never need know anything about the binary structure of the plugin except to know that there's a function called ladspa_descriptor, adding ladgui certainly doesn't stop old hosts from loading and using the plugin, i've modified nekobee to use ladgui and it runs exactly as it used to in an unmodified rosegarden, so how is binary compatibilty an issue? whereas LV2 breaks compatibilty with old plugins (this seems like more of an issue to me), adds a lot of complexity and requires the host to use an additional liblv2 library. - Jez
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 01:55:27PM -0400, Dave Robillard wrote: API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h what i'd like to know is, if this is a stupid idea ^_^ The idea itself isn't stupid, but the implementation is.. let's say less than wise. (Consider my personal blatant bias, but...) I'd suggest taking a look at LV2. There is a data file you can add all this information to (whatever information you want to), without defining any APIs, changing any host code, etc, etc. The provisional LV2 spec is at http://lv2pluig.in/ it could do with some human language text explaining the technical parts, not just C and RDFS, but I think theres enough there to make sense of it. FWIW, I think the not changing any code thing is a blind, someone, somewhere has to change some code if you want new behaviour*. To me the critical thing is not that, but that a display function or whatever only solves half the problem. You would also like the app to be able to understand the control value and it's units. But I said that allready :) * though not if you don't which can be more of an advantage than you'd think. - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 10:34:05PM +0100, Steve Harris wrote: FWIW, I think the not changing any code thing is a blind, someone, somewhere has to change some code if you want new behaviour*. To me the critical thing is not that, but that a display function or whatever only solves half the problem. You would also like the app to be able to understand the control value and it's units. But I said that allready :) * though not if you don't which can be more of an advantage than you'd think. What worries me is that LV2 is *not* going to solve the problem that DR raised w.r.t. my Moog filter plugins. IIRC the control law is : f = pow (2, v) * frequency_of_middle_C or some such, where v is the parameter value. So the relation v-f is *exponential* (not logarithmic). Now in a sophisticated soft-synth, the control port could be connected to either: 1. another module: In that case the host needs to know the relation above. 2. a GUI widget: This may want to display the frequency either in musical terms, or in Hz. The relation widget_pos-v should be linear, while the relation displayed_frequency-v is logarithmic, using the inverse relation of the one above. 3. a MIDI controller: Since we are controlling a frequency, it would make sense to use MIDI note numbers. So the host needs to know that v = (n - 60) / 12.0f; 4. an OSC path: Here we would probably want the plain frequency as the OSC parameter value. So how are we going to tell this to the host ? I'm sure LV2 can _represent_ all of this, but representation is not the same as meaning. For the host to understand it, either - it has a degree in music science and DSP, - the meaning of the tags used is predefined by some standard. The latter is missing, and once it is defined the need for an 'open' representation format no longer exists. -- FA Follie! Follie! Delirio vano e' questo!
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 11:58:43PM +0200, Fons Adriaensen wrote: On Mon, Jun 19, 2006 at 10:34:05PM +0100, Steve Harris wrote: FWIW, I think the not changing any code thing is a blind, someone, somewhere has to change some code if you want new behaviour*. To me the critical thing is not that, but that a display function or whatever only solves half the problem. You would also like the app to be able to understand the control value and it's units. But I said that allready :) * though not if you don't which can be more of an advantage than you'd think. What worries me is that LV2 is *not* going to solve the problem that DR raised w.r.t. my Moog filter plugins. This particualr one I'm not worried about, as it's a know one, its all the subtle things noones realised yet, something like a plugin that does its delay in 24ths of a beat or something. IIRC the control law is : f = pow (2, v) * frequency_of_middle_C or some such, where v is the parameter value. So the relation v-f is *exponential* (not logarithmic). Sure, the LADSPA LOG hint couldn't deal with this meaningfully anyway. So how are we going to tell this to the host ? I'm sure LV2 can _represent_ all of this, but representation is not the same as meaning. For the host to understand it, either - it has a degree in music science and DSP, - the meaning of the tags used is predefined by some standard. Or both if you really mess up :) The latter is missing, and once it is defined the need for an 'open' representation format no longer exists. That's more-or-less true, but you can apply that argument repeatedly forever. I have many plugins that I would prefer to work this way, but LADSPA makes it tricky if you want to interoperate with most hosts. Consequenctly, I have given it some though. The representation I was thinking of was something like: :somePort lv2:unit unit:octavePitch ; lv2:baseFreq 264.0 . It's not beyond the realms of the possible to describe the mathematical relationship between the octave pitch unit and Hz, but it's probably excessive. Some organic chemists use an RDF schema that expresses conversions bewteen crazy chemical units, but I think its overkill for crazy DSP units. We only really care about frequency[/time] and ampltiude anyway ;) - Steve
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 11:25:52PM +0100, Steve Harris wrote: On Mon, Jun 19, 2006 at 11:58:43PM +0200, Fons Adriaensen wrote: What worries me is that LV2 is *not* going to solve the problem that DR raised w.r.t. my Moog filter plugins. This particualr one I'm not worried about, as it's a know one, its all the subtle things noones realised yet, something like a plugin that does its delay in 24ths of a beat or something. Aaarggghhh :-) So the relation v-f is *exponential* (not logarithmic). Sure, the LADSPA LOG hint couldn't deal with this meaningfully anyway. Not a problem. AFAIK, the hints do not describe the v-f mapping, but rather the one between the widget and v. It's plain linear in this case. - it has a degree in music science and DSP, - the meaning of the tags used is predefined by some standard. Or both if you really mess up :) I'd love a plugin host with a degree... :somePort lv2:unit unit:octavePitch ; lv2:baseFreq 264.0 . It's not beyond the realms of the possible to describe the mathematical relationship between the octave pitch unit and Hz, but it's probably excessive. A well-designed set of tags like the ones you show above would probably solve 99.9% of all cases. But you can't expect anyone to dream that up in a day. Which leads me to my main gripe with LV2: it was defined much too fast. In a normal RFC process, you present the problem, give interested parties at least a month to consider it and write something that exceeds the quality of a whim, and then take at least as much time to study the results and comment on them before anything is decided. -- FA Follie! Follie! Delirio vano e' questo!
Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data
On Tue, 2006-06-20 at 00:57 +0200, Fons Adriaensen wrote: It's not beyond the realms of the possible to describe the mathematical relationship between the octave pitch unit and Hz, but it's probably excessive. A well-designed set of tags like the ones you show above would probably solve 99.9% of all cases. But you can't expect anyone to dream that up in a day. Which leads me to my main gripe with LV2: it was defined much too fast. In a normal RFC process, you present the problem, give interested parties at least a month to consider it and write something that exceeds the quality of a whim, and then take at least as much time to study the results and comment on them before anything is decided. two points: 1) i think the LV2 scheme is designed to leave the tag namespace open, separating the basic design (plugin vs. metadata) from any specific metadata definition. this means that agreement is only needed on the infrastructure for the plugin/metadata design, not on what the metadata looks like. you can still have your month or two to figure out the correct metadata namespace. 2) LADSPA v2 has floundered for more than a year since the previous LAC BoF. i commend rather than criticize swh for stepping up doing something, because otherwise nothing would ever have been done.
Re: [linux-audio-dev] LADSPA 2 name
On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote: On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: ZAP Audio Plugins I like this one, especially if the R. Crumb reference is intentional hmm ZAP. not only the least offensive recursive acronym i've seen but it's also catchy, has one syllable and sounds like the ZAPP. infact, i reckon it has more bounce to the ounce. LV2 has non of the above but is also a good enough choice to my mind. =) pete. -- == paugh on irc.freenode.org in #sweep, #lad [EMAIL PROTECTED] ==
Re: [linux-audio-dev] LADSPA 2 name
On Fri, 2006-05-12 at 12:04 +0100, peter wrote: On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote: On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: ZAP Audio Plugins I like this one, especially if the R. Crumb reference is intentional hmm ZAP. not only the least offensive recursive acronym i've seen but it's Why was 'peep' offensive? urbandictionary was of no help. also catchy, has one syllable and sounds like the ZAPP. What's ZAPP? infact, i reckon it has more bounce to the ounce. LV2 has non of the above but is also a good enough choice to my mind. =) pete.
Re: [linux-audio-dev] LADSPA 2 name
Lee Revell wrote: On Fri, 2006-05-12 at 12:04 +0100, peter wrote: On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote: On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: ZAP Audio Plugins I like this one, especially if the R. Crumb reference is intentional hmm ZAP. not only the least offensive recursive acronym i've seen but it's Why was 'peep' offensive? urbandictionary was of no help. different kind of offensive. recursive acro's are often contrived and stretched to fit. peep isn't SO bad and it's even palindromic if you go in for that sort of thing but ZAP just seems to have a lot going for it where peep seems a bit laboured. also catchy, has one syllable and sounds like the ZAPP. What's ZAPP? 70-80's electro funk band. featuring a characteristic use of vocoders. more bounce to the ounce is probably their best known track. (features in la haine in the breakdancing scene if you've seen that. ) so uhm.. i like ZAPP and also like Z.A.P. the idea of a zap vocoder plugin seems a fitting tribute to the vocoder pioneers. not exactly relevant but i liked it enough to wade in on its behalf. :) infact, i reckon it has more bounce to the ounce. LV2 has non of the above but is also a good enough choice to my mind. =) pete.
Re: [linux-audio-dev] LADSPA 2 name
On Fri, 2006-05-12 at 22:39 +0100, pete wrote: Lee Revell wrote: On Fri, 2006-05-12 at 12:04 +0100, peter wrote: On Wed, 2006-05-10 at 07:07 -0400, Lee Revell wrote: On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: ZAP Audio Plugins I like this one, especially if the R. Crumb reference is intentional hmm ZAP. not only the least offensive recursive acronym i've seen but it's Why was 'peep' offensive? urbandictionary was of no help. different kind of offensive. recursive acro's are often contrived and stretched to fit. peep isn't SO bad and it's even palindromic if you go in for that sort of thing but ZAP just seems to have a lot going for it where peep seems a bit laboured. I don't like ZAP at all. Sounds silly and childish. /my2cents -DR-
Re: [linux-audio-dev] LADSPA 2 name
Hans Fugal escribe: What about Llama? The (Llinux|Llibre) Audio Modules Architecture, or just a cool animal that has Ls and As in the name. Then we would be faced against a very popular Win32 application that shouts Winamp, it really whips the Llama's ass! (Even though I admit I like the name!) BTW are we talking of an architecture deeply Linux-related? I mean, is it completely out of scope compiling hosts and plugins over Windows, Mac OS X or any of the BSDs? In that case I'd focus to the libre concept and not to the linux concept. My two euro cents. :) Cordially, Ismael -- Ismael Valladolid Torres OpenPGP key ID: 0xDE721AF4 [^[$B$?$S$?$S$9$_$^$;$s^[(B] Jabber ID: [EMAIL PROTECTED] http://lamediahostia.blogspot.com =?iso-2022-jp?B?GyJE0hREjAGyhC?=
RE: [linux-audio-dev] LADSPA 2 name
Dave Phillips wrote: If I recall correctly LV2 was the rock that the Nostromo set down on (in the movie Alien). So it's cool with me. :) Actually that was LV4-26, but it's still cool ;)
Re: [linux-audio-dev] LADSPA 2 name
On Wed, May 10, 2006 at 07:12:33 +0200, Esben Stien wrote: Steve Harris [EMAIL PROTECTED] writes: LV2 What happened to the funny recursive acronyms?;). That they don't show up in a google search don't hold water; f.ex a search for JACK get you.. our beloved, sacred one. They seem to be too much a matter of taste, and/or have negative connotations in various languages. Trying to get everyone to agree on one is just too much effort. Feel free to try and get consensus on a word-like name, but I've lost all enthusiasm for it. I think it's telling that the hardest part of this whole process has been choosing a name, classic colour of the bikeshed problem. You can argue that the name is important, but we've been happily using LADSPA for years, and that's terrible by alomost any metric. I've started using the name LV2 myself, if it doesn't annoy me within a week or so, and no-one comes up with a sensible objection it will probably become permenant. So, if you really hate it speak up now. Nothing beats daves' PEEP in any case..;) Someone was allready using it for a free software project, and it's visually too close to BEEP which is a widely used protocol library. - Steve
Re: [linux-audio-dev] LADSPA 2 name
[EMAIL PROTECTED] wrote: Dave Phillips wrote: If I recall correctly LV2 was the rock that the Nostromo set down on (in the movie Alien). So it's cool with me. :) Actually that was LV4-26, but it's still cool ;) Yep, you right. Rats, I really wanted it to be that rock... :) Best, dp
Re: [linux-audio-dev] LADSPA 2 name
Steve Harris [EMAIL PROTECTED] writes: if you really hate it speak up now. BEAP Environment for Audio Plugins BAM Audio Mangling ZAP Audio Plugins A brainstorm on KLANK, PLOINK, SPLAT, SPLASH, BANG, KABOOM, CRASH, etc;) A name means a lot, in my opinion. It's about taking care of every corner case;). -- Esben Stien is [EMAIL PROTECTED] s a http://www. s tn m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@n n
Re: [linux-audio-dev] LADSPA 2 name
On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: ZAP Audio Plugins I like this one, especially if the R. Crumb reference is intentional
Re: [linux-audio-dev] LADSPA 2 name
Lee Revell [EMAIL PROTECTED] writes: On Wed, 2006-05-10 at 14:55 +0200, Esben Stien wrote: ZAP Audio Plugins I like this one, especially if the R. Crumb reference is intentional He he, ZAP has in the 90s also been the name of a german Hardcore/Punk Fanzine. Matthias
Re: [linux-audio-dev] LADSPA 2 name
On Tue, May 09, 2006 at 09:59:53AM +0100, Steve Harris wrote: But I like the idea. LV2 is less taken. Early work on the all important logo ;) http://affenbande.org/~thorwil/wordpress/2006/05/10/lv2-ladspa-2/ http://affenbande.org/~thorwil/wordpress/2006/05/10/lv2-ladspa-version-2-continued/ Not that I would want to push you in any direction ;) Cheers, Thorsten Wilms
Re: [linux-audio-dev] LADSPA 2 name
LAMA - Linux(Libre) Audio Modules Architecture I hope The Dalai Lama will not object.
Re: [linux-audio-dev] LADSPA 2 name
On Wed, May 10, 2006 at 08:16:04PM +0400, Dmitry Baikov wrote: LAMA - Linux(Libre) Audio Modules Architecture I hope The Dalai Lama will not object. Good name, but theres a well known VST plugin called Delay Lama. - Steve
Re: [linux-audio-dev] LADSPA 2 name
What about Llama? The (Llinux|Llibre) Audio Modules Architecture, or just a cool animal that has Ls and As in the name. The Delay Lama is obviously named after the Dalai Lama, I don't think there would be any serious confusion. Maybe someone would write a Delay Lama lama plugin too. ;-) On Wed, 10 May 2006 at 17:19 +0100, Steve Harris wrote: On Wed, May 10, 2006 at 08:16:04PM +0400, Dmitry Baikov wrote: LAMA - Linux(Libre) Audio Modules Architecture I hope The Dalai Lama will not object. Good name, but theres a well known VST plugin called Delay Lama. - Steve -- Hans Fugal ; http://hans.fugal.net There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Johann Sebastian Bach signature.asc Description: Digital signature
Re: [linux-audio-dev] LADSPA 2 name
Dave Robillard wrote: I like LV2. Bit of a mouthful when spoken, but then so is VST. If I recall correctly LV2 was the rock that the Nostromo set down on (in the movie Alien). So it's cool with me. :)
Re: [linux-audio-dev] LADSPA 2 name
Steve Harris [EMAIL PROTECTED] writes: LV2 What happened to the funny recursive acronyms?;). That they don't show up in a google search don't hold water; f.ex a search for JACK get you.. our beloved, sacred one. How about a girlie name to accompany JACK, then?;) Nothing beats daves' PEEP in any case..;) -- Esben Stien is [EMAIL PROTECTED] s a http://www. s tn m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@n n
[linux-audio-dev] LADSPA 2 name
Hi! Requirements in order of importance, highest first: - not likely to get us into legal trouble - no too obvious negative interpretations/associations (too obvious because it's too hard, internationaly, otherwise) - no conflict with established open source projects - easy to search for Pretty much every 3 letter combo is in use by some company or institute. Few are pronounceable. It's similar with 4 letters. Suggestions with few (and not relevant looking) or no Google hits: splugs - stream processing plugins sppib - stream processing plugins in bundles laspib - linux audio ... buspp - bundled stream processing plugins streamins - streaming/stream-processing plugins sprocins - stream processing plugins [Streaming because there are continuous i/o streams of data as far as I understand, while there's no limitation to audio/float anymore. Corect me if I'm wrong.] Cheers, Thorsten Wilms
Re: [linux-audio-dev] LADSPA 2
On Tue, May 02, 2006 at 03:49:59 -0400, Dave Robillard wrote: Further, you can't really remove all of this data. Most of it will be required by the plugin code itself, and you can't expect it to go and read it from the RDF. Since the plugin author writes both and they are strongly associated with (and depend on) each other, the plugin can 'assume' eg. the type of it's ports. Plugin code definitely won't be reading the RDF file.S I've not yet seen a plugin that introspects its own port hints either, but don't take that as a challenge ;) - Steve
Re: [linux-audio-dev] LADSPA 2
On Tue, 2006-05-02 at 20:32 +0100, Steve Harris wrote: On Tue, May 02, 2006 at 03:49:59 -0400, Dave Robillard wrote: Further, you can't really remove all of this data. Most of it will be required by the plugin code itself, and you can't expect it to go and read it from the RDF. Since the plugin author writes both and they are strongly associated with (and depend on) each other, the plugin can 'assume' eg. the type of it's ports. Plugin code definitely won't be reading the RDF file.S I've not yet seen a plugin that introspects its own port hints either, but don't take that as a challenge ;) I suppose it does have a path to it's own bundle, and could theoretically parse manifest.ttl to find it's own data file and do what it wants with it. But.. I mean... just.. no! :) (I did actually consider adding plugin-side hooks to my ladspa2 library but decided against it) -- Speaking of the library, status update: I have successfully processed data with the example plugin in about 5 lines of C code. Plugins can be 'loaded' with one LOC using only the URI (finding and loading the plugin is all automagic), and instantiated with one more LOC. -DR-
[linux-audio-dev] LADSPA 2 name
Several people have suggested that LADSPA is not a great name for what we
are calling LADSPA 2. Reasons for this include:
The L, it's not really linux specific, and though /we/ know that its the L
of LAD, its not obvious to people outside.
The S, it ain't really going to be simple. For someone like me, who is
neck deep in triples on a daily basis, 2.0 seems like the paragon of
simplicity, but I can imagine 2.9 being quite a beast.
LADSPA, (pron. ladspuh?) is a bit of a mouthful, and not exactly catchy.
2.0, it's not going to be obvious to all users that 2.0 and 1.0 are binary
incompatible. I'm not sure everyone thinks in major and minor revisions.
So, with some trepidation I suggest that we think about naming, with the
proviso that if we haven't reached consensus by May 10th we default to
LADSPA 2.0, and live with the pain.
My suggestion is that we ressurect the XAP name
(http://www.google.com/search?q=lad+xap)
It stood for Xap Audio Plugin IIRC.
Pros: it's short*, relatively unused** and pronouncable***
Cons: xap.{com,org,net} will have gone long ago (too short), theres a
small ammount of baggage.
- Steve
* I've typed LADSPA_ a lot
** There is a home automaption protocol, called xAP that takes
plugin modules. Though I think we started using the name around the
same time, they seem like nice people and we should OK it with them.
*** zap@en-gb
Re: [linux-audio-dev] LADSPA 2 name
Quoting Steve Harris [EMAIL PROTECTED]:
My suggestion is that we ressurect the XAP name
(http://www.google.com/search?q=lad+xap)
It stood for Xap Audio Plugin IIRC.
Pros: it's short*, relatively unused** and pronouncable***
More pros: we would have a VST -alike logo already! (looking at
http://xap-plugins.org/artwork.html).
And it's not too VST -alike, as XAP doesn't share a single letter with VST.
Cons: xap.{com,org,net} will have gone long ago (too short), theres a
small ammount of baggage.
I think we would select a short name anyway. Most of them are gone already,
so we have the same problem whichever [a-z][a-z][a-z] we select :)
Sampo
Re: [linux-audio-dev] LADSPA 2 name
On Wed, Apr 26, 2006 at 11:10:02 +0300, Sampo Savolainen wrote: Quoting Steve Harris [EMAIL PROTECTED]: My suggestion is that we ressurect the XAP name (http://www.google.com/search?q=lad+xap) It stood for Xap Audio Plugin IIRC. Pros: it's short*, relatively unused** and pronouncable*** More pros: we would have a VST -alike logo already! (looking at http://xap-plugins.org/artwork.html). Indeed. I forgot to add, we also need to ask David's permission to reuse the name, seen as it was largely his baby. - Steve
Re: [linux-audio-dev] LADSPA 2
don't think that the string is needed I think that's fair. One version number should be enough though, and it doesn't have to match the actual version of the LADSPA spec Both those points (especially the second) sound simple and sensible. Okay, so on reflection... There's a case to be made that some version information ought to go into the struct, since it directly affects how the struct may be properly accessed. There are two case where you would need version information to correctly access the struct. 1) A future version extends the struct. (does not break backwards compatibility) version information is needed so that eg. a 2.1 host does not try to use 2.1 functionality in a 2.0 plugin. 2) A future version modifies the struct. (breaking backwards compatibility) case 2) is very unlikely to occur anytime soon, so let's just forget about that (it can be solved by using a new discovery function anyhow) case 1) could most simply be addressed like this: The struct starts with a single unsigned short. The host must check the version number at the start... If the plugin version = host version: No problem - the host knows it's functionality is fully supported. If the plugin version host version: The host may access the plugin normally and is aware of what functionality the plugin does not support. Why is this useful? Well, it provides a _built-in_ way of ensuring that the struct is properly accessed, even if the metadata file is corrupted or lost. Say a user meddles with the metadata file to make a 2.0 plugin look like a 2.1 plugin. The host attempts to access 2.1 functionality and core dumps. Say the metadata file has been lost - the plugin contains sufficient information to remain accessible although it no longer has any associated metadata. I realise that the LADSPA library should mostly enforce keeping things okay, but it seems like a nice idea to have a protected way of making sure that we don't accidentally attempt to access invalid memory when things go wrong. I would suggest then: A single unsigned short at the start of the struct, starting at '0' for ladspa 2.0 plugins and incrementing if and when the struct is extended. The LADSPA major and minor versions would stay in the metadata. Any milege in this?...
Re: [linux-audio-dev] LADSPA 2
On Tue, 25 Apr 2006 22:55:55 -0400 Paul Davis [EMAIL PROTECTED] wrote: it takes *way* more lines of code than that to use a ladspa plugin in this way, and thats for the existing header-only specification. one the design goals of a good plugin API is to make life simple for plugins, because there are lots of them and presumably quite a few authors too, at a certain expense to hosts, because there are relatively few of them and their authors are likely to be more skilled at what they are doing. there are lots of little gotchas even with the amazingly simple API that LADSPA 1 represents, and quite a few of these will become simpler or will vanish with the metadata scheme that steve has outlined. Erm, just to voice my opinion on this LADSPA 2 thing i kinda hijack your post to Vote++; @Phil: Look at the example plugin. Life does get easier with this. Flo -- Palimm Palimm! http://tapas.affenbande.org
Re: [linux-audio-dev] LADSPA 2 name
On Wed, 2006-04-26 at 07:23 +0100, Steve Harris wrote:
Several people have suggested that LADSPA is not a great name for what we
are calling LADSPA 2. Reasons for this include:
The L, it's not really linux specific, and though /we/ know that its the L
of LAD, its not obvious to people outside.
The S, it ain't really going to be simple. For someone like me, who is
neck deep in triples on a daily basis, 2.0 seems like the paragon of
simplicity, but I can imagine 2.9 being quite a beast.
LADSPA, (pron. ladspuh?) is a bit of a mouthful, and not exactly catchy.
2.0, it's not going to be obvious to all users that 2.0 and 1.0 are binary
incompatible. I'm not sure everyone thinks in major and minor revisions.
So, with some trepidation I suggest that we think about naming, with the
proviso that if we haven't reached consensus by May 10th we default to
LADSPA 2.0, and live with the pain.
My suggestion is that we ressurect the XAP name
(http://www.google.com/search?q=lad+xap)
It stood for Xap Audio Plugin IIRC.
Pros: it's short*, relatively unused** and pronouncable***
I know it's stupid, but starting with X has the same problem as
starting with G and K. Seeing XAP out of context, people will
default to thinking it's some X related technology.
Cons: xap.{com,org,net} will have gone long ago (too short), theres a
small ammount of baggage.
It would be very nice if we could get the specname.org domain, to
provide stable resolvable plugin URIs for plugins for authors that don't
have nice spiffy domains of their own...
Then again, domains aren't free, and I know I'm not paying for it. :)
-DR-
Re: [linux-audio-dev] LADSPA 2
On Wed, 2006-04-26 at 10:38 +0100, Steve Harris wrote: This is why the plugin is really a directory, all the stuff in there is neccesary. On the plugin bundle thing, I've got working C code that takes a path to the directory, parses manifest.ttl, gleams the available plugin DLLs and data files from that, and enumerates all the plugins in the DLL. We need to clarify some things about bundles themselves: - What is the significance of the bundle name itself? (We need to avoid clashes somehow) - Do they contain one plugin variant, or any number? - One DLL or many? - What's the relation between the two above points? I'm not sure about number-of-plugins-per-bundle (though putting all of, say, swh-plugins in one bundle seems counter to the intent to me?) but I will suggest we reccommend that one DLL contains only variants of one plugin (or a group of very similar plugins). Reasoning is to avoid things like cmt.so which has a huge number of completely unrelated plugins in one lib, meaning a host has to link in all that crap just to use a simple amplifier plugin, which is no good. -DR-
Re: [linux-audio-dev] LADSPA 2
That's somewhat like saying a corrupt binary should never cause a segfault... No, not at all. The data file is accessed as an input stream (to the host / LADSPA library). It's fine for a bad data file to cause the library to fail to be able to load it, or to load it and produce unexpected output, but it should *never* cause it to segfault. No-ones seriously interested in guarding against the caes where the .so is corrupt. Agreed, and neither am I. All I'm saying is that if the discovery function may potentially return differing structs from one LADSPA version to another, then it ought also provide a mechanism of determining exactly which struct it is returning. If it does that, then the worst that can ever happen is that the binary is accessed with duff input (no segfaulting). Okay, I really will shut it now, I begin to suspect I'm labouring the point :) t.
Re: [linux-audio-dev] LADSPA 2
On Wed, Apr 26, 2006 at 05:48:32PM +0100, tom christie wrote: That's somewhat like saying a corrupt binary should never cause a segfault... No, not at all. The data file is accessed as an input stream (to the host / LADSPA library). It's fine for a bad data file to cause the library to fail to be able to load it, or to load it and produce unexpected output, but it should *never* cause it to segfault. the only situation it can cause a segfault is where its mangled in a somehow still structurally and syntaxically correct way (too unlikly to be worth considering) or if the host pushes on without enough information. The point I was making is that you will get segfaults if you try to us the struct without the data, even if you know the version number, so dont. All I'm saying is that if the discovery function may potentially return differing structs from one LADSPA version to another, then it ought also provide a mechanism of determining exactly which struct it is returning. Sure, but its easier to version the struct in the data. - Steve
Re: [linux-audio-dev] LADSPA 2
On Wed, 2006-04-26 at 17:55 +0100, Steve Harris wrote: On Wed, Apr 26, 2006 at 05:48:32PM +0100, tom christie wrote: That's somewhat like saying a corrupt binary should never cause a segfault... No, not at all. The data file is accessed as an input stream (to the host / LADSPA library). It's fine for a bad data file to cause the library to fail to be able to load it, or to load it and produce unexpected output, but it should *never* cause it to segfault. the only situation it can cause a segfault is where its mangled in a somehow still structurally and syntaxically correct way (too unlikly to be worth considering) or if the host pushes on without enough information. The point I was making is that you will get segfaults if you try to us the struct without the data, even if you know the version number, so dont. All I'm saying is that if the discovery function may potentially return differing structs from one LADSPA version to another, then it ought also provide a mechanism of determining exactly which struct it is returning. Sure, but its easier to version the struct in the data. Thinking about this I was worried about parallel installed multiple versions of the same plugin, but as long as the URI refers to a compatible version of the plugin, we don't need versioning in the struct itself, since the URI between two versions of a plugin (one of which is LADSPA2.0 and one which is binary incompatible LADSPA2.2 or whatever) must change since it's incompatible, right? We need to make absolutely sure multiple versions of a plugin can be installed at once, including new incompatible versions of the spec, is my point. I /think/ it's okay as stands though. -DR-
Re: [linux-audio-dev] LADSPA 2
On Wed, 2006-04-26 at 06:48 +0100, Steve Harris wrote: if it never refuses then its ok with me ;) It's certainly allowed to refuse, it would just be bad manners, unless the host has ignored the required features list. so required features have to be checked on both sides. isn't that redundant? furthermore, surely there are other reasons why instantiation could fail. how can the host determine the reason for which a plugin refused to instantiate? thats platform specific though, seems like the plugins shouldn't be full of #ifdef WIN32 ... code. yes, of course, that would be nonsense. but in case there is a posix equivalent, it will be available on win32 as well. but i dont know anything more about this. alternatively the host could be required to chdir to the bundle folder before the plugin is being instantiated? Thats likely to cause all manner of excitement. the erotic kind of excitement? ;) -- -- leonard paniq ritter -- http://www.mjoo.org -- http://www.paniq.org
Re: [linux-audio-dev] LADSPA 2 name
On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote: I think we would select a short name anyway. Most of them are gone already, so we have the same problem whichever [a-z][a-z][a-z] we select :) XAP suggests this could be an XML document type. what about FAP (FAP Audio Plugin)? GO FAP! FAP FAP FAP! i also would like CLAP. :) -- -- leonard paniq ritter -- http://www.mjoo.org -- http://www.paniq.org
Re: [linux-audio-dev] LADSPA 2 name
SAX? (Simple Audio eXtensions) Yup, it names also the XML parser, but it is music related. Incidentally, at some point in the near future it will be possible to register .ax domain names, don't know under which conditions. http://en.wikipedia.org/wiki/.ax CHAP? (Cunningly Hacked Audio Plugins) WASAP? (Widely Acknowledged Simple Audio Plugins) wasap.org is available. Cheers, Luis
Re: [linux-audio-dev] LADSPA 2 name
On Wed, Apr 26, 2006 at 02:03:38PM -0400, Dave Robillard wrote: On Wed, 2006-04-26 at 20:09 +0200, Leonard paniq Ritter wrote: On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote: I think we would select a short name anyway. Most of them are gone already, so we have the same problem whichever [a-z][a-z][a-z] we select :) XAP suggests this could be an XML document type. what about FAP (FAP Audio Plugin)? RAP - Recursively Acronym'd Plugin Thats the kind of suggestion that makes non-free software developers think were all pissing about. But I still dont like it that much ;) EEP - Extensible Environment for Plugins? PEEP - Portable ... MEEP - Multiplatform ... Sadly BEEP has gone :( - Steve
Re: [linux-audio-dev] LADSPA 2 name
On Wed, Apr 26, 2006 at 08:10:23PM +0200, Luis Garrido wrote: SAX? (Simple Audio eXtensions) Yup, it names also the XML parser, but it is music related. Incidentally, at some point in the near future it will be possible to register .ax domain names, don't know under which conditions. I quite like that. Not too keen on Simple, but SAX is a good TLA. Software Audio eXtensions? http://en.wikipedia.org/wiki/.ax Doesn't look like .ax domains are open to non-residents. There are other things we can get though. - Steve
Re: [linux-audio-dev] LADSPA 2
On Wed, 2006-04-26 at 19:06 +0100, Steve Harris wrote: On Wed, Apr 26, 2006 at 11:18:13AM -0400, Dave Robillard wrote: On Wed, 2006-04-26 at 10:38 +0100, Steve Harris wrote: This is why the plugin is really a directory, all the stuff in there is neccesary. On the plugin bundle thing, I've got working C code that takes a path to the directory, parses manifest.ttl, gleams the available plugin DLLs and data files from that, and enumerates all the plugins in the DLL. It shouldn't be neccesary to actually dlload() the .so file, if it is then theres a mistake somewhere. Sorry, to be clearer loading the DLL was my goal (not the means towards enumerating the available plugins). Enumerating what indexes ladspa_descriptor returns is just what I happened to write to be sure I really did load the DLL successfully. We need to clarify some things about bundles themselves: - What is the significance of the bundle name itself? (We need to avoid clashes somehow) Yes, its a bit awkward. It would be nice to be able to use URIs, but thats not going to wash. I was planning something like [abbreviated plugin name]-[collection name].whatever/ eg. Amp-swh.ladspa2 Assuming the number of collections doesnt grow to much, the current thing of people using thier initials or similar should work fine. The maintainer of each colleaction is responsible for making sure noone else uses the same collection name, and that none of thier abbreviated names collide. If we wanted to go overboard we could do something like [abbreviated plugin name]-[64bit hash of URI of one plugin].whatever/ eg. amp-5491370f050fa849.ladspa2/ which guarantees uniqueness, but its a bit of a pain, and the plugin bundle names will be a bit ugly. That is overboard, but I guess there's no real good solution to this that doesn't involve having a URI of some variety as the name, which is far too ugly. We do need to prevent people from doing stupid things like calling the directory amp though, so at least a recommendation in the spec is in order. - Do they contain one plugin variant, or any number? Probably leave it as a matter of taste. Though discouraging the cmt thing is a good idea IMHO. - One DLL or many? As many as you want / need. I'm not sure about number-of-plugins-per-bundle (though putting all of, say, swh-plugins in one bundle seems counter to the intent to me?) but I will suggest we reccommend that one DLL contains only variants of one plugin (or a group of very similar plugins). Reasoning is to avoid things like cmt.so which has a huge number of completely unrelated plugins in one lib, meaning a host has to link in all that crap just to use a simple amplifier plugin, which is no good. My intention was to have a pretty much 1:1 correspondance between .so's I have now and bundles in the future. ie. most plugins are on thier own, but logically grouped ones are in one .so. eg. a buch ov very similar oscialltors, filters etc. The way your plugins are divvied up is fine, but: I dont think its neccesary to specify this though, the best natural level usually settles out. ie. people see cmt.so, and go arrrghhh!. They go aggghhh, but cmt.so remains with no settling in sight :) I guess in the interests of defining as little as neccessary, it should go unspecified (though as above a recommendation would be good). Large bundles are okay because they ease the burden on the user, but I don't see any benefit of a huge chunk of completely unrelated plugins being in one .so As long as we have this nice bundle format, I suppose both a LADSPA repo site and a 'master package' of all LADSPA plugins can exist (both things that are requested pretty often), though they would only be able to usefully distribute binary builds, not source. :/ This is why I'm tempted to suggest that a bundle only contains related plugins, so a user could easily just install the SWH amp (say on a resource limited system). There's a lot of plugins out there that are totally useless for some people, it would be nice if /users/ could decide what plugins they want installed. But then of course the directory name problem becomes a bigger one that'd need to be solved properly.. -DR-
Re: [linux-audio-dev] LADSPA 2 name
On Wed, 2006-04-26 at 19:13 +0100, Steve Harris wrote: On Wed, Apr 26, 2006 at 02:03:38PM -0400, Dave Robillard wrote: On Wed, 2006-04-26 at 20:09 +0200, Leonard paniq Ritter wrote: On Wed, 2006-04-26 at 11:10 +0300, Sampo Savolainen wrote: I think we would select a short name anyway. Most of them are gone already, so we have the same problem whichever [a-z][a-z][a-z] we select :) XAP suggests this could be an XML document type. what about FAP (FAP Audio Plugin)? RAP - Recursively Acronym'd Plugin Thats the kind of suggestion that makes non-free software developers think were all pissing about. That's a good thing, right? EEP - Extensible Environment for Plugins? PEEP - Portable ... MEEP - Multiplatform ... PEEP - Palindromic Extensible Environment for Plugins :) -DR-
Re: [linux-audio-dev] LADSPA 2 name
SAX: Sexy Audio eXtensions (or just make it recursive (TM)) APE: Audio Pluggable Extensions (not my favorite: there is already an important audio application that uses the term and I cringe thinking of the simian lingo that is going to develop around it, but well...) PEA: Pluggable Extensions for Audio. Luis
Re: [linux-audio-dev] LADSPA 2 name
On Wed, 2006-04-26 at 14:58 -0400, Dave Robillard wrote: PEEP - Palindromic Extensible Environment for Plugins or PEEPER Extensible Environment for Plugins, Entitled Recursively 10 points to anyone who can fit both Palindromic and Recursive in there. ;) -DR-
Re: [linux-audio-dev] LADSPA 2 name
On Wed, Apr 26, 2006 at 07:13:23PM +0100, Steve Harris wrote: Thats the kind of suggestion that makes non-free software developers think were all pissing about. But I still dont like it that much ;) EEP - Extensible Environment for Plugins? PEEP - Portable ... MEEP - Multiplatform ... Sadly BEEP has gone :( - Steve I already have a linux audio project going with a friend called meep. http://home.in.tum.de/~kluegel/static.php?page=static060308-162614 You can't have it ;)
Re: [linux-audio-dev] LADSPA 2 name
On Wed, 2006-04-26 at 17:48 +0100, Steve Harris wrote: Then again, domains aren't free, and I know I'm not paying for it. :) If we can find one thats not too expensive I'll pick up the tab. - Steve If you can put up with not beeing the root domain, you could get somthing like [ladspa|xap|apa].linux.dk for free -- mvh // Jens M Andreasen
Re: [linux-audio-dev] LADSPA 2 name
Dave Robillard [EMAIL PROTECTED] writes: PEEP - Palindromic Extensible Environment for Plugins This is a very good one;). PEEP Extensible Environment for Plugins -- Esben Stien is [EMAIL PROTECTED] s a http://www. s tn m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@n n
Re: [linux-audio-dev] LADSPA 2 name
On Wed, Apr 26, 2006 at 10:29:16 +0200, Jens M Andreasen wrote: On Wed, 2006-04-26 at 17:48 +0100, Steve Harris wrote: Then again, domains aren't free, and I know I'm not paying for it. :) If we can find one thats not too expensive I'll pick up the tab. - Steve If you can put up with not beeing the root domain, you could get somthing like [ladspa|xap|apa].linux.dk for free Thanks, but, I'll register something under a TLD, I have some ideas... the thing I really want is for sale, but they want EUR10,000, which is too much. FWIW, my current favourite is SAX. Musical connotations, short, name collisions not too serious. - Steve
Re: [linux-audio-dev] LADSPA 2
On Mon, Apr 24, 2006 at 04:12:11 -0400, Jesse Chappell wrote: On 4/24/06, tom christie [EMAIL PROTECTED] wrote: In the former, any change in the descriptor structure will always break backwards compatibility. In the later, new functions can extend the core functionality without breaking backwards compatibility in any way. Actually, just adding a large-ish chunk of reserved padding at the end of the descriptor struct can accomplish the same goal, as long as you are only adding new functions to the API. That, along with a version field also in the struct. The pluin is responsibe for allocating the descriptor, so its not neccesary to add padding. - Steve
Re: [linux-audio-dev] LADSPA 2
Okay, I ought to have qualified my 'will always break...' that's clearly not true. But there is still real inflexibility in using a struct based API. eg. Say a developer comes up with a nice extension (perhaps to allow a plugin to deal with multi-channel IO / non-causal audio effects / alter the audio frequency / support an 'end of stream' marker / midi / GUI / accessing metadata via function calls / or whatever...) With the struct based API the only way(*) for that extension to make it into LADSPA is for it to be part of the the struct in the next version of LADSPA. We want to keep LADSPA simple, so that's unlikely to happen. With the library call based API the developer defines and advertises the functions that make up the extension, and if it is useful hosts will start to implement it. If it proves it's worth it can be adopted as an official LADSPA *extension*, which hosts can choose (or not) to implement. The core API remains simple and unbloated, but LADSPA can still develop. (*) Yes there is trickery that could be played with, eg. using multiple discovery functions, but that's just icky.
Re: [linux-audio-dev] LADSPA 2
Sorry, I just dont feel that motivated by this. We have a bunch of code and experience around the struct format, and we know were going to need something equivalent for the forseeable future, so I dont see the point in changing it over just for the sake of it. Sure, for some possible future ABI-incomaptible extension we might want to add functions, but equally we might not. - Steve On Tue, Apr 25, 2006 at 11:28:47AM +0100, tom christie wrote: Okay, I ought to have qualified my 'will always break...' that's clearly not true. But there is still real inflexibility in using a struct based API. eg. Say a developer comes up with a nice extension (perhaps to allow a plugin to deal with multi-channel IO / non-causal audio effects / alter the audio frequency / support an 'end of stream' marker / midi / GUI / accessing metadata via function calls / or whatever...) With the struct based API the only way(*) for that extension to make it into LADSPA is for it to be part of the the struct in the next version of LADSPA. We want to keep LADSPA simple, so that's unlikely to happen. With the library call based API the developer defines and advertises the functions that make up the extension, and if it is useful hosts will start to implement it. If it proves it's worth it can be adopted as an official LADSPA *extension*, which hosts can choose (or not) to implement. The core API remains simple and unbloated, but LADSPA can still develop. (*) Yes there is trickery that could be played with, eg. using multiple discovery functions, but that's just icky.
Re: [linux-audio-dev] LADSPA 2
Sorry, I just dont feel that motivated by this. No problem :) just wanted to know if anyone else thought it was an important point. Two other concerns... A) There is no built-in way of a host distinguishing between a LADSPA 1.1 and a LADSPA 2.x plugin. (Unless I'm missing something?) Would it make sense to change the name of the discovery function? eg... ladspa2_descriptor() instead of ladspa_descriptor() That way there's no chance of a 2.0 host thinking it has a 2.0 plugin when in fact it has a 1.1 plugin. (Or vice versa with a 1.1 host) Either case would cause the host to crash when it calls the instantiate() function. B) There is no way of a host distinguishing between a LADSPA 2.x and a LADSPA 2.y plugin. Would it make sense for the initial few bytes of the struct to explicitly declare that this really is a LADSPA struct and give the major and minor versions for which it was written? This would allow the struct to change in the future if neccessary without breaking things and without needing to change the name of the discovery function again. char ladspa_string[7]; // plugin must set this to LADSPA\0 unsigned short major_version; // plugin must set this to 2 unsigned short minor_version; // plugin must set this to 0 The host should check for the null terminated LADSPA string, and should ensure that it's version is less than or equal that which the host supports before attempting to access the plugin. thoughts?... On 4/25/06, Steve Harris [EMAIL PROTECTED] wrote: Sorry, I just dont feel that motivated by this. We have a bunch of code and experience around the struct format, and we know were going to need something equivalent for the forseeable future, so I dont see the point in changing it over just for the sake of it. Sure, for some possible future ABI-incomaptible extension we might want to add functions, but equally we might not. - Steve On Tue, Apr 25, 2006 at 11:28:47AM +0100, tom christie wrote: Okay, I ought to have qualified my 'will always break...' that's clearly not true. But there is still real inflexibility in using a struct based API. eg. Say a developer comes up with a nice extension (perhaps to allow a plugin to deal with multi-channel IO / non-causal audio effects / alter the audio frequency / support an 'end of stream' marker / midi / GUI / accessing metadata via function calls / or whatever...) With the struct based API the only way(*) for that extension to make it into LADSPA is for it to be part of the the struct in the next version of LADSPA. We want to keep LADSPA simple, so that's unlikely to happen. With the library call based API the developer defines and advertises the functions that make up the extension, and if it is useful hosts will start to implement it. If it proves it's worth it can be adopted as an official LADSPA *extension*, which hosts can choose (or not) to implement. The core API remains simple and unbloated, but LADSPA can still develop. (*) Yes there is trickery that could be played with, eg. using multiple discovery functions, but that's just icky.
Re: [linux-audio-dev] LADSPA 2
On Tue, Apr 25, 2006 at 05:40:59PM +0100, tom christie wrote: Sorry, I just dont feel that motivated by this. No problem :) just wanted to know if anyone else thought it was an important point. Two other concerns... A) There is no built-in way of a host distinguishing between a LADSPA 1.1 and a LADSPA 2.x plugin. (Unless I'm missing something?) I was imagining they would be in a different path, and as they will be in .ladspa2 directories, and the .so files are discoverable via the RDF manifest, theres no real reason why you would find one and not be sure what version it was, however... Would it make sense to change the name of the discovery function? eg... ladspa2_descriptor() instead of ladspa_descriptor() That way there's no chance of a 2.0 host thinking it has a 2.0 plugin when in fact it has a 1.1 plugin. (Or vice versa with a 1.1 host) Either case would cause the host to crash when it calls the instantiate() function. Right, I can't see any reason not to do this. B) There is no way of a host distinguishing between a LADSPA 2.x and a LADSPA 2.y plugin. Would it make sense for the initial few bytes of the struct to explicitly declare that this really is a LADSPA struct and give the major and minor versions for which it was written? This would allow the struct to change in the future if neccessary without breaking things and without needing to change the name of the discovery function again. char ladspa_string[7]; // plugin must set this to LADSPA\0 unsigned short major_version; // plugin must set this to 2 unsigned short minor_version; // plugin must set this to 0 I made a version of the .h that does this (the version thing, not the header), but I couldn't think if any cases where it was useful - if it gets as far as the time you fetch the descriptor from the .so before you find out what the version is thats problaby a mistake. You should be able to reject descriptors you cant handle before that stage, otherwise it will annoy users. user: I want that one, host: oh, sorry, I dont understand it One of my aims for LADSPA 2 is to remove the need to dlload the plugin (expensive in CPU+memory, potentially dangerous) until you need to pass data through it. - Steve
Re: [linux-audio-dev] LADSPA 2
Ok, some thoughts about the headerfile: - i would find it helpful if the header also contained a definition of a valid LADSPA URI, along with some examples. - passing the HostFeatures in instantiate is a bit too late. i wouldnt want to instantiate a plugin first to find out if they match i.e. when i enumerate plugins to display them in a menu. furthermore i'm not sure if it is an audio plugins duty to check the validity of a host. rather the host should analyze a static string pointed member containing required host features. this way the host programmer can choose the quickest method to do a match check. at least i think so. - why does the plugin require its own bundle path for instantiation? this can usually be deduced from the dl's own runtime image information, no? otherwise, an explanation of this choice in the comment would be nice. - comments still contain references to set_run_adding_gain - LADSPA is an ugly name ;) after reading this i do not see why a new ladspa header is required. there are barely any changes in 2. i think this is going to become more confusing than helpful, especially since it will not be possible to load ladspa 1+2 plugins in the same host with ease (yes, people do not like to fix orphaned code and recompile binaries, imagine!). furthermore, DSSI builds upon ladspa. a ladspa 2 enforces also a DSSI 2. again, looking at the slight changes that ladspa underwent, i dont see what the big fuzz is about. grumpily yours, -- -- leonard paniq ritter -- http://www.mjoo.org -- http://www.paniq.org
Re: [linux-audio-dev] LADSPA 2
On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote: On Tue, 2006-04-25 at 23:58 +0200, Leonard paniq Ritter wrote: Ok, some thoughts about the headerfile: [snip] after reading this i do not see why a new ladspa header is required. there are barely any changes in 2. i think this is going to become more confusing than helpful, especially since it will not be possible to load ladspa 1+2 plugins in the same host with ease (yes, people do not like to fix orphaned code and recompile binaries, imagine!). You are completely missing the entire point of LADSPA2. All the unecessary data has been removed from the header file (ie the plugin code). Look at the example plugin's code, it will be painfully obvious what the advantage is. Well, with sufficeint use of calloc and careful spec wording its possible to get the same affect with no change to the struct, but I just dont see the point. The plugin and host code has to change anyway, and its less ugly if its removed. If we ever have an ABI change in the future then the LADSPA 1 pseudo-compatibility will be lost anyway. - Steve
Re: [linux-audio-dev] LADSPA 2
On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote: I think the easiest thing would be for the plugin to list its required features in the data file, then the host can weed them out without even getting that far. yup. The plugin may just choose to modify its behaviour, not refuse, so the featuers list still should be passed to instantiate IMHO. if it never refuses then its ok with me ;) - why does the plugin require its own bundle path for instantiation? this can usually be deduced from the dl's own runtime image information, no? otherwise, an explanation of this choice in the comment would be nice. Can it? I wasn't aware of that, in that case its redundant. i assume the lib file resides in the bundle path or the bundle path has been compiled into the lib. on win32, GetModulePath can be used to get the path to the current module, i do not know the posix equivalent to do that. alternatively the host could be required to chdir to the bundle folder before the plugin is being instantiated? It should be perfectly possible to load both. Personally I prefer to remove obsolete cruft, but its a matter of taste. I did consder just ignoring the obsolete fields and resusing label as the uri, but its kinda ugly. i just had a discussion with dave robillard on irc regarding this topic. my original (silly) wish of just changing the name has now a pragmatical basis. from my point of view, ladspa 2 is something different than ladspa 1. _replacing_ ladspa will immediately invalidate any non-updated plugin on the system. counting the mass of different plugins already available, it might take up to a year until distros catch up. you could avoid these migration issues if ladspa 2 had an entirely different name. none of the previous binaries have to be rebuilt, and can happily bitrot until no distro is supporting them anymore. it is maybe neccessary to support future api changes from the start, to allow soft migrations? Yes, but that's desirable anyway. With some of the (potential) new capbilities there are less ugly ways to do some of the things DSSI does, DSSI 2 should be much less complex that 1. how are parameter boundaries determined now? are all parameters clamped to 0..1 (as vst does)? if yes, shouldnt this be mentioned in the comments? -- -- leonard paniq ritter -- http://www.mjoo.org -- http://www.paniq.org
Re: [linux-audio-dev] LADSPA 2
On Wed, 2006-04-26 at 00:33 +0200, Leonard paniq Ritter wrote: On Tue, 2006-04-25 at 23:02 +0100, Steve Harris wrote: I think the easiest thing would be for the plugin to list its required features in the data file, then the host can weed them out without even getting that far. yup. ++ Definitely shouldn't have to instantiate a plugin to see if you even want it, especially since (as mentioned) this would make the user experience awful. The plugin may just choose to modify its behaviour, not refuse, so the featuers list still should be passed to instantiate IMHO. if it never refuses then its ok with me ;) Plugins must be able to refuse hosts and hosts must be able to refuse plugins. It's the only way to allow extensions. I _guarantee_ plugins will exist that some hosts just don't want (they already do with LADSPA1), and some plugins will exists that require features hosts are not required to provide. This is a Good Thing. i just had a discussion with dave robillard on irc regarding this topic. my original (silly) wish of just changing the name has now a pragmatical basis. from my point of view, ladspa 2 is something different than ladspa 1. _replacing_ ladspa will immediately invalidate any non-updated plugin on the system. counting the mass of different plugins already available, it might take up to a year until distros catch up. you could avoid these migration issues if ladspa 2 had an entirely different name. none of the previous binaries have to be rebuilt, and can happily bitrot until no distro is supporting them anymore. While I am with you on the name thing, you don't understand. LADSPA2 will be completely installable in parallel with LADSPA1. Obviously it will not replace LADSPA1 on a system and immediately break all the installed plugins! how are parameter boundaries determined now? are all parameters clamped to 0..1 (as vst does)? if yes, shouldnt this be mentioned in the comments? This, like most everything else, is in the data file. You really need to read more than the header before commenting further ;) -DR-
Re: [linux-audio-dev] LADSPA 2
On Tue, 2006-04-25 at 18:46 -0400, Dave Robillard wrote: Plugins must be able to refuse hosts and hosts must be able to refuse plugins. It's the only way to allow extensions. I _guarantee_ plugins will exist that some hosts just don't want (they already do with LADSPA1), and some plugins will exists that require features hosts are not required to provide. This is a Good Thing. maybe in a Perfect World. in practice, we are going to face irritations when plugins demand weird non-unified URIs to be passed in order to run at all. from what i see, no new URIs can be invented without requiring immediate support in all available hosts, and plugins that initially only work for one host are not that cool. ergo, the feature of blocking instantiation for a host not passing a required URI will be rarely used, for the simple reason that it might not work with all hosts. thus, do not allow it by spec. from my point of view, host features should be seen as hints, which are not required, but of a suggestive nature. my argumentation is chaotic. decipher the obvious! While I am with you on the name thing, you don't understand. LADSPA2 will be completely installable in parallel with LADSPA1. Obviously it will not replace LADSPA1 on a system and immediately break all the installed plugins! i hope this is taken care of! the new header suggests replacement, not complementation. This, like most everything else, is in the data file. You really need to read more than the header before commenting further ;) the trusty header should be all documentation required... there was also no reference to additional documents in it. how about adding it? :o) -DR- -- -- leonard paniq ritter -- http://www.mjoo.org -- http://www.paniq.org
