Re: [linux-audio-dev] LADSPA needs & wishes

[Steve Harris]

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

[Fraser]

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

[Nedko Arnaudov]

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 


pgpV4YvgL74j1.pgp
Description: PGP signature

Re: [linux-audio-dev] LADSPA needs & wishes

[Lars Luthman]

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

[Steve Harris]

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

[Paul Winkler]

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

[Steve Harris]

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

[Lars Luthman]

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

[Chris Cannam]

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

[Steve Harris]

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

[Nedko Arnaudov]

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

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

P.S. Antisocial humans don't read mailing lists.

-- 
Nedko Arnaudov 


pgpyjHZZFic7Z.pgp
Description: PGP signature

Re: [linux-audio-dev] LADSPA needs & wishes

[Nedko Arnaudov]

"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 


pgpwppUvg5HXK.pgp
Description: PGP signature

Re: [linux-audio-dev] LADSPA needs & wishes

[Fraser]

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

[Steve Harris]

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

[Loki Davison]

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

[Fraser]

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

RE: [linux-audio-dev] LADSPA needs & wishes

[Ivica Ico Bukvic]

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

[Chris Cannam]

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

[Nedko Arnaudov]

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 


pgpZZNLIch0bk.pgp
Description: PGP signature

Re: [linux-audio-dev] LADSPA needs & wishes

[Paul Davis]

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]

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

[Lars Luthman]

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 needs & wishes

[Loki Davison]

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 preset musings

[Luis Garrido]

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

[Kjetil Svalastog Matheussen]

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)

Re: [linux-audio-dev] LADSPA preset musings

[Steve Harris]

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 Extension for Extra GUI Data

[Dave Robillard]

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

[Dave Robillard]

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

[Jeff McClintock]

> 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

[carmen]

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

[Alfons Adriaensen]

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

[Steve Harris]

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

[Alfons Adriaensen]

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

[Steve Harris]

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

[Dave Robillard]

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

[Dave Robillard]

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

[Steve Harris]

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

Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data

[Paul Davis]

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 Extension for Extra GUI Data

[Fons Adriaensen]

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

[Steve Harris]

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

[Fons Adriaensen]

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

[Steve Harris]

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

[Dave Robillard]

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-

Re: [linux-audio-dev] LADSPA Extension for Extra GUI Data

[Steve Harris]

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 2 name

[Dave Robillard]

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.



-DR-

Re: [linux-audio-dev] LADSPA 2 name

[pete]

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

[Lee Revell]

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

[peter]

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

[Ismael Valladolid Torres]

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

[Hans Fugal]

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

[Steve Harris]

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

[Dmitry Baikov]

LAMA - Linux(Libre) Audio Modules Architecture

I hope The Dalai Lama will not object.

Re: [linux-audio-dev] LADSPA 2 name

[Thorsten Wilms]

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

[Matthias Koenig]

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

[Lee Revell]

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

[Esben Stien]

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

[Dave Phillips]

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

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

[Sampo Savolainen]

Quoting Esben Stien <[EMAIL PROTECTED]>:

> 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?;)

How about both recursive and a girlie name?

BELLA = BELLA Effects Layer for Linux Audio

(B could also be Bitchin')

  Sampo

RE: [linux-audio-dev] LADSPA 2 name

[andym00]

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

[Esben Stien]

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

Re: [linux-audio-dev] LADSPA 2 name

[Dave Phillips]

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

[Dave Robillard]

On Tue, 2006-05-09 at 09:59 +0100, Steve Harris wrote:
> On Mon, May 08, 2006 at 03:29:46PM -0400, Paul Winkler wrote:
> > On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote:
> > > On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote:
> > > > Hi!
> > > > 
> > > > Requirements in order of importance, highest first:
> > > > - not likely to get us into legal trouble
> > (snip)
> > > L2, where the L is for LADSPA.
> > http://www.waves.com/content.asp?id=139
> 
> But I like the idea. LV2 is less taken. Nearest thing is a model of midi
> controller:
> http://www.dolphinmusic.co.uk/page/shop/flypage/product_id/8779

I like LV2.  Bit of a mouthful when spoken, but then so is VST.

-DR-

Re: [linux-audio-dev] LADSPA 2 name

[Steve Harris]

On Mon, May 08, 2006 at 03:29:46PM -0400, Paul Winkler wrote:
> On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote:
> > On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote:
> > > Hi!
> > > 
> > > Requirements in order of importance, highest first:
> > > - not likely to get us into legal trouble
> (snip)
> > L2, where the L is for LADSPA.
> http://www.waves.com/content.asp?id=139

But I like the idea. LV2 is less taken. Nearest thing is a model of midi
controller:
http://www.dolphinmusic.co.uk/page/shop/flypage/product_id/8779

- Steve

Re: [linux-audio-dev] LADSPA 2 name

[Paul Winkler]

On Mon, May 08, 2006 at 08:20:43PM +0200, Lars Luthman wrote:
> On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote:
> > Hi!
> > 
> > Requirements in order of importance, highest first:
> > - not likely to get us into legal trouble
(snip)
> L2, where the L is for LADSPA.
http://www.waves.com/content.asp?id=139

-- 

Paul Winkler
http://www.slinkp.com

Re: [linux-audio-dev] LADSPA 2 name

[Lars Luthman]

On Mon, 2006-05-08 at 19:28 +0200, Thorsten Wilms wrote:
> 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

L2, where the L is for LADSPA.

-- 
Lars Luthman
PGP key: http://www.student.nada.kth.se/~d00-llu/pgp_key.php
Fingerprint: FCA7 C790 19B9 322D EB7A  E1B3 4371 4650 04C7 7E2E


signature.asc
Description: This is a digitally signed message part

Re: [linux-audio-dev] LADSPA 2

[Dave Robillard]

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-

Re: [linux-audio-dev] LADSPA 2

[Steve Harris]

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

[Dave Robillard]

On Tue, 2006-05-02 at 13:50 +0200, Alfons Adriaensen wrote:
> On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote:
> 
> 
> > 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.
> 
> A lot of plugins create what is essentially a block of constants by
> dynamically allocating and initialising every bit of it. ISTR there was
> (is) even an 'offical' plugin example source doing it that way.
> Compared to that the new code is indeed simpler. But it's a braindead
> way of doing it really, and that makes the comparison totally invalid.
> 
> I really don't see what is 'complex' or 'difficult' about e.g.
> 
> 
> static const LADSPA_PortDescriptor pdesc0 [Ladspa_G2reverb::NPORT] = 
> {
> LADSPA_PORT_INPUT  | LADSPA_PORT_AUDIO,
> LADSPA_PORT_INPUT  | LADSPA_PORT_AUDIO,
> LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
> LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
> LADSPA_PORT_INPUT  | LADSPA_PORT_CONTROL,
> 
> };

That would be a valid point if all the data that people wanted to
associate with plugins was strictly defined right now (which is
impossible).  That is the whole problem with LADSPA1 that we need to fix
here, hence the external data file.

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

-DR-

Re: [linux-audio-dev] LADSPA 2

[Alfons Adriaensen]

On Tue, Apr 25, 2006 at 05:58:08PM -0400, Dave Robillard wrote:


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

A lot of plugins create what is essentially a block of constants by
dynamically allocating and initialising every bit of it. ISTR there was
(is) even an 'offical' plugin example source doing it that way.
Compared to that the new code is indeed simpler. But it's a braindead
way of doing it really, and that makes the comparison totally invalid.

I really don't see what is 'complex' or 'difficult' about e.g.


static const LADSPA_PortDescriptor pdesc0 [Ladspa_G2reverb::NPORT] = 
{
LADSPA_PORT_INPUT  | LADSPA_PORT_AUDIO,
LADSPA_PORT_INPUT  | LADSPA_PORT_AUDIO,
LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_OUTPUT | LADSPA_PORT_AUDIO,
LADSPA_PORT_INPUT  | LADSPA_PORT_CONTROL,

};


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.


-- 
FA

Follie! Follie! Delirio vano e' questo!

Re: [linux-audio-dev] LADSPA Repository

[Steve Harris]

On Sun, Apr 30, 2006 at 11:49:32PM +0100, Gordonjcp wrote:
> Jan Weil wrote:
> >Am Donnerstag, den 20.04.2006, 21:48 +0200 schrieb Lars Luthman:
> >>How about a machine-friendly interface for searching and downloading
> >>plugin tarballs (or references to distribution packages) so one could
> >>write a tool like CPAN for LADSPAs? An automated way to download and
> >>install plugins would be really useful if it could be integrated into
> >>software like Om, Ardour, JACK-rack etc. Scenario: you try to load a new
> >>Om patch that you downloaded from the net, you get the message "You
> >>don't have the 'foo' plugin, do you want to install it?", click Yes, and
> >>a few seconds (or minutes) later the plugin is installed and the patch
> >>is loaded.
> >
> >AFAIK most plugins don't have any dependencies. Is there anything wrong
> 
> DSSI ones may do.  It depends what toolkit their GUI was written in.

Sorry, I missed the earlier message, but many plugins also link to FFTW,
and I wouldn't be supprised to find some that link to DSP libraries.

- Steve

Re: [linux-audio-dev] LADSPA Repository

[Gordonjcp]

Jan Weil wrote:

Am Donnerstag, den 20.04.2006, 21:48 +0200 schrieb Lars Luthman:

How about a machine-friendly interface for searching and downloading
plugin tarballs (or references to distribution packages) so one could
write a tool like CPAN for LADSPAs? An automated way to download and
install plugins would be really useful if it could be integrated into
software like Om, Ardour, JACK-rack etc. Scenario: you try to load a new
Om patch that you downloaded from the net, you get the message "You
don't have the 'foo' plugin, do you want to install it?", click Yes, and
a few seconds (or minutes) later the plugin is installed and the patch
is loaded.


AFAIK most plugins don't have any dependencies. Is there anything wrong


DSSI ones may do.  It depends what toolkit their GUI was written in.

Gordon

Re: [linux-audio-dev] "LADSPA 2" name

[Steve Harris]

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" name

[Esben Stien]

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

[Jens M Andreasen]

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

[Phil Frost]

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


You can't have it ;)

Re: [linux-audio-dev] "LADSPA 2" name

[Dave Robillard]

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

[Luis Garrido]

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

[Dave Robillard]

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

[Dave Robillard]

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

[Steve Harris]

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

[Steve Harris]

On Wed, Apr 26, 2006 at 01:14:06PM -0400, Dave Robillard wrote:
> 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?

Yes, the URI changes whenever the effective ABI changes, ie add, remove or
change semantics of ports, or new struct ABI.
 
> 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.

Yes, you just need to make sure the URIs and and bundle names change as
appropriate.

- Steve

Re: [linux-audio-dev] "LADSPA 2" name

[Steve Harris]

On Wed, Apr 26, 2006 at 08:09:26PM +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)?
> 
> GO FAP! FAP FAP FAP!

Perhaps not.
 
> i also would like CLAP. :)

No, you wouldn't ;)

- Steve

Re: [linux-audio-dev] "LADSPA 2" name

[Steve Harris]

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

[Luis Garrido]

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

[Steve Harris]

On Wed, Apr 26, 2006 at 08:04:35PM +0200, Leonard paniq Ritter wrote:
> 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?

SupportedFeatures is not just fo requirements. eg. Fon's plyphonic control
ports can work around the case where the host doesnt support it.
 
> furthermore, surely there are other reasons why instantiation could
> fail. how can the host determine the reason for which a plugin refused
> to instantiate? 

It can't. Meh.
 
> > > 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? ;)

More the running around screaming kind ;)

- Steve

Re: [linux-audio-dev] LADSPA 2

[Steve Harris]

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

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

I dont think its neccesary to specify this though, the best natural level
usually settles out. ie. people see cmt.so, and go "arrrghhh!".

- Steve

Re: [linux-audio-dev] LADSPA 2

[Dave Robillard]

On Wed, 2006-04-26 at 20:04 +0200, Leonard "paniq" Ritter wrote:
> 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?

The plugin (obviously) needs to check the features anyway, since it
needs to (or may want to) use them.  Can't use something if you don't
even know if it's there.

-DR-

Re: [linux-audio-dev] LADSPA 2

[Leonard \"paniq\" Ritter]

On Wed, 2006-04-26 at 15:56 +0100, Steve Harris wrote:
> That's somewhat like saying a corrupt binary should never cause a
> segfault... if the data file gets corrupted in a way that breaks the
> syntax, then there wont be enouhg data for hte host to attempt to load the
> plugin and it will refuse, but if through some miracle
> ladspa:InputControPort becomes ladspa:OutputControlPort then all kinds of
> crazy shit will go down.

segfaults will only be ok as long as there are no security advisories.
beware the rdf exploits. :)


-- 
-- leonard "paniq" ritter
-- http://www.mjoo.org
-- http://www.paniq.org

Re: [linux-audio-dev] "LADSPA 2" name

[Dave Robillard]

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

-DR-

Re: [linux-audio-dev] "LADSPA 2" name

[Leonard \"paniq\" Ritter]

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

[Leonard \"paniq\" Ritter]

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

[Dave Robillard]

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

[Steve Harris]

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" name

[Steve Harris]

On Wed, Apr 26, 2006 at 10:55:12AM -0400, Dave Robillard wrote:
> > 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.

Or XML related, yes. It's a risk.
 
> > 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. :)

If we can find one thats not too expensive I'll pick up the tab.

- Steve

Re: [linux-audio-dev] LADSPA 2

[tom christie]

> 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

[Dave Robillard]

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

[Steve Harris]

On Wed, Apr 26, 2006 at 12:54:43PM +0100, tom christie wrote:
> It's really just an extra layer of protection...
> I realise that the binary and data files will be accessed as a single unit,
> but a corrupt data file should never cause a segfault.

That's somewhat like saying a corrupt binary should never cause a
segfault... if the data file gets corrupted in a way that breaks the
syntax, then there wont be enouhg data for hte host to attempt to load the
plugin and it will refuse, but if through some miracle
ladspa:InputControPort becomes ladspa:OutputControlPort then all kinds of
crazy shit will go down.

> Without a built-in struct version identifier the host (or LADSPA library)
> may segfault by incorrectly accessing the struct.  (if the data file is 
> corrupt)

I'm not interested in the case the data file is corrupt, its too much of a
special case, and theres nothing sensible you can do about it.

No-ones seriously interested in guarding against the caes where the .so is
corrupt. If you care that much, ship a sha1 checksum with your plugin.
 
> With a built-in struct version identifier the host (or LADSPA library)
> can ensure it will never access the struct in a way which will cause a 
> segfault.
> (even if the data file is corrupt.)

No it can't :) If the data file is currupt in any plausible way the host wont
have enough information to even attept to open the plugin anyway.

- Steve

Re: [linux-audio-dev] "LADSPA 2" name

[Dave Robillard]

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

[tom christie]

It's really just an extra layer of protection...
I realise that the binary and data files will be accessed as a single unit,
but a corrupt data file should never cause a segfault.

Without a built-in struct version identifier the host (or LADSPA library)
may segfault by incorrectly accessing the struct.  (if the data file is corrupt)

With a built-in struct version identifier the host (or LADSPA library)
can ensure it will never access the struct in a way which will cause a segfault.
(even if the data file is corrupt.)

Okay, I'll hold my peace now ;)


On 4/26/06, Steve Harris <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 26, 2006 at 09:48:01 +0100, tom christie wrote:
> ...
>
> > 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.
>
> It's not metadata. If the data is corrupt or missing then youre SOL. It's
> just as vital as the arrays of structs were in LADSPA 1; if you dont have
> the data theres no way to use the plugin without causing segfaults.
>
> This is why the "plugin" is really a directory, all the stuff in there is
> neccesary.
>
> - Steve
>