9 Apr
2004
9 Apr
'04
9:27 a.m.
hi richard, hi everyone!
i'm just wading through 2k5 linux audio mails, as i'm a little
behind on current affairs due to a lengthy and less-than-smooth
moving of houses.
after reading the LADSPA related threads of about a month ago, a
couple of things became obvious to me:
* LADSPA has some showstopper deficiencies to some developers
* there seems to be an ongoing battle about how essential rdf
metadata support should be: if it's purely optional, then many
things that conceptually should be metadata must be duplicated in
more or less inelegant additions to ladspa.h, and there seems to be
no real consensus on how to do that. if metadata support is
necessary even for simple hosts to create usable guis, we put the
famed 'S' in danger.
* at present, the discussion has reached the "matter of taste" point
and is pretty much dead in the water.
* with no real formal process for the development of LADSPA except
for richard's role as the "benevolent dictator", and richard being
very quiet on the matter, those developers who opt for an extension
of the spec may feel there is no way to get their proposals through.
* maybe for that reason, there has been some imho ill-advised
rhetoric towards fait-accompli tactics.
now wherever LADSPA is heading, one thing is very certain for me:
LADSPA and JACK are the very two projects that absolutely *MUST*
*NOT* *FORK* or even develop "local dialects" at this point in time.
i'm not afraid of forks in almost all contexts, but a forked
"common" api is a dead api. whatever happens, let's not jeopardize
the two major kickass components of linux audio.
there may come a time when LADSPA has become so inert and obsolete
that we should take care of it the darwin way, but this time is
still a long way off.
for that reason, let's try to cram a LADSPA BOF into the already
overflowing schedule at LAConf#2, or at least dedicate a "working
dinner" to the future of LADSPA.
i have this feeling that injecting the face-to-face factor and some
german beer into the discussion might remove some obstacles. :-D
richard, if you are reading this, some comment from your part would
also be helpful imho. i found you have not participated in the
ladspa discussions since release 1.1, which was in august 2002.
it seems everyone still considers you the keeper of LADSPA, and it
might clarify things if you stated
* your opinion on the current discussion;
* your criteria for approving extensions;
* whether you are willing and have the time to retain the role of
official LADSPA maintainer and to have the final say over what goes
in or what doesn't, or let go of this role;
* whether you can make it to LAConf#2 for a beer :)
all the best,
jörn
--
The handles of a craftsman's tools bespeak an absolute simplicity,
the plainest forms affording the greatest range of possibilities for
the user's hand.
That which is overdesigned, too highly specific, anticipates
outcome; the anticipation of outcome guarantees, if not failure, the
absence of grace.
- William Gibson, "All Tomorrow's Parties"
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)
9 Apr
9 Apr
11 a.m.
On Fri, Apr 09, 2004 at 01:20:42PM +0200, Joern Nettingsmeier wrote:
* LADSPA has some showstopper deficiencies to some
developers
* there seems to be an ongoing battle about how essential rdf
metadata support should be: if it's purely optional, then many
things that conceptually should be metadata must be duplicated in
more or less inelegant additions to ladspa.h, and there seems to be
no real consensus on how to do that. if metadata support is
necessary even for simple hosts to create usable guis, we put the
famed 'S' in danger.
* at present, the discussion has reached the "matter of taste" point
and is pretty much dead in the water.
"The noise has died down", to use Steve's expression, but without
any result whatsoever.
* with no real formal process for the development of
LADSPA except
for richard's role as the "benevolent dictator", and richard being
very quiet on the matter, those developers who opt for an extension
of the spec may feel there is no way to get their proposals through.
* maybe for that reason, there has been some imho ill-advised
rhetoric towards fait-accompli tactics.
I have so far presented three proposals. One of them was just a matter
of interpretation. The two others would have no ill effect at all except
using one the 22 (IIRC) available hint bits, and in a way that could be
safely ignored by all existing hosts. In all three cases the net result
was zero. Since I did not propose these things in order to waste my own
time nor that of the other list members, but because a problem presented
itself during development and needed a solution, this *is* frustrating.
If the only approval process is the intervention of a "benevolent
dictator", then one would at least expect for this person to take up
his responsabilities, take part in the discussion, and decide.
If this, for some reason, is not possible then another approval
process should be installed.
If the current situtation prevails, the end result will be that
either some people will introduce their own plugin format, or that
at some point there will be a fait acccompli. It seems like either
of these will be required in order to get things moving at all.
for that reason, let's try to cram a LADSPA BOF
into the already
overflowing schedule at LAConf#2, or at least dedicate a "working
dinner" to the future of LADSPA.
i have this feeling that injecting the face-to-face factor and some
german beer into the discussion might remove some obstacles. :-D
I'd prefer some wine, but otherwise this may be a good idea. Fact is
that the conference will already be a very busy affair, so this will
need some planning.
--
FA
12:34 p.m.
On Fri, Apr 09, 2004 at 02:53:10 +0200, Alfons Adriaensen wrote:
I can't see how that, or any other process, would agree on any of the
proposed fixes given the current lack of concensus.
Yup, I think its a good idea though.
- Steve
* maybe for
that reason, there has been some imho ill-advised
rhetoric towards fait-accompli tactics.
I have so far presented three proposals. One of them was just a matter
of interpretation. The two others would have no ill effect at all except
using one the 22 (IIRC) available hint bits, and in a way that could be
safely ignored by all existing hosts. In all three cases the net result
was zero. Since I did not propose these things in order to waste my own
time nor that of the other list members, but because a problem presented
itself during development and needed a solution, this *is* frustrating.
If the only approval process is the intervention of a "benevolent
dictator", then one would at least expect for this person to take up
his responsabilities, take part in the discussion, and decide.
If this, for some reason, is not possible then another approval
process should be installed. for that
reason, let's try to cram a LADSPA BOF into the already
overflowing schedule at LAConf#2, or at least dedicate a "working
dinner" to the future of LADSPA.
i have this feeling that injecting the face-to-face factor and some
german beer into the discussion might remove some obstacles. :-D
I'd prefer some wine, but otherwise this may be a good idea. Fact is
that the conference will already be a very busy affair, so this will
need some planning.
12:54 p.m.
On Fri, Apr 09, 2004 at 03:27:36PM +0100, Steve Harris wrote:
The advantage of having a real dictator is that no concensus is needed :-)
--
Fons
On Fri, Apr 09, 2004 at 02:53:10 +0200, Alfons
Adriaensen wrote:
If the only
approval process is the intervention of a "benevolent
dictator", then one would at least expect for this person to take up
his responsabilities, take part in the discussion, and decide.
If this, for some reason, is not possible then another approval
process should be installed.
I can't see how that, or any other process, would agree on any of the
proposed fixes given the current lack of concensus.
1:58 p.m.
On Fri, Apr 09, 2004 at 04:47:59 +0200, Alfons Adriaensen wrote:
I think the word "benevolent" was used ;)
- Steve
I can't
see how that, or any other process, would agree on any of the
proposed fixes given the current lack of concensus.
The advantage of having a real dictator is that no concensus is needed :-) 
3:20 p.m.
On Fri, Apr 09, 2004 at 04:51:57PM +0100, Steve Harris wrote:
On Fri, Apr 09, 2004 at 04:47:59 +0200, Alfons
Adriaensen wrote:
Yes, but a benevolent dictator, seeing his people divided and in
misery, should act. :)
--
Fons
The advantage of having a real dictator is that
no concensus is needed :-)
I think the word "benevolent" was used ;)
7:33 p.m.
Hi!
Besides the meeting at the conference, which really seems a good idea,
forming a small group might be helpful. I've read all the mails and the
"benevolent dictator" has kept quiet up to now. So I ask: Who is technically
interested in the extension of ladspa? Who seems to know about the api, it's
short-comings and who might have reasonably realistic ideas on how to
continue?
Interested in extending ladspa are: the LADSPA-plugin developers (mainly
Steve and Fons I think) and the application programmers (mainly Paul and the
ams-people). I don't use gui-apps, but from what I hear Ardour and AMS are the
apps _I_ know, which are most active among those who really need more than
there is.
Just a stupid idea of mine, but I hope it's a good one... :-)
Kindest regards
Julien
--------
Music was my first love and it will be my last (John Miles)
======== FIND MY WEB-PROJECT AT: ========
http://ltsb.sourceforge.net - the Linux TextBased Studio guide
2:17 p.m.
From looking at the schedule, it appears to me that we
have 2 choices:
1) Friday evening dinner (other evenings have concerts etc)
2) a meeting at, perhaps, 10am on Friday, Saturday or Sunday.
Without a dictator, I guess we're a democracy, and given that 2 of the
3 names in the LADSPA header file will be present at ZKM, we can get a
majority vote :)
I personally would favor the morning option because the time limit
might make things more productive. But assuming we can find a decent
dry reisling, dinner is fine too.
--p
11 Apr
11 Apr
10:26 a.m.
frank, matthias, could you perhaps just decide on a date, and
announce it on the zkm website as a non-public (i.e. not for casual
passers-by, but of course free for all interested developers)?
i like the morning option, too, but not sunday, since there's
already a panel discussion in the afternoon.
i'd vote for friday, 10:00, so that if something useful comes up,
there's the option to agree on a "dinner session" later to continue
the debate.
regards,
jörn
Paul Davis wrote:
--
The handles of a craftsman's tools bespeak an absolute simplicity,
the plainest forms affording the greatest range of possibilities for
the user's hand.
That which is overdesigned, too highly specific, anticipates
outcome; the anticipation of outcome guarantees, if not failure, the
absence of grace.
- William Gibson, "All Tomorrow's Parties"
Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)
From looking at
the schedule, it appears to me that we have 2 choices:
1) Friday evening dinner (other evenings have concerts etc)
2) a meeting at, perhaps, 10am on Friday, Saturday or Sunday.
Without a dictator, I guess we're a democracy, and given that 2 of the
3 names in the LADSPA header file will be present at ZKM, we can get a
majority vote :)
I personally would favor the morning option because the time limit
might make things more productive. But assuming we can find a decent
dry reisling, dinner is fine too.
--p
13 Apr
13 Apr
8:17 a.m.
On Sun, 11 Apr 2004, Joern Nettingsmeier wrote:
frank, matthias, could you perhaps just decide on a
date, and announce it on
the zkm website as a non-public (i.e. not for casual passers-by, but of course
free for all interested developers)?
OK, we will schedule it on Friday 10.00, as you suggested. Workshop/BOF
schedule will be released tomorrow.
i like the morning option, too, but not sunday, since
there's already a panel
discussion in the afternoon.
i'd vote for friday, 10:00, so that if something useful comes up, there's the
option to agree on a "dinner session" later to continue the debate.
regards,
jörn
Paul Davis wrote:
--
Dr. Matthias Nagorni
SuSE Linux AG
Maxfeldstr. 5 phone: +49 911 74053375
D - 90409 Nuernberg fax : +49 911 74053483
From
looking at the schedule, it appears to me that we have 2 choices:
1) Friday evening dinner (other evenings have concerts etc)
2) a meeting at, perhaps, 10am on Friday, Saturday or Sunday.
Without a dictator, I guess we're a democracy, and given that 2 of the
3 names in the LADSPA header file will be present at ZKM, we can get a
majority vote :)
I personally would favor the morning option because the time limit
might make things more productive. But assuming we can find a decent
dry reisling, dinner is fine too.
--p
14 Apr
14 Apr
10:28 a.m.
[Matthias Nagorni]
On Sun, 11 Apr 2004, Joern Nettingsmeier wrote:
the LADSPA patch proposal i have been hatching -- should you care to
discuss it -- has undergone one more revision. you can find it, along
with assorted sample implementation code and some 'propaganda', at
http://quitte.de/ladspa/
(latest revision is +GROUP, -RANDOMIZED.)
unfortunately i won't be able to join you at LAConf, which i hope
will be an enjoyable and productive experience for you all.
tim
frank, matthias, could you perhaps just decide on
a date, and announce it on
the zkm website as a non-public (i.e. not for casual passers-by, but of course
free for all interested developers)?
OK, we will schedule it on Friday 10.00, as you suggested. Workshop/BOF
schedule will be released tomorrow.
11:52 a.m.
On Wed, Apr 14, 2004 at 02:17:07PM +0200, Tim Goetze wrote:
(latest revision is +GROUP, -RANDOMIZED.)
Tim, am I correct in assuming that when you mean e.g. [A B C] D E [F G] H
where [] indicates the grouping, then A, C, F, G will have the GROUP hint
bit set ? The text is a litte ambiguous here, it could be interpreted
as if A, D, F, H would be marked, and this will not work in all cases.
It's a nice idea, and as basic e.g. the NULL hint.
A more general way would be structured names, e.g.
/Filter 1/frequency
/Filter 1/gain
/Filter 1/Q
An intelligent host would take the names apart, and create a group 'Filter 1'
with three elements. This is close to OSC of course, and generalises to more
levels of groupting.
--
FA
2:48 p.m.
[Alfons Adriaensen]
On Wed, Apr 14, 2004 at 02:17:07PM +0200, Tim Goetze
wrote:
the latter (A, D, F, H) describes the intention. a better name would
be *_GROUP_START, you're probably right about the ambiguity. i'll try
to clarify this.
(latest revision is +GROUP, -RANDOMIZED.)
Tim, am I correct in assuming that when you mean e.g. [A B C] D E [F G] H
where [] indicates the grouping, then A, C, F, G will have the GROUP hint
bit set ? The text is a litte ambiguous here, it could be interpreted
as if A, D, F, H would be marked, and this will not work in all cases. A more general way would be structured names, e.g.
/Filter 1/frequency
/Filter 1/gain
/Filter 1/Q
An intelligent host would take the names apart, and create a group 'Filter 1'
with three elements. This is close to OSC of course, and generalises to more
levels of groupting.
yes, without a distinct group ID or proper hierarchical scheme like
the one you describe here there'll always be a lot of setups that
can't be expressed (RDF, is that you knocking?) -- but this will do
for the simpler cases of breaking up a line of GUI controls in the
meantime.
tim
7562
days inactive
7567
days old
linux-audio-dev@lists.linuxaudio.org
12 comments
8 participants
participants (8)
-
Alfons Adriaensen -
Fons Adriaensen -
Joern Nettingsmeier -
Julien Claassen -
Matthias Nagorni -
Paul Davis -
Steve Harris -
Tim Goetze