Discussion:
[linux-audio-dev] LADSPA needs & wishes
Fraser
2007-01-27 05:05:58 UTC
Permalink
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;
PortLayoutHints[MY_METER].right=5;

3) Customization
- control colours in the layout hints
- background & logo images in the descriptor
etc

This would all be optional for the host


Thanks for taking the time to read though all this, turned out to be
longer than I anticipated!

regards,
Fraser
Loki Davison
2007-01-27 05:47:09 UTC
Permalink
Post by Fraser
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!
Robert Jonsson
2007-01-27 11:36:09 UTC
Permalink
Post by Fraser
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!
Nedko Arnaudov
2007-01-27 18:57:26 UTC
Permalink
Post by Robert Jonsson
Post by Fraser
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>
Chris Cannam
2007-01-27 21:53:16 UTC
Permalink
Post by Nedko Arnaudov
Post by Robert Jonsson
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
Loki Davison
2007-01-28 13:01:04 UTC
Permalink
Post by Chris Cannam
Post by Nedko Arnaudov
Post by Robert Jonsson
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.
Nedko Arnaudov
2007-01-29 07:39:29 UTC
Permalink
Post by Chris Cannam
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

What else you want them to do? (zynjacku feature list is still open)

P.S. Antisocial humans don't read mailing lists.
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
Chris Cannam
2007-01-29 13:49:45 UTC
Permalink
Post by Nedko Arnaudov
Post by Chris Cannam
What are they? Do they do anything else, besides host LV2 plugins?
* 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?
Post by Nedko Arnaudov
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?
Post by Nedko Arnaudov
P.S. Antisocial humans don't read mailing lists.
Yeah, they do. Me for example.

Sorry for being so grumpy.


Chris
Lars Luthman
2007-01-29 14:41:30 UTC
Permalink
Post by Chris Cannam
Post by Nedko Arnaudov
Post by Chris Cannam
What are they? Do they do anything else, besides host LV2 plugins?
* 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).
Post by Chris Cannam
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
Steve Harris
2007-01-29 15:15:15 UTC
Permalink
Post by Lars Luthman
Post by Chris Cannam
Post by Nedko Arnaudov
Post by Chris Cannam
What are they? Do they do anything else, besides host LV2 plugins?
* 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
Nedko Arnaudov
2007-01-29 17:57:24 UTC
Permalink
Post by Chris Cannam
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>
Lars Luthman
2007-01-27 06:09:04 UTC
Permalink
Post by Fraser
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.
Post by Fraser
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.
Post by Fraser
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
Paul Davis
2007-01-27 13:07:00 UTC
Permalink
Post by Fraser
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
Fraser
2007-01-28 05:07:54 UTC
Permalink
Hi Paul,
Post by Paul Davis
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)
Steve Harris
2007-01-28 15:01:26 UTC
Permalink
Post by Fraser
Post by Paul Davis
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.
Fraser
2007-01-29 02:18:11 UTC
Permalink
Hi Steve,
Post by Steve Harris
Post by Fraser
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...
Post by Steve Harris
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.
Post by Steve Harris
Post by Fraser
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
Steve Harris
2007-01-29 08:08:37 UTC
Permalink
Post by Fraser
Hi Steve,
Hi Fraser,
Post by Fraser
Post by Steve Harris
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
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.
Post by Fraser
Post by Steve Harris
Post by Fraser
3) changes to parameters can be presented to the run() function
immediately
I don't see how it makes any difference in this area?
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
Paul Winkler
2007-01-29 15:23:40 UTC
Permalink
Post by Steve Harris
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
Steve Harris
2007-01-29 15:30:06 UTC
Permalink
Post by Paul Winkler
Post by Steve Harris
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
Lars Luthman
2007-01-29 15:33:11 UTC
Permalink
Post by Paul Winkler
Post by Steve Harris
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
Florian Schmidt
2007-01-29 16:51:32 UTC
Permalink
Post by Steve Harris
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.
Hi, let me chime in because it kidna fits into the subject.

I have defined two (very very simple LV2 extensions):

"The extension’s URI is
http://tapas.affenbande.org/lv2/ext/fixed-buffersize

All that a plugin needs to check is whether a host feature with this URI
exists and the data will be a uint32 containing the buffersize.

The host is only allowed to call the plugin’s run function with a buffersize
equal to the one specified by the host feature.
There’s a second extension:

http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize

which is identical to above but with the additional requirement that the fixed
buffersize has to be a power of two."

I don't need to have the URI point to my site. If you want to integrate it
into the official LV2 standard i'd be more than happy..

For anyone who might ask: "why do we need this"? Well the answer is that some
algorithms (especially fft based) perform much better when the buffer size
is known (because they must operate with a fixed buffersize internally). With
anyone of these two extensions provided by the host, those plugins can avoid
additional delay from buffering, etc..

We discussed on #lad whether a guarantee that the framecount of subsequent run
() calls add up to a fixed buffersize is enough.. I wasn't sure about this.
But i think now, that it's not a good idea. Here's a good counterargument:
Imagine an fft based plugin that uses the host buffer size as internal fft
size. Then with this guarantee it would have to collect data until an fft
buffer is full. While waiting for this and processing subsequent these
smaller buffers, it will have to produce output, but it doesn't have the fft
result yet. Thus causing unavoidable delay (of one total buffersize)..

Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Steve Harris
2007-01-29 17:22:38 UTC
Permalink
Post by Florian Schmidt
Post by Steve Harris
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.
Hi, let me chime in because it kidna fits into the subject.
"The extension’s URI is
http://tapas.affenbande.org/lv2/ext/fixed-buffersize
All that a plugin needs to check is whether a host feature with this URI
exists and the data will be a uint32 containing the buffersize.
The host is only allowed to call the plugin’s run function with a buffersize
equal to the one specified by the host feature.
http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize
which is identical to above but with the additional requirement that the fixed
buffersize has to be a power of two."
Great idea. I've got some plugins that will benefit a lot by this. We
should link to known extensions on the http://lv2plug.in/ site.

FWIW, my provisional plan was to wait until it seemed like time for a
LV2 1.1 (hopefully not too soon :), then roll all the "popular"
extensions into that.
It doesn't make a huge amount of difference whether their included or
not though.

Before you ask, no I don't have a definition for "popular".

- Steve
Florian Schmidt
2007-01-29 17:57:00 UTC
Permalink
Post by Steve Harris
Post by Florian Schmidt
http://tapas.affenbande.org/lv2/ext/fixed-buffersize
http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize
Great idea. I've got some plugins that will benefit a lot by this. We
should link to known extensions on the http://lv2plug.in/ site.
FWIW, my provisional plan was to wait until it seemed like time for a
LV2 1.1 (hopefully not too soon :), then roll all the "popular"
extensions into that.
Ah, i don't mean this extension has to become part of the core LV2 spec.
Nonono. I was just wondering whether it makes sense that i maintain this
seperately and keep the extension URI to my site.

Is there a plan to host some very common extensions on the lv2 site (URI
having lv2plug.in in it and docs on the lv2 site), too? If so i would like to
see these extensions included.
Post by Steve Harris
It doesn't make a huge amount of difference whether their included or
not though.
Well, just a visibility thing. By having some extensions documented
and "hosted" on lv2plug.in they probably get more visibility than others. For
certain "almost core" functionality this would make sense i think.
Post by Steve Harris
Before you ask, no I don't have a definition for "popular".
Hehe :)

Flo
--
Palimm Palimm!
http://tapas.affenbande.org
Steve Harris
2007-01-29 18:20:28 UTC
Permalink
Post by Florian Schmidt
Post by Steve Harris
Post by Florian Schmidt
http://tapas.affenbande.org/lv2/ext/fixed-buffersize
http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize
Great idea. I've got some plugins that will benefit a lot by this. We
should link to known extensions on the http://lv2plug.in/ site.
FWIW, my provisional plan was to wait until it seemed like time for a
LV2 1.1 (hopefully not too soon :), then roll all the "popular"
extensions into that.
Ah, i don't mean this extension has to become part of the core LV2 spec.
Nonono. I was just wondering whether it makes sense that i maintain this
seperately and keep the extension URI to my site.
Is there a plan to host some very common extensions on the lv2 site (URI
having lv2plug.in in it and docs on the lv2 site), too? If so i would like to
see these extensions included.
Ah, I see. In principle that's fine, but in practice I suspect it's
easier for you to edit the content on your own site. OTOH if people
are happy to maintain the content via WebDAV then I'm happy to host
extensions at http://lv2plugin.in/extension/foo or similar.

There should definitely be links to the extensions from the spec site
either way.
Post by Florian Schmidt
Post by Steve Harris
It doesn't make a huge amount of difference whether their included or
not though.
Well, just a visibility thing. By having some extensions documented
and "hosted" on lv2plug.in they probably get more visibility than others. For
certain "almost core" functionality this would make sense i think.
Well, for any really. URIs are free and we're not going to run out ;)

- Steve
Dave Robillard
2007-01-29 23:25:33 UTC
Permalink
Post by Steve Harris
Post by Florian Schmidt
Post by Steve Harris
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.
Hi, let me chime in because it kidna fits into the subject.
"The extension’s URI is
http://tapas.affenbande.org/lv2/ext/fixed-buffersize
All that a plugin needs to check is whether a host feature with this URI
exists and the data will be a uint32 containing the buffersize.
The host is only allowed to call the plugin’s run function with a buffersize
equal to the one specified by the host feature.
http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize
which is identical to above but with the additional requirement that the fixed
buffersize has to be a power of two."
Great idea. I've got some plugins that will benefit a lot by this. We
should link to known extensions on the http://lv2plug.in/ site.
FWIW, my provisional plan was to wait until it seemed like time for a
LV2 1.1 (hopefully not too soon :), then roll all the "popular"
extensions into that.
It doesn't make a huge amount of difference whether their included or
not though.
Before you ask, no I don't have a definition for "popular".
I think it might be a better idea to reserve some URI prefix
(http://lv2plug/extensions ?) for "popular" extensions and keep the spec
itself simple, just for the sake of having a simple understandable core
spec regardless of how the more fancy things evolve.

Thoughts?

-DR-
Fraser
2007-01-30 01:25:20 UTC
Permalink
Hi Steve,
Post by Steve Harris
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
Steve Harris
2007-01-30 08:53:07 UTC
Permalink
Post by Fraser
Hi Steve,
Post by Steve Harris
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

Nedko Arnaudov
2007-01-29 07:30:09 UTC
Permalink
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>
Ivica Ico Bukvic
2007-01-27 23:33:59 UTC
Permalink
Post by Robert Jonsson
Suggesting that LADSPA is deprecated is a bit of a stretch. It may not
be
Post by Robert Jonsson
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
Continue reading on narkive:
Loading...