19 Jun
2006
19 Jun
'06
6:03 a.m.
Hello, i'm new here,
i've been working on a very simple, backward-forwards compatible extension to
LADSPA/DSSI to allow hosts to display more meaningful gui's with a
"describe_value" function which takes the port index and a LADSPA_Data and
allows the plugin to return a meaningful description. eg.
for a waveform port it might return "SAW", "SIN", "SQR" etc
for a cutoff filter it might return the frequency in Hz
for a tuning port it might return "-4 semitones"
also wanting to add a mechanism to group ports into logical sections.
without changing the underlying APIs, only by adding more layers on top this way
preserving backwards compatibility, the host simply dlsyms for
"ladgui_descriptor" and if it's there it makes use of the extra data,
otherwise
it falls back to how it previously did things
once the API is done i plan to make a reference gui
the idea behind this is that plugins will not need any of their own gui code as
a useful gui can be constructed on the fly as a part of the host or a separate
process that will work for any plugin so plugin developers never need worry
about constructing a gui and can instead just make nice useable algorithms and
test them quickly and easily.
nicknamed LADGUI for now.
API so far is at http://ftsf.technetium.net.au/code/ladgui/ladgui.h
what i'd like to know is, if this is a stupid idea ^_^
it seems like a good one to me, but when i joined here to post this i noticed
lots of talk about LADSPA2, i've tried to read up on it but i can't seem to
find much information about it, and it doesn't seem to be backwards compatible
and doesn't seem to add anything to help create guis in the host? is there a
page somewhere which explains it all?
i'm sure there's lots of useful stuff that i'm missing, what other things
would
be useful in such an extension?
thanks
Jez Kabanov
19 Jun
19 Jun
6:51 a.m.
On Mon, Jun 19, 2006 at 06:03:43 +1000, jez(a)technetium.net.au 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
7:50 a.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
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
hmm, wouldn't that mean you need to code something (or include another
library) to parse all that description language making it difficult for
the host coder, and requires learning of a new language for the plugin
developer. seems much simpler and quicker for a plugin developer and host
developer to use a simple callback.
but the localisation is a good idea, but couldn't be handled via gettext
in the usual manner.
the advantage of this method is that it can achieve these goals without
breaking compatibility, further extensions can be added simply by adding
another "layer" of API like this and DSSI do which can be queried by the
host as needed or it can simply fall back if the host or the plugin don't
support it.
seems to me like LV2 has lots of good ideas, but is shooting itself in the
foot with complexity?
- Jez
8:05 a.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 07:51:59AM +1000, Jez Kabanov wrote:
hmm, wouldn't that mean you need to code something (or include another
library) to parse all that description language making it difficult for
the host coder, and requires learning of a new language for the plugin
developer. seems much simpler and quicker for a plugin developer and host
developer to use a simple callback.
but the localisation is a good idea, but couldn't be handled via gettext
in the usual manner.
A library to make hosting LV2s easy is in progress and almost finished,
afaik.
seems to me like LV2 has lots of good ideas, but is
shooting itself in the
foot with complexity?
It's rather LADSPA which shot itself in the foot:
With LADSPA, fixed data fields providing information about the plugin (like
the number and type of ports) are inside the plugin binary, resulting in a
number of problems:
* There is lots of tedious, but quite complex code for providing data needed
inside every plugin source.
* The plugin has to be loaded and linked to retrieve any information about it.
* There's no support for internationalisation.
* Adding anything to the static data means breaking binary compatibility.
LV2 separates the static data into RDF files in the easy to hand-write Turtle
syntax. This provides a solution to all of the above problems. By using RDF,
any kind of additional data can be added by plugin authors without
compatibility problems. Thanks to RDF namespacing, anyone can create
extensions under their own namespace. Successful extensions can then later be
made part of the core spec. Strings can be internationalised easily.
---
Thorsten Wilms
10:15 a.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 12:04:56PM +0200, Thorsten Wilms wrote:
It's rather LADSPA which shot itself in the foot:
With LADSPA, fixed data fields providing information about the plugin (like
the number and type of ports) are inside the plugin binary, resulting in a
number of problems:
All of them fake.
* There is lots of tedious, but quite complex code for
providing data needed
inside every plugin source.
False. Its bl**dy simple, unless you want to make it difficult.
* The plugin has to be loaded and linked to retrieve
any information about it.
Loading and unloading it is still a lot simpler than what you need to do now.
* There's no support for internationalisation.
It could easily be added without breaking anything.
* Adding anything to the static data means breaking
binary compatibility.
No it doesn't, unless you want it to.
Reminds me of the description, in Colin Crouch's wonderful book
"Postdemocrazia", of how privatisation was sold to the British
public, and the story of the lamb and the woolf which he uses to
illustrate the process:
A lamb and a woolf are both are living near a river, not far
from each other.
Woolf: Lamb, you are pollution my water ! You'r pi**ing in it and
I have to drink it ! Therefore I will kill you.
Lamb: But you know that isn't true ! I'm living downstream from you,
so you are polluting *my* water !
Woolf: That doesn't matter. I'll kill you anyway.
--
FA
Follie! Follie! Delirio vano e' questo!
3:49 p.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Mon, 2006-06-19 at 14:15 +0200, Alfons Adriaensen wrote:
On Mon, Jun 19, 2006 at 12:04:56PM +0200, Thorsten
Wilms wrote:
Fake like the countless bug reports I get about your filter plugins not
working because they take some silly arbitrary unit instead of Hz for
cutoff frequency?
-DR-
It's rather LADSPA which shot itself in the
foot:
With LADSPA, fixed data fields providing information about the plugin (like
the number and type of ports) are inside the plugin binary, resulting in a
number of problems:
All of them fake. 
4:44 p.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 01:49:14PM -0400, Dave Robillard wrote:
If you mean the "Moog" filters, it's not arbitrary, but 1/octave as for
everything in AMS, for which they were written.
I never had a bug report for this, rather the opposite.
And why then should *you* be getting them ?
If OTOH you mean the 4-band parametric, it does take frequency control
values in Hz (and gains in dB).
All this doesn't change the fact that the rationale I commented on
*is* fake, whatever the qualities of LV2 (which I do not even deny).
--
FA
Follie! Follie! Delirio vano e' questo!
On Mon, 2006-06-19 at 14:15 +0200, Alfons Adriaensen
wrote:
All of them
fake.
Fake like the countless bug reports I get about your filter plugins not
working because they take some silly arbitrary unit instead of Hz for
cutoff frequency?
6:33 p.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Mon, Jun 19, 2006 at 08:44:25 +0200, Fons Adriaensen wrote:
All this doesn't change the fact that the
rationale I commented on
*is* fake, whatever the qualities of LV2 (which I do not even deny).
I dont agree that it's fake per se, but I do think it was overstated. It
can be /difficult/ to maintain binary compatibility, but it is rarely
impossible, unless a really bad design decisision was taken..
- Steve
9:05 p.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On 6/20/06, Fons Adriaensen <fons.adriaensen(a)skynet.be> wrote:
On Mon, Jun 19, 2006 at 01:49:14PM -0400, Dave
Robillard wrote:
If you mean the "Moog" filters, it's not arbitrary, but 1/octave as for
everything in AMS, for which they were written.
I never had a bug report for this, rather the opposite.
And why then should *you* be getting them ?
If OTOH you mean the 4-band parametric, it does take frequency control
values in Hz (and gains in dB).
All this doesn't change the fact that the rationale I commented on
*is* fake, whatever the qualities of LV2 (which I do not even deny).
--
FA
Follie! Follie! Delirio vano e' questo!
Because people actually use them in Om, because people actually use Om
unlike certain other modulars. volt per octave is pretty damn obscure
in a computer program.... If i wanted to have a cutoff at concert A
what the hell is that in volts per octave?
Loki
On Mon, 2006-06-19 at 14:15 +0200, Alfons
Adriaensen wrote:
All of
them fake.
Fake like the countless bug reports I get about your filter plugins not
working because they take some silly arbitrary unit instead of Hz for
cutoff frequency?
20 Jun
20 Jun
5:35 a.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki Davison wrote:
Because people actually use them in Om, because people
actually use Om
unlike certain other modulars. volt per octave is pretty damn obscure
in a computer program.... If i wanted to have a cutoff at concert A
what the hell is that in volts per octave?S
Zero typically. I have to take issue with this, 1.0f per octave is the
natural way to preresent things like filter cutoff in a modular. It's what
makes the great modular systems so easy to work with.
- Steve
25 Jun
25 Jun
4:01 a.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Tue, 2006-06-20 at 08:35 +0100, Steve Harris wrote:
On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki Davison
wrote:
Nonsense. As a numerical unit it has no meaning whatsoever, and the
unit actually used has no bearing on the user interface provided (which
should of course be exponential).
The only sane unit for frequency is Hz. As Loki said, if I want a
cutoff at concert A, I (like any musician) know that's 440Hz. Whatever
arbitrary ugly real number it is in "V/Oct As Defined By AMS" is not
something I or anyone else cares to know. Any table of frequencies, or
math app, or damn near _anything_ that deals with frequencies will
present it in Hz. If you can come up with a real reason why this
arbitrary "AMS V/Oct" makes any sense in a _digital_ modular, I'd like
to hear it.
Anyway, Hz is the SI unit for frequency. Beat that. :P
-DR-
Because people actually use them in Om, because
people actually use Om
unlike certain other modulars. volt per octave is pretty damn obscure
in a computer program.... If i wanted to have a cutoff at concert A
what the hell is that in volts per octave?S
Zero typically. I have to take issue with this, 1.0f per octave is the
natural way to preresent things like filter cutoff in a modular. It's what
makes the great modular systems so easy to work with.
3:58 p.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Sun, Jun 25, 2006 at 02:01:48 -0400, Dave Robillard wrote:
On Tue, 2006-06-20 at 08:35 +0100, Steve Harris
wrote:
It has a very specific meaning, +1.0 is +1.0 octaves.
On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki
Davison wrote:
Nonsense. As a numerical unit it has no meaning whatsoever, and the
unit actually used has no bearing on the user interface provided (which
should of course be exponential). Because people actually use them in Om, because
people actually use Om
unlike certain other modulars. volt per octave is pretty damn obscure
in a computer program.... If i wanted to have a cutoff at concert A
what the hell is that in volts per octave?S
Zero typically. I have to take issue with this, 1.0f per octave is the
natural way to preresent things like filter cutoff in a modular. It's what
makes the great modular systems so easy to work with. The only sane unit for frequency is Hz. As Loki said,
if I want a
cutoff at concert A, I (like any musician) know that's 440Hz. Whatever
arbitrary ugly real number it is in "V/Oct As Defined By AMS" is not
something I or anyone else cares to know. Any table of frequencies, or
math app, or damn near _anything_ that deals with frequencies will
present it in Hz. If you can come up with a real reason why this
arbitrary "AMS V/Oct" makes any sense in a _digital_ modular, I'd like
to hear it.
It's all about modulation, if I connect a [-1.0, 1.0] sine LFO to a cutoff
modulation input then I want it to modulate up and down by N octaves, not
N Hz, frequency-linearly symmetric modulations sound wrong. My favourite
(digital) modular filters have a centre frequnecy (shown in Hz, expoentialy
scaled control) and a modulation input that modulates in octaves.
You want the modulation to be musically relevent, and the most musically
useful unit for pitch is octaves :) Humans aren't SI sadly.
I agree that describing it as volts is a bit odd, but it instantly makes
people like me feel at home. There's not reason why a digital modular neds
units for its modulation sources. It's just real numbers.
- Steve
6:21 p.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Sun, 2006-06-25 at 18:57 +0100, Steve Harris wrote:
This is true, but there are other cases when you want a real, meaningful
frequency to do something with (using the same plugin). Eg lowpass all
frequencies above 800Hz. Someone working on a DAW definitely doesn't
want to deal with this meaningless V/Oct unit.
Of course, in a modular you can convert Hz frequencies to VOct
frequencies, and in a DAW you can convert VOct frequencies to Hz, but in
both cases it's a user nuisance, so it needs to be automatic. My gripe
isn't with the unit itself, so much as in the current situation with
LADSPA it's a really, really huge PITA to have a mess of twisty little
units, all alike.
Of course LV2 will let us solve this, and the frequency unit can in both
cases be kept entirely transparent by the host (if you want), making the
actual unit used by a plugin just an optimization as it should be
(skipping the conversion step).
-DR-
On Sun, Jun 25, 2006 at 02:01:48 -0400, Dave Robillard
wrote:
so 2.0 is.. um... well, 2 octaves above.. uh, something... ;)
On Tue, 2006-06-20 at 08:35 +0100, Steve Harris
wrote:
It has a very specific meaning, +1.0 is +1.0 octaves. On Tue, Jun 20, 2006 at 09:05:33 +1000, Loki
Davison wrote:
Nonsense. As a numerical unit it has no meaning whatsoever, and the
unit actually used has no bearing on the user interface provided (which
should of course be exponential). Because people actually use them in Om, because
people actually use Om
unlike certain other modulars. volt per octave is pretty damn obscure
in a computer program.... If i wanted to have a cutoff at concert A
what the hell is that in volts per octave?S
Zero typically. I have to take issue with this, 1.0f per octave is the
natural way to preresent things like filter cutoff in a modular. It's what
makes the great modular systems so easy to work with. The only sane
unit for frequency is Hz. As Loki said, if I want a
cutoff at concert A, I (like any musician) know that's 440Hz. Whatever
arbitrary ugly real number it is in "V/Oct As Defined By AMS" is not
something I or anyone else cares to know. Any table of frequencies, or
math app, or damn near _anything_ that deals with frequencies will
present it in Hz. If you can come up with a real reason why this
arbitrary "AMS V/Oct" makes any sense in a _digital_ modular, I'd like
to hear it.
It's all about modulation, if I connect a [-1.0, 1.0] sine LFO to a cutoff
modulation input then I want it to modulate up and down by N octaves, not
N Hz, frequency-linearly symmetric modulations sound wrong. My favourite
(digital) modular filters have a centre frequnecy (shown in Hz, expoentialy
scaled control) and a modulation input that modulates in octaves.
You want the modulation to be musically relevent, and the most musically
useful unit for pitch is octaves :) Humans aren't SI sadly.
I agree that describing it as volts is a bit odd, but it instantly makes
people like me feel at home. There's not reason why a digital modular neds
units for its modulation sources. It's just real numbers.
26 Jun
26 Jun
6:04 a.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Sun, Jun 25, 2006 at 04:21:20 -0400, Dave Robillard wrote:
That's why I said you have a centre frequency control, that's set in Hz.
It's all
about modulation, if I connect a [-1.0, 1.0] sine LFO to a cutoff
modulation input then I want it to modulate up and down by N octaves, not
N Hz, frequency-linearly symmetric modulations sound wrong. My favourite
(digital) modular filters have a centre frequnecy (shown in Hz, expoentialy
scaled control) and a modulation input that modulates in octaves.
You want the modulation to be musically relevent, and the most musically
useful unit for pitch is octaves :) Humans aren't SI sadly.
I agree that describing it as volts is a bit odd, but it instantly makes
people like me feel at home. There's not reason why a digital modular neds
units for its modulation sources. It's just real numbers.
This is true, but there are other cases when you want a real, meaningful
frequency to do something with (using the same plugin). Eg lowpass all
frequencies above 800Hz. Someone working on a DAW definitely doesn't
want to deal with this meaningless V/Oct unit. Of course, in a modular you can convert Hz frequencies
to VOct
frequencies, and in a DAW you can convert VOct frequencies to Hz, but in
both cases it's a user nuisance, so it needs to be automatic. My gripe
isn't with the unit itself, so much as in the current situation with
LADSPA it's a really, really huge PITA to have a mess of twisty little
units, all alike.
Yes, but neccesary, unless your hosts all understand the semantics of
pitch/frequency and are willing to do lots of pow() based conversions.
Of course LV2 will let us solve this, and the
frequency unit can in both
cases be kept entirely transparent by the host (if you want), making the
actual unit used by a plugin just an optimization as it should be
(skipping the conversion step).
s/will/could/, I'm not yet convinced that it's appropriate. My preference
would still be for a Hz centre control and a (high rate) modulation input.
If there's a sane representation in RDF for a single port to do both
things well, then I'm all for it, but I'm scpetical.
- Steve
25 Jun
25 Jun
7:40 p.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Sun, Jun 25, 2006 at 06:57:47PM +0100, Steve Harris wrote:
I agree that describing it as volts is a bit odd, but
it instantly makes
people like me feel at home. There's not reason why a digital modular neds
units for its modulation sources. It's just real numbers.
I never mentioned 'volts'.
--
FA
Follie! Follie! Delirio vano e' questo!
26 Jun
26 Jun
6:06 a.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Sun, Jun 25, 2006 at 11:40:53 +0200, Fons Adriaensen wrote:
On Sun, Jun 25, 2006 at 06:57:47PM +0100, Steve Harris
wrote:
Sorry, that was Dave then. I still feel at home with v/octave though :)
- Steve
I agree that describing it as volts is a bit odd,
but it instantly makes
people like me feel at home. There's not reason why a digital modular neds
units for its modulation sources. It's just real numbers.
I never mentioned 'volts'.
19 Jun
19 Jun
3:58 p.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Mon, 2006-06-19 at 07:51 +1000, Jez Kabanov wrote:
http://www.scs.carleton.ca/~drobilla/files/slv2_jack_host.c
If that can be less complex, I want to hear how. :)
-DR-
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
hmm, wouldn't that mean you need to code something (or include another
library) to parse all that description language making it difficult for
the host coder, and requires learning of a new language for the plugin
developer. seems much simpler and quicker for a plugin developer and host
developer to use a simple callback.
but the localisation is a good idea, but couldn't be handled via gettext
in the usual manner.
the advantage of this method is that it can achieve these goals without
breaking compatibility, further extensions can be added simply by adding
another "layer" of API like this and DSSI do which can be queried by the
host as needed or it can simply fall back if the host or the plugin don't
support it.
seems to me like LV2 has lots of good ideas, but is shooting itself in the
foot with complexity? 
4:05 p.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On Mon, 2006-06-19 at 13:57 -0400, Dave Robillard wrote:
On Mon, 2006-06-19 at 07:51 +1000, Jez Kabanov wrote:
And here's a simple demo host written using libslv2 (it could be a lot
smaller if I didn't wrap things in C++ classes):
http://cvs.savannah.nongnu.org/viewcvs/dino/extras/lv2/?root=dino
--
Lars Luthman - please encrypt any email sent to me if possible
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x04C77E2E
Fingerprint: FCA7 C790 19B9 322D EB7A E1B3 4371 4650 04C7 7E2E
seems to me like LV2 has lots of good ideas, but
is shooting itself in the
foot with complexity?
http://www.scs.carleton.ca/~drobilla/files/slv2_jack_host.c
If that can be less complex, I want to hear how. :)
3:55 p.m.
On Mon, 2006-06-19 at 18:03 +1000, jez(a)technetium.net.au 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-
7:34 p.m.
On Mon, Jun 19, 2006 at 01:55:27PM -0400, Dave Robillard wrote:
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
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.
7:58 p.m.
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!
8:26 p.m.
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:
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.
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).
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
8:57 p.m.
On Mon, Jun 19, 2006 at 11:25:52PM +0100, Steve Harris wrote:
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.
I'd love a plugin host with a degree...
On Mon, Jun 19, 2006 at 11:58:43PM +0200, Fons
Adriaensen wrote:
Aaarrrrrggghhh :-)
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. So the
relation v->f is *exponential* (not logarithmic).
Sure, the LADSPA LOG hint couldn't deal with this meaningfully anyway. - 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 :) :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!
10:44 p.m.
On Tue, 2006-06-20 at 00:57 +0200, Fons Adriaensen wrote:
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.
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.
20 Jun
20 Jun
5:32 a.m.
On Tue, Jun 20, 2006 at 12:57:43 +0200, Fons Adriaensen wrote:
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
: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.
25 Jun
25 Jun
3:52 a.m.
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-
19 Jun
19 Jun
7:29 p.m.
The idea itself isn't stupid, but the implementation is.. let's say less
than wise.
(Consider my personal blatant bias, but...) I'd suggest taking a look at
LV2. There is a data file you can add all this information to (whatever
information you want to), without defining any APIs, changing any host
code, etc, etc.
You definitely shouldn't have to break binary compatibility of things
just to add some hints for hosts, this is the problem LV2 is meant to
solve...
-DR-
while i'm no expert in this area, i'm having some trouble
understanding
your rationale.
how is it breaking binary compatibility?
is binary compatibility even an issue?
shouldn't the host just look for the plugin and load it and check for
the existence of a symbol,
if it exists then call it, otherwise it doesn't and everything is just
as it was.
the host never need know anything about the binary structure of the
plugin except to know that there's a function called "ladspa_descriptor",
adding ladgui certainly doesn't stop old hosts from loading and using
the plugin,
i've modified nekobee to use ladgui and it runs exactly as it used to in
an unmodified rosegarden,
so how is binary compatibilty an issue?
whereas LV2 breaks compatibilty with old plugins (this seems like more
of an issue to me), adds a lot of complexity and requires the host to
use an additional liblv2 library.
- Jez
20 Jun
20 Jun
1:48 a.m.
New subject: [linux-audio-dev] Re: LADSPA Extension for Extra GUI Data
On 6/19/06, Jez Kabanov <jez(a)technetium.net.au> wrote:
Noticed you mentioned dssi gui's here. I'm interested in adding some
kind of dssi wrapper to khagan so gui's built in khagan can be used
for dssi's easily. It's on the todo for the next release
http://openfacts.berlios.de/index-en.phtml?title=Khagan_Todo however
since i wrote the todo i've got a full time job programming python and
my interest in touching a computer has waned and i spend my limited
spare time with my lovely washburn bass and 70's pawn shop acoustic.
If you'd like to add this kind of thing to khagan for dssi's and maybe
lv2 plugins that could be quite interesting.
Loki
The idea itself isn't stupid, but the implementation is.. let's say less
than wise.
(Consider my personal blatant bias, but...) I'd suggest taking a look at
LV2. There is a data file you can add all this information to (whatever
information you want to), without defining any APIs, changing any host
code, etc, etc.
You definitely shouldn't have to break binary compatibility of things
just to add some hints for hosts, this is the problem LV2 is meant to
solve...
-DR-
while i'm no expert in this area, i'm having some trouble
understanding
your rationale.
how is it breaking binary compatibility?
is binary compatibility even an issue?
shouldn't the host just look for the plugin and load it and check for
the existence of a symbol,
if it exists then call it, otherwise it doesn't and everything is just
as it was.
the host never need know anything about the binary structure of the
plugin except to know that there's a function called "ladspa_descriptor",
adding ladgui certainly doesn't stop old hosts from loading and using
the plugin,
i've modified nekobee to use ladgui and it runs exactly as it used to in
an unmodified rosegarden,
so how is binary compatibilty an issue?
whereas LV2 breaks compatibilty with old plugins (this seems like more
of an issue to me), adds a lot of complexity and requires the host to
use an additional liblv2 library.
- Jez
25 Jun
25 Jun
6:30 p.m.
On Mon, 2006-06-19 at 19:31 +1000, Jez Kabanov 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.
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-
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.
26 Jun
26 Jun
6:07 a.m.
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
9:53 a.m.
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:
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!
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.
10:19 a.m.
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:
True enough, but with POL if the frontend and backend mahcines are different
architectures or operating systems then you have a problem.
- Steve
On Sun, Jun 25, 2006 at 04:30:40 -0400, Dave
Robillard 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). 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.
11:03 a.m.
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 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!
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. 
4:05 p.m.
> > 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
..
27 Jun
27 Jun
12:43 a.m.
On Mon, 2006-06-26 at 18:05 +0000, carmen wrote:
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. :)
> > 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
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-
26 Jun
26 Jun
11:38 p.m.
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:
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-
On Mon, Jun 26, 2006 at 01:53:13 +0200, Alfons
Adriaensen wrote:
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. 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.
6524
days inactive
6531
days old
linux-audio-dev@lists.linuxaudio.org
35 comments
11 participants
participants (11)
-
Alfons Adriaensen -
carmen -
Dave Robillard -
Fons Adriaensen -
Jez Kabanov -
jez＠technetium.net.au
-
Lars Luthman -
Loki Davison -
Paul Davis -
Steve Harris -
Thorsten Wilms