Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Sun, Feb 27, 2011 at 06:21:29AM -0500, Thomas Vecchione wrote:

> Fons replied off list and we discussed his example some, The situations was
> similar to what i had thought, where a 4 point edit was one possible way to
> do it, but far from the only.solution, and probably wouldn't be what I
> personally used.

Exactly, a 4-pt is not the only way to do it, and I'd probably split
it up into two edits anyway unless the part to be replaced was very
short (which happens, I've been replacing single notes in some cases).

What I don't accept is the suggestion that this sort of thing is never
necessary, and that if it is, that is just the result of using the
wrong 'workflow'. So far I haven't seen any alternative 'workflow'
that would actually get the job done.

>  The real issue was A2's lack of an ability to move
> automation with regions, which Carl has addressed in A3 IIRC.

Not in this case, as there was no automation. The real issue is
that it is very difficult to move everything to the right of the
edit, in particular if this alternates with trimming the start
point, trimming the end point of the left side, and listening
to the result. It requires constant changing of selections,
and zoom factors. One 'erreur de manip' and something gets
damaged, and if you don't notice that immediately (and very
probably you don't if you are zoomed in) it becomes a nightmare
to repair.

The underlying problem are 

1. That everything is 'visual', done by actually moving regions
   and their endpoints on screen (and quite ofter being sure you
   get the right one of these actions is an exercise by itself).

2. That Ardour has no idea at all of what you want to do, it just
   sees a series of individual operations and consequently can't
   provide any support. For example if you want to listen to the
   end of the left part followed by silence, or the start of the
   right part (to trim them), the only way is to move the right
   part away, destroying any tentative edit you may already have.

Ciao,

-- 
FA


 



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Thomas Vecchione]

Yes film and TV post is where I have heard of it being more useful, but
since I just got up I will leave that for the moment until my brain is more
awake;)

Fons replied off list and we discussed his example some, The situations was
similar to what i had thought, where a 4 point edit was one possible way to
do it, but far from the only.solution, and probably wouldn't be what I
personally used.  The real issue was A2's lack of an ability to move
automation with regions, which Carl has addressed in A3 IIRC.  I didn't
spell this out as much as I should have in my reply to Fons on list however
due to typing on my cell phone at the time:)

Seablade

PS For the record yes I understand an overdub wouldn't be likely in
classical recording, an even less so in tracking live performances which is
more of what I am used to doing obviously, but in that particular situation
is something I could see doing since the singer had requested it I assume
they were present.  However this wasn't the situation presented above, thus
my post above.

2011/2/27 Andres Cabrera 

> Hi,
>
> This feature is actually also very useful in post production for film
> or TV, where often you get a video edit after you've started doing
> your mixing, and you have to move big blocks of tracks in time. I'd
> also like to know if there's a simple way to do this in ardour, or to
> add my vote for it =)
>
> Cheers,
> Andres
>
> 2011/2/27 Jörn Nettingsmeier :
> > On 02/27/2011 01:05 AM, Thomas Vecchione wrote:
> >>
> >> Fons
> >>
> >> Being someone that tracks recordings live constantly, I am curious, if
> >> the singer only wanted to overdub one section of their vocals with
> >> another, and you are not touching the remainder of the recorded tracks,
> >> exactly what stops you from doing a standard punch in/out in your
> example?
> >
> > in classical recording sessions, overdubs happen rarely if ever.
> > i guess the situation here is that multiple full or partial takes were
> > recorded with the full ensemble, and the editing happens afterwards, when
> > all musicians are gone.
> > iiuc, the soloist requested one section to be replaced with another take.
> > since there is no "click", this usually means that the part after the new
> > spliced-in section will move in time, slightly.
> > which is a bit of a problem in ardour while you haven't consolidated
> region
> > fragments (which often you don't want to do until the very end), because
> you
> > have to be very careful to move all subsequent regions.
> > easy in the vertical thanks to edit groups, but quite hard in the
> > horizontal. or maybe i'm overlooking yet another feature?
> >
> > best,
> >
> > jörn
> >
> >
> >
> > ___
> > Linux-audio-dev mailing list
> > Linux-audio-dev@lists.linuxaudio.org
> > http://lists.linuxaudio.org/listinfo/linux-audio-dev
> >
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Andres Cabrera]

Hi,

This feature is actually also very useful in post production for film
or TV, where often you get a video edit after you've started doing
your mixing, and you have to move big blocks of tracks in time. I'd
also like to know if there's a simple way to do this in ardour, or to
add my vote for it =)

Cheers,
Andres

2011/2/27 Jörn Nettingsmeier :
> On 02/27/2011 01:05 AM, Thomas Vecchione wrote:
>>
>> Fons
>>
>> Being someone that tracks recordings live constantly, I am curious, if
>> the singer only wanted to overdub one section of their vocals with
>> another, and you are not touching the remainder of the recorded tracks,
>> exactly what stops you from doing a standard punch in/out in your example?
>
> in classical recording sessions, overdubs happen rarely if ever.
> i guess the situation here is that multiple full or partial takes were
> recorded with the full ensemble, and the editing happens afterwards, when
> all musicians are gone.
> iiuc, the soloist requested one section to be replaced with another take.
> since there is no "click", this usually means that the part after the new
> spliced-in section will move in time, slightly.
> which is a bit of a problem in ardour while you haven't consolidated region
> fragments (which often you don't want to do until the very end), because you
> have to be very careful to move all subsequent regions.
> easy in the vertical thanks to edit groups, but quite hard in the
> horizontal. or maybe i'm overlooking yet another feature?
>
> best,
>
> jörn
>
>
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Jörn Nettingsmeier]

On 02/27/2011 01:05 AM, Thomas Vecchione wrote:

Fons

Being someone that tracks recordings live constantly, I am curious, if
the singer only wanted to overdub one section of their vocals with
another, and you are not touching the remainder of the recorded tracks,
exactly what stops you from doing a standard punch in/out in your example?


in classical recording sessions, overdubs happen rarely if ever.
i guess the situation here is that multiple full or partial takes were 
recorded with the full ensemble, and the editing happens afterwards, 
when all musicians are gone.
iiuc, the soloist requested one section to be replaced with another 
take. since there is no "click", this usually means that the part after 
the new spliced-in section will move in time, slightly.
which is a bit of a problem in ardour while you haven't consolidated 
region fragments (which often you don't want to do until the very end), 
because you have to be very careful to move all subsequent regions.
easy in the vertical thanks to edit groups, but quite hard in the 
horizontal. or maybe i'm overlooking yet another feature?


best,

jörn



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Sat, Feb 26, 2011 at 04:18:30PM -0800, Mark Knecht wrote:

> I don't give a flip about convolution reverbs, LVL2 gtk vs qt, or
> where I host a VST.

-:) Strangely enough, this is not about any of these subjects :-)
 
> I do however love a good piece of music.
> Thanks for sharing.

Verdi, Rigoletto. 

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Mark Knecht]

On Sat, Feb 26, 2011 at 7:40 AM, Fons Adriaensen  wrote:

>
> A simple case:
>
> 
>
> After this was edited (9 fragments from 4 takes), the singer wanted
> to replace the part "del prigioniere misero conforta l'egra mente"
> [2:03 to 2:27] by another take.
>


I don't give a flip about convolution reverbs, LVL2 gtk vs qt, or
where I host a VST.

I do however love a good piece of music.

Thanks for sharing.

- Mark
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Thomas Vecchione]

Fons

Being someone that tracks recordings live constantly, I am curious, if the
singer only wanted to overdub one section of their vocals with another, and
you are not touching the remainder of the recorded tracks, exactly what
stops you from doing a standard punch in/out in your example?

Even if you are referring to replacing a mixdown take, I am not certain 4
point editing is to much of a benefit there persay to be honest, as I have
done this without it quite well in the past as I often have to edit down
recordings for dance choreographers for modified music in a way you can't
tell it is edited obviously.

I have never used 4 point editing, and have done mixing of all varieties,
musical and non, from many different genres including some classical.  There
are points where I can easily see 4 point editing being useful as has been
explained to me in the past by people that do use it, but this is not one of
them if I am understanding your question correctly. (Of course I can't think
of a good example at the moment where I was thinking it would be useful, but
I remember being told some in the past and thinking it would be).

   Seablade


On Sat, Feb 26, 2011 at 10:40 AM, Fons Adriaensen wrote:

> On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:
>
> > the position that i take with N-point editing is not that there is
> > some other way to do "the following". There isn't. its that the way of
> > approaching the task that leads to needing to do "the following" is
> > rooted in an older way of thinking about the overall workflow.
>
> Tell that to your customer when he (or she in this case) wants you
> to replace part of an edited track with the same fragment from
> another take.
>
> A simple case:
>
> <
> http://kokkinizita.linuxaudio.org/linuxaudio/downloads/d_amor_sull_ali_rosee2.mp3
> >
>
> After this was edited (9 fragments from 4 takes), the singer wanted
> to replace the part "del prigioniere misero conforta l'egra mente"
> [2:03 to 2:27] by another take.
>
> Now I could have told her that what she wanted was 'rooted in an
> older way of thinking', or that she was stupid and should have had
> that bright idea before we had done the five edits following this
> fragment, but I didn't and actually performed the edit to her
> satisfaction.
>
> Now this was a simple demo with just the piano instead of a full
> orchestra. The latter could easily be more than 20 tracks if the
> recording is done live and no mics must be visible. And mixing it
> before editing is usually *not* and option.
>
>
> Quiz2: there are 10 edits in this recording, free beer at LAC2011
> if you can find 5 of them.
>
> Ciao,
>
> --
> FA
>
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Renato]

On Sat, 26 Feb 2011 10:52:05 -0500
Paul Davis  wrote:

> On Sat, Feb 26, 2011 at 10:40 AM, Fons Adriaensen
>  wrote:
> > On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:
> >
> >> the position that i take with N-point editing is not that there is
> >> some other way to do "the following". There isn't. its that the
> >> way of approaching the task that leads to needing to do "the
> >> following" is rooted in an older way of thinking about the overall
> >> workflow.
> >
> > Tell that to your customer when he (or she in this case) wants you
> > to replace part of an edited track with the same fragment from
> > another take.
> 
> i'm confused about who the customer is. the older way of thinking
> about the overall workflow is an attribute of the engineer/editor, not
> the singer.
> if the engineer/editor is the customer, i'd tell them to use another
> program right now because ardour doesn't support their workflow. i try
> not to spend much time convincing people to work in a different way
> than they are used to, it seems pretty pointless to me since i don't
> really believe that one way is superior to the others (though some are
> definitely more connected to ideas rooted in some kind physical
> operation like tape splicing).
> 
> hint: there's no reason to replace the section from [2:03 to 2:27]
> with another take at all.
> 

hi,
I'm noob with ardour but I'd like to understand, how would one solve a
problem such as the one posed by Fons?

If I understand correctly you're saying that if you use a different
workflow while setting up the project / recording you wan't fall in
this problem, so could you explain what is this different workflow?

cheers
renato
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Sat, Feb 26, 2011 at 10:40 AM, Fons Adriaensen  wrote:
> On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:
>
>> the position that i take with N-point editing is not that there is
>> some other way to do "the following". There isn't. its that the way of
>> approaching the task that leads to needing to do "the following" is
>> rooted in an older way of thinking about the overall workflow.
>
> Tell that to your customer when he (or she in this case) wants you
> to replace part of an edited track with the same fragment from
> another take.

i'm confused about who the customer is. the older way of thinking
about the overall workflow is an attribute of the engineer/editor, not
the singer.
if the engineer/editor is the customer, i'd tell them to use another
program right now because ardour doesn't support their workflow. i try
not to spend much time convincing people to work in a different way
than they are used to, it seems pretty pointless to me since i don't
really believe that one way is superior to the others (though some are
definitely more connected to ideas rooted in some kind physical
operation like tape splicing).

hint: there's no reason to replace the section from [2:03 to 2:27]
with another take at all.

> Now I could have told her that what she wanted was 'rooted in an
> older way of thinking', or that she was stupid and should have had
> that bright idea before we had done the five edits following this
> fragment,

that would just have confirmed that you have the skills to be abrasive
and difficult to get along with when you choose to.

> but I didn't and actually performed the edit to her
> satisfaction.

much better idea.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:

> the position that i take with N-point editing is not that there is
> some other way to do "the following". There isn't. its that the way of
> approaching the task that leads to needing to do "the following" is
> rooted in an older way of thinking about the overall workflow.

Tell that to your customer when he (or she in this case) wants you
to replace part of an edited track with the same fragment from
another take. 

A simple case:



After this was edited (9 fragments from 4 takes), the singer wanted
to replace the part "del prigioniere misero conforta l'egra mente"
[2:03 to 2:27] by another take.

Now I could have told her that what she wanted was 'rooted in an
older way of thinking', or that she was stupid and should have had
that bright idea before we had done the five edits following this
fragment, but I didn't and actually performed the edit to her
satisfaction.

Now this was a simple demo with just the piano instead of a full
orchestra. The latter could easily be more than 20 tracks if the
recording is done live and no mics must be visible. And mixing it
before editing is usually *not* and option.


Quiz2: there are 10 edits in this recording, free beer at LAC2011
if you can find 5 of them.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Joel Roth]

On Fri, Feb 25, 2011 at 02:02:09PM +0100, Jens M Andreasen wrote:
> 
> On Fri, 2011-02-25 at 11:28 +, Fons Adriaensen wrote:
> 
> > Also noticed  'ingen fara' -> no problem and 'ingen aning' -> no idea.
> > 
> In a compound statement, yes
> 
> And then You have the Scottish Gaelic "inghean" from Old Irish "ingen"
> meaning "daughter" which might be related to the Swedish/Norwegian
> female name "Inga" which in turn also happens to be the pluralis form of
> "none"?
> 
> Or it could be a reference to InGen systems, from Jurassic Parc ..

Or a reference to the Japanese term meaning 'string beans'.

-- 
Joel Roth
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Giblock]

Clear your cookies and try again.  Google must know you are involved
in Linux Audio ;)

On Fri, Feb 25, 2011 at 1:01 PM, Alexandre Prokoudine
 wrote:
> On Fri, Feb 25, 2011 at 8:50 PM, David Robillard wrote:
>
>> It's also the company in Jurassic Park. One day I'll make it to #1
>> Google hit. One day!
>
> You already have :) Just try it.
>
> Alexandre Prokoudine
> http://libregraphicsworld.org
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On Fri, Feb 25, 2011 at 8:50 PM, David Robillard wrote:

> It's also the company in Jurassic Park. One day I'll make it to #1
> Google hit. One day!

You already have :) Just try it.

Alexandre Prokoudine
http://libregraphicsworld.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Fri, 2011-02-25 at 00:34 +, Fons Adriaensen wrote:
> On Thu, Feb 24, 2011 at 06:47:10PM -0500, David Robillard wrote:
> 
> > On Thu, 2011-02-24 at 21:39 +, Fons Adriaensen wrote:
> > > On Fri, Feb 25, 2011 at 12:20:44AM +0300, Alexandre Prokoudine wrote:
> > [...]
> > > > "This is an error that any DSP student is allowed to make once".
> > > 
> > > This is absolutely true for the one I referred to.
> > 
> > As absolutely true as when I say the obviously terrible software
> > architecture / design decisions that come out of certain DSP heads
> > are... well, obvious terrible to anyone who actually knows what they are
> > doing in that field?
> 
> That could very well be the case.
> 
> With N >= 1000:
> There are some things I know about, N times more things I'm
> interested in, know a little about and want to learn more,
> and again N times more I don't know anything about. That's
> life.

Indeed.

> Now I'm here, I do have a question. And please just take it
> for what it is and don't look for anything behind it as there
> isn't anything.
> 
> How did you arrive at the name 'ingen' ?

Mainly, INstrument GENerator, and the fact that it's like "engine".

> This evening I happened to stumble on an episode of 'Midsommer
> Murders', a famous English detective TV series, on Youtube.
> Strangely enough it had Swedish (I think) subtitles. From which
> I learned that 'ingen' is Swedish for 'no, nobody, nothing' or
> similar...
> 
> Again, that's not meant to be a comment on your program, just
> curious.

Yeah, if I had a nickel for every time that's been mentioned to me I
wouldn't have to beg for donations anymore :)

I actually like the connection in a way, since the whole point of Ingen
is to be a minimal framework in which to wire up generic plugins to do
what you want. The plugins are the rock stars, Ingen is just the stage.
I also have a penchant for Zen, and there's certainly no thing wrong
with no thing ;)

It's also the company in Jurassic Park. One day I'll make it to #1
Google hit. One day!

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Jens M Andreasen]

On Fri, 2011-02-25 at 11:28 +, Fons Adriaensen wrote:

> Also noticed  'ingen fara' -> no problem and 'ingen aning' -> no idea.
> 
In a compound statement, yes

And then You have the Scottish Gaelic "inghean" from Old Irish "ingen"
meaning "daughter" which might be related to the Swedish/Norwegian
female name "Inga" which in turn also happens to be the pluralis form of
"none"?

Or it could be a reference to InGen systems, from Jurassic Parc ..

  http://ingenaning.com/noidea.html

/j

-- 

Brand new stockings
http://mx44.linux.dk/notturno/brand_new_stockings.mp3


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Fri, Feb 25, 2011 at 01:42:46AM +0100, Jens M Andreasen wrote:
> 
> On Fri, 2011-02-25 at 00:34 +, Fons Adriaensen wrote:
> 
> > I learned that 'ingen' is Swedish for 'no, nobody, nothing' or
> > similar...
> 
> Nobody it is.
 
Tack :-)

Also noticed  'ingen fara' -> no problem and 'ingen aning' -> no idea.

-- 
FA
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Jens M Andreasen]

On Fri, 2011-02-25 at 00:34 +, Fons Adriaensen wrote:

> I learned that 'ingen' is Swedish for 'no, nobody, nothing' or
> similar...

Nobody it is.

-- 

Brand new stockings
http://mx44.linux.dk/notturno/brand_new_stockings.mp3


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Thu, Feb 24, 2011 at 06:47:10PM -0500, David Robillard wrote:

> On Thu, 2011-02-24 at 21:39 +, Fons Adriaensen wrote:
> > On Fri, Feb 25, 2011 at 12:20:44AM +0300, Alexandre Prokoudine wrote:
> [...]
> > > "This is an error that any DSP student is allowed to make once".
> > 
> > This is absolutely true for the one I referred to.
> 
> As absolutely true as when I say the obviously terrible software
> architecture / design decisions that come out of certain DSP heads
> are... well, obvious terrible to anyone who actually knows what they are
> doing in that field?

That could very well be the case.

With N >= 1000:
There are some things I know about, N times more things I'm
interested in, know a little about and want to learn more,
and again N times more I don't know anything about. That's
life.

Now I'm here, I do have a question. And please just take it
for what it is and don't look for anything behind it as there
isn't anything.

How did you arrive at the name 'ingen' ?

This evening I happened to stumble on an episode of 'Midsommer
Murders', a famous English detective TV series, on Youtube.
Strangely enough it had Swedish (I think) subtitles. From which
I learned that 'ingen' is Swedish for 'no, nobody, nothing' or
similar...

Again, that's not meant to be a comment on your program, just
curious.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Thu, 2011-02-24 at 21:39 +, Fons Adriaensen wrote:
> On Fri, Feb 25, 2011 at 12:20:44AM +0300, Alexandre Prokoudine wrote:
[...]
> > "This is an error that any DSP student is allowed to make once".
> 
> This is absolutely true for the one I referred to.

As absolutely true as when I say the obviously terrible software
architecture / design decisions that come out of certain DSP heads
are... well, obvious terrible to anyone who actually knows what they are
doing in that field?

The trick is to know what you're good at, and shut up about the rest.

-dr (Who couldn't - and thus won't try to - tell you the first thing
about DSP, or classical music editing, or ...)


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Fri, Feb 25, 2011 at 01:05:03AM +0300, Alexandre Prokoudine wrote:

> "'True. After all those years none of the 'DSP experts' developing Jamin
> has noticed anything wrong when listening to it (it's quite obvious
> actually), let alone done a simple measurement that could have revealed
> this problem even before the first release."

Which is simply true. A simple measurement would have revealed that
particular problem. Some critical listening would have revealed it
as well. 

The term 'DSP experts' was first used not by me, but in an attempt
to discredit what I wrote. So don't blame me for quoting it.

> These were your words.

And I'll repeat them any time you want.

-- 
FA
 
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On 2/25/11, Fons Adriaensen wrote:

>> You know, I find this kind of attitude quite dangerous.
>
> What attitude ?

See below.

>> JAMin developers not having clue,
>
> Didn't write that.

*sigh*

Really?

"'True. After all those years none of the 'DSP experts' developing Jamin
has noticed anything wrong when listening to it (it's quite obvious
actually), let alone done a simple measurement that could have revealed
this problem even before the first release."

These were your words.

So what I'm seeiing is that while JAMin guys write in their list that
you, Fons, have interesting ideas about improvements in the backend,
you, in return, write that utter bullshit. And then you pretend you
never did that.

And now I see this repeating with Ardour team.

>> Especially since we are *sort of*  community that is supposed
>> to *sort of* share knowledge.
>
> Indeed. And what knowledge have you been sharing lately ?

Lately I've been spreading tolerance and respect to fellow community
members with a shovel. I'm pretty sure I can find some for you.

Alexandre Prokoudine
http://libregraphicsworld.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Nick Copeland]

You are full of even more shit than I am - can you just f-off and write your 
own 
DAW? Or at least go and write apps for an OS that has other developer lists.

"we have to make sure that old fag [Fons] does disappear”.
Jim Wong, president of IT products, Acer




> Date: Thu, 24 Feb 2011 21:58:12 +
> From: f...@linuxaudio.org
> To: p...@linuxaudiosystems.com
> CC: linux-audio-dev@lists.linuxaudio.org
> Subject: Re: [LAD] [ANN] IR: LV2 Convolution Reverb
> 
> On Thu, Feb 24, 2011 at 04:12:58PM -0500, Paul Davis wrote:
> 
> > On Thu, Feb 24, 2011 at 3:45 PM, Fons Adriaensen  
> > wrote:
> > > On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:
> > >
> > >> the position that i take with N-point editing is not that there is
> > >> some other way to do "the following". There isn't. its that the way of
> > >> approaching the task that leads to needing to do "the following" is
> > >> rooted in an older way of thinking about the overall workflow.
> > >
> > > The only conclusion I can arrive at from this, and despite lots
> > > of effort to avoid it, is that you don't have a clue as to what
> > > is involved in editing e.g. classic music recordings.
> > 
> > unfortunately, your conclusion would be wrong.
> 
> Unfortunately, I don't think so. Or you have other reasons
> for not providing the sort of functionality that is needed.
> 
> Without a single exception, everyone involved in this sort of
> work (classic or more generally, 'acoustic' music recording
> and editing) that I've shown Ardour to has said more or less
> the same thing: 1. it can't do it, or at best in a very clumsy
> way, and 2. it's a marvellous program otherwise, and it would
> probably take very little to solve its obvious problems.
> 
> Not my words, but I do agree with them.
> 
> -- 
> FA
> 
> 
> 
> 
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
  ___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Thu, Feb 24, 2011 at 04:12:58PM -0500, Paul Davis wrote:

> On Thu, Feb 24, 2011 at 3:45 PM, Fons Adriaensen  wrote:
> > On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:
> >
> >> the position that i take with N-point editing is not that there is
> >> some other way to do "the following". There isn't. its that the way of
> >> approaching the task that leads to needing to do "the following" is
> >> rooted in an older way of thinking about the overall workflow.
> >
> > The only conclusion I can arrive at from this, and despite lots
> > of effort to avoid it, is that you don't have a clue as to what
> > is involved in editing e.g. classic music recordings.
> 
> unfortunately, your conclusion would be wrong.

Unfortunately, I don't think so. Or you have other reasons
for not providing the sort of functionality that is needed.

Without a single exception, everyone involved in this sort of
work (classic or more generally, 'acoustic' music recording
and editing) that I've shown Ardour to has said more or less
the same thing: 1. it can't do it, or at best in a very clumsy
way, and 2. it's a marvellous program otherwise, and it would
probably take very little to solve its obvious problems.

Not my words, but I do agree with them.

-- 
FA




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Fri, Feb 25, 2011 at 12:20:44AM +0300, Alexandre Prokoudine wrote:

> You know, I find this kind of attitude quite dangerous.

What attitude ?

> JAMin developers not having clue,

Didn't write that.

> Ardour developers not having and clue

About one very specfic issue.

> "This is an error that any DSP student is allowed to make once".

This is absolutely true for the one I referred to.

> Especially since we are *sort of*  community that is supposed
> to *sort of* share knowledge.

Indeed. And what knowledge have you been sharing lately ?

--
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On 2/24/11, Fons Adriaensen wrote:

>> the position that i take with N-point editing is not that there is
>> some other way to do "the following". There isn't. its that the way of
>> approaching the task that leads to needing to do "the following" is
>> rooted in an older way of thinking about the overall workflow.
>
> The only conclusion I can arrive at from this, and despite lots
> of effort to avoid it, is that you don't have a clue as to what
> is involved in editing e.g. classic music recordings.

You know, I find this kind of attitude quite dangerous. JAMin
developers not having clue, Ardour developers not having and clue, and
then there's Fons in the shining armour never telling what is the
right thing exactly, because "This is an error that any DSP student is
allowed to make once". As much as I treasure your contribution (and I
do), this is really disturbing. Especially since we are *sort of*
community that is supposed to *sort of* share knowledge.

Alexandre Prokoudine
http://libregraphicsworld.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Thu, Feb 24, 2011 at 3:45 PM, Fons Adriaensen  wrote:
> On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:
>
>> the position that i take with N-point editing is not that there is
>> some other way to do "the following". There isn't. its that the way of
>> approaching the task that leads to needing to do "the following" is
>> rooted in an older way of thinking about the overall workflow.
>
> The only conclusion I can arrive at from this, and despite lots
> of effort to avoid it, is that you don't have a clue as to what
> is involved in editing e.g. classic music recordings.

unfortunately, your conclusion would be wrong.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Thu, Feb 24, 2011 at 12:39:04PM -0500, Paul Davis wrote:
 
> the position that i take with N-point editing is not that there is
> some other way to do "the following". There isn't. its that the way of
> approaching the task that leads to needing to do "the following" is
> rooted in an older way of thinking about the overall workflow.

The only conclusion I can arrive at from this, and despite lots
of effort to avoid it, is that you don't have a clue as to what
is involved in editing e.g. classic music recordings.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[drew Roberts]

On Thursday 24 February 2011 12:09:19 David Robillard wrote:
> This is, of course, a big problem in terms of our greater mission
> to provide software that caters to the needs of precisely nobody while
> irritating everybody else.
>
> To resolve this situation, we now have an exciting new Clippy inspired
> assistant that hops around your screen begging you to add MIDI tracks
> constantly.
>
> If, after 20 minutes, you have still not created a MIDI track, Ardour
> will overwrite every .waf file found in your home directory with a 4/4
> electronic kick drum loop, then shut down.
>
> -dr

Dude!

This is just what I have been wanting but am too much of a newb to have even 
thought of undertaking such a complex project on my own!

Hence my starting my soundwall project which I newbily thought was going to be 
a simple little app.

I have some code inspired by some "anon" silence that could perhaps be 
included in this project. wwnnsnmsnm.

cage-ily,

drew
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Michael Bechard]

Heh, yeah, I know. I was more commenting on how every DJ on the planet has 
treated that sample. :)

Michael





From: Harry Van Haaren 
To: Michael Bechard 
Cc: Arnold Krille ; linux-audio-dev@lists.linuxaudio.org
Sent: Thu, February 24, 2011 2:11:20 PM
Subject: Re: [LAD] [ANN] IR: LV2 Convolution Reverb




On Thu, Feb 24, 2011 at 6:49 PM, Michael Bechard  wrote:

The amen break has no rights attached to it. It was a gift from the gods. Now
>whether or not those gods love or hate us is another matter...
>

As far as I know the Winstons own the copyright (well... used to anyway, it 
might have expired) but they never chased anyone about lifting the drums...

For an informative youtube browse there's a nice video on the start of 
sampling, 
dnb, etc:
http://www.youtube.com/watch?v=5SaFTm2bcac

 Cheers, -Harry



  ___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Harry Van Haaren]

On Thu, Feb 24, 2011 at 6:49 PM, Michael Bechard wrote:

> The amen break has no rights attached to it. It was a gift from the gods.
> Now
> whether or not those gods love or hate us is another matter...
>

As far as I know the Winstons own the copyright (well... used to anyway, it
might have expired) but they never chased anyone about lifting the drums...

For an informative youtube browse there's a nice video on the start of
sampling, dnb, etc:
http://www.youtube.com/watch?v=5SaFTm2bcac

 Cheers, -Harry
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Michael Bechard]

The amen break has no rights attached to it. It was a gift from the gods. Now 
whether or not those gods love or hate us is another matter...

Michael



- Original Message 
From: Arnold Krille 
To: linux-audio-dev@lists.linuxaudio.org
Sent: Thu, February 24, 2011 12:35:39 PM
Subject: Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Thursday 24 February 2011 18:09:19 David Robillard wrote:
> To resolve this situation, we now have an exciting new Clippy inspired
> assistant that hops around your screen begging you to add MIDI tracks
> constantly.

Will you call it ardourino?

> If, after 20 minutes, you have still not created a MIDI track, Ardour
> will overwrite every .waf file found in your home directory with a 4/4
> electronic kick drum loop, then shut down.

You couldn't get the rights to use the amen-break for this?

Have (much!) fun,

Arnold



  
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Thu, Feb 24, 2011 at 1:35 PM, Arnold Krille 

> You couldn't get the rights to use the amen-break for this?

dude we don't use no breaks unless its "when the levee breaks", is
that clear? problem is, jimmy and the boys in zep wouldn't clear the
sample for us, so ...

we're using a break from barry manilow's "copacabana". its all good.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Arnold Krille]

On Thursday 24 February 2011 18:09:19 David Robillard wrote:
> To resolve this situation, we now have an exciting new Clippy inspired
> assistant that hops around your screen begging you to add MIDI tracks
> constantly.

Will you call it ardourino?

> If, after 20 minutes, you have still not created a MIDI track, Ardour
> will overwrite every .waf file found in your home directory with a 4/4
> electronic kick drum loop, then shut down.

You couldn't get the rights to use the amen-break for this?

Have (much!) fun,

Arnold


signature.asc
Description: This is a digitally signed message part.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Jörn Nettingsmeier]

On 02/24/2011 06:39 PM, Paul Davis wrote:

well, panners in a3 are now plugins, of a fashion (they are a bit
different from normal plugin APIs for a variety of reasons, primarily
the fact that they never do in-place processing). its quite likely
that at least the simplest of your ambi LADSPA plugins will show up in
that fashion in the not too distant future, with a GUI very similar to
the one in that screen shot.


nice :)


when i was in berlin attending "serious" concerts of electro-acoustic
music, there seemed to be quite a range of opinion about ambisonics
versus VBAP. although i tend to take your word for it on such matters,
there were quite several smart people with years of experience in
multi-speaker setups who had real issues with ambisonics and felt that
VBAP was generally preferable. i don't want to make people choose.


actually, i didn't like what i heard of vbap so far, but it does work as 
advertised, even under very adverse conditions. unless we have franz 
zotter's partial sphere magic firmly in place for all workflows, *and* 
there are kick-ass, fool-proof automatic ambisonic decoder generators 
for even the most pathological speaker layouts, vbap sure has its place.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Thu, Feb 24, 2011 at 11:46 AM, Fons Adriaensen  wrote:
> On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote:
>
>> what you don't know (because you're not on IRC) is the question of
>> N-point editing comes up a lot. i (and others) have argued (in my
>> opinion quite successfully) that four point editing is a relic of an
>> older workflow. others who have used 2, 3 and 4 point editing a lot on
>> other systems have argued back. nobody has been persuaded to change
>> their minds, and clearly nobody with the strong feelings in favor of
>> it has been motivated thus far to implement it.
>
> Then tell me how to do the following:

the position that i take with N-point editing is not that there is
some other way to do "the following". There isn't. its that the way of
approaching the task that leads to needing to do "the following" is
rooted in an older way of thinking about the overall workflow.

anyway, i've been through this debate at least 4 times in the last 2
years. i didn't persuade people who feel that its critical, and they
didn't persuade me. status quo.

> I don't have the time to hang out in chat room all day. Fortunately

i didn't say that. but i will say this. i could have had this
conversation with you on IRC in about 50% of the time it takes via
email.

IRC is one of the channels i meant. but what i meant much more was a
reference to those people who, either via IRC, email or the bug
tracker, get involved in an issue or feature and move it forward by
(a) creating the "loop" (b) staying in the "loop". there are many bugs
in ardour that i haven't fixed because i don't personally see them as
big issues and because nobody has convinced me otherwise. it doesn't
mean i'm right, but it does mean that if i (or someone else) is going
to switch focus to feature X or bug Y, even though i (or someone else)
isn't that motivated to do so, someone has to play advocate for the
role. and its not an advocate in a sea of silence. there are long
lists of bugs and long lists of cool features that  we *want* to work
on, at all times. for something to rise up above that particular ocean
of noise does, unfortunately, sometimes require a bit of advocacy that
goes beyond an email to a mailing list describing a problem.

> I'm generally not interested in VBAP. I provides the worst surround
> possible, even worse than most 5.1 panners. And in those rare cases where
> it would be a good solution, I can derive the required signals from a more
> universal encoding.

well, panners in a3 are now plugins, of a fashion (they are a bit
different from normal plugin APIs for a variety of reasons, primarily
the fact that they never do in-place processing). its quite likely
that at least the simplest of your ambi LADSPA plugins will show up in
that fashion in the not too distant future, with a GUI very similar to
the one in that screen shot.

when i was in berlin attending "serious" concerts of electro-acoustic
music, there seemed to be quite a range of opinion about ambisonics
versus VBAP. although i tend to take your word for it on such matters,
there were quite several smart people with years of experience in
multi-speaker setups who had real issues with ambisonics and felt that
VBAP was generally preferable. i don't want to make people choose.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Thu, 2011-02-24 at 13:08 +0100, Thorsten Wilms wrote:
> On 02/24/2011 12:43 PM, Fons Adriaensen wrote:
> 
> > It's also foolish to suggest that the 'all inclusive universal
> > DAW' will cater for those needs - just ignore what you don't
> > use etc. It most definitely does *not* because it's by no means
> > as universal as you may think, but rather the reflection of
> > one particular musical culture. Which means that whatever is
> > not used in that particular scene will not be provided. Ardour,
> > despite all it qualities and being a magnificent piece of work,
> > is a good example of that.
> 
> Now you talk about features not being provided, when the starting point 
> was features that are provided.
> 
> 
> > Also, 'ignoring the bits you don't need' is not always as simple
> > as it may seem. The simple fact that these things _are_ provided
> > has consequences on the overall design, they _do_ distract, they
> > _have_ to be checked and disabled (often each time again), they
> > _do_ take resources and they _do_ impact reliability. And they
> > are not compile time options.
> 
> Sure, a tool that offers exactly what you need and nothing more has 
> something reassuring to it. But how much do you get to see of Ardour's 
> MIDI support if you simply do not add any MIDI track to your session?

Oh, you havn't seen the latest improvements? The Ardour team noticed
that, since the track type selector is a combo box, literally not a
single pixel related to MIDI is shown during a purely audio related work
flow. This is, of course, a big problem in terms of our greater mission
to provide software that caters to the needs of precisely nobody while
irritating everybody else.

To resolve this situation, we now have an exciting new Clippy inspired
assistant that hops around your screen begging you to add MIDI tracks
constantly.

If, after 20 minutes, you have still not created a MIDI track, Ardour
will overwrite every .waf file found in your home directory with a 4/4
electronic kick drum loop, then shut down.

-dr

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Thu, 2011-02-24 at 11:47 +, Fons Adriaensen wrote:
> On Wed, Feb 23, 2011 at 05:11:33PM -0500, David Robillard wrote:
> 
> > Entirely Redland free. I hand-wrote a Turtle parser and serialiser.
> > 
> > In short, it's been a PITA for everyone in numerous ways since day one.
> 
> Congratulations. I mean it. This is probably the best move in the entire
> history of LV2.

Cheers :)

I am not a fan of wheel-reinventing; at the time using the existing
implementation seemed like the way to go, but... well, yeah. A burden
has been lifted for sure.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote:

> what you don't know (because you're not on IRC) is the question of
> N-point editing comes up a lot. i (and others) have argued (in my
> opinion quite successfully) that four point editing is a relic of an
> older workflow. others who have used 2, 3 and 4 point editing a lot on
> other systems have argued back. nobody has been persuaded to change
> their minds, and clearly nobody with the strong feelings in favor of
> it has been motivated thus far to implement it.

Then tell me how to do the following:

replace a range A-B by another one C-D, with user controllable
short xfades at the transitions, and so that everything to the
right of B (which may mean disjoint regions) moves as required
to make space for C-D. On all tracks, or some selected ones.
With the option to listen to each side of a transition separately,
and ajust it, without having to move away the other side.

> actually, i think i can speak clearly for carl and myself (the two
> most active current developers; possibly most of the others too) when
> i say that we are focussed on the feedback that we get from people who
> repeatedly engage with us using the communication channels that we
> find most convenient for this work. is that perfect? no. but its the
> way things work out, at least for the last several years. the price of
> entry into the exclusive club that is #ardour is simply time, nothing
> more (or less).

I don't have the time to hang out in chat room all day. Fortunately
I also have other things to do. You can of course choose to ignore
this list and others, and emails, but using these are a far better
use of my (or anybody's) time.

> if you can live with VBAP, this may interest you:

I'm generally not interested in VBAP. I provides the worst surround
possible, even worse than most 5.1 panners. And in those rare cases where
it would be a good solution, I can derive the required signals from a more
universal encoding. 

Ciao,

-- 
FA




___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Thu, Feb 24, 2011 at 11:28 AM, torbenh  wrote:
> On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote:
>> On Thu, Feb 24, 2011 at 10:23 AM, Fons Adriaensen  
>> wrote:
>> > On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis wrote:
>> > Well, I could pay or I could offer my time as a developer. During
>> > the last five years I have several times offered to integrate decent
>> > multichannel or AMB panning into Ardour, provided I could team up
>> > with someone taking care of the GUI aspects (I'm a nitwit regarding
>> > writing for GTK). Nothing has happened. I've arrived at the point
>> > where it quite clear that if I want certain functionality I'll be
>> > on my own to implement it.
>>
>> if you can live with VBAP, this may interest you:
>
> i doubt, that he can live with vbap.
> however, the ui should be pretty similar.
> so maybe he only needs to port amb dsp code.

i was planning to do that myself at some point soon, actually. i just
have to get clear in my head whether i think any warning needs to
exist somewhere that using it generates b-format.

i also just discovered that VBAP doesn't do constant power panning
between outputs, which means it probably needs to be thrown away.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[torbenh]

On Thu, Feb 24, 2011 at 11:17:17AM -0500, Paul Davis wrote:
> On Thu, Feb 24, 2011 at 10:23 AM, Fons Adriaensen  wrote:
> > On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis wrote:
> > Well, I could pay or I could offer my time as a developer. During
> > the last five years I have several times offered to integrate decent
> > multichannel or AMB panning into Ardour, provided I could team up
> > with someone taking care of the GUI aspects (I'm a nitwit regarding
> > writing for GTK). Nothing has happened. I've arrived at the point
> > where it quite clear that if I want certain functionality I'll be
> > on my own to implement it.
> 
> if you can live with VBAP, this may interest you:

i doubt, that he can live with vbap.
however, the ui should be pretty similar.
so maybe he only needs to port amb dsp code. 

> http://ardour.org/files/vbappanners.png

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Thu, Feb 24, 2011 at 10:23 AM, Fons Adriaensen  wrote:
> On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis wrote:
>
>> i don't agree with you that its about a type of music. it is about the
>> difference between some different ways of producing music, and not
>> just two of them. there are certainly approaches to making music that
>> are not well served by a DAW. but they are approaches to the
>> production of music, not kinds of music.
>
> Well, 'type' or even 'a particular type' can refer to a leaf node
> in the taxonomy or to a quite solid branch of it.
> The are classes of music that depend on sequencing etc. in order to
> be produced at all - that's why people involved in them want those
> features in the first place. I don't think it's wrong to call this
> 'a particular type of music', the type is defined by its dependence
> on those tools.

music is sound arranged in time (and optionally in space). i don't
know precisely what you mean by sequencing, but that means that any
production of music is going to involve arranging one or more of the
following things in time:

   * carrying out physical movements
   * playback of existing recordings of audio
   * instructions (for a human and/or a machine) to do one or both of the above

to the extent that computers don't carry out physical movement (much),
any use of computers in the production of music means that it is going
to involve the 2nd and 3rd options. both of them have been called
"sequencing". ardour2 only does the second action right now; ardour3
adds the third (instructions for a machine).

>> the notion that there is ever "one tool" for a task as
>> incredibly varied as producing music is absurd. nobody with half a
>> brain suggests that any DAW can be that tool.
>
> Then maybe the term 'DAW' is misnomer. I wouldn't call a tool
> that can't do simple four point editing an 'audio workstation'.

what you don't know (because you're not on IRC) is the question of
N-point editing comes up a lot. i (and others) have argued (in my
opinion quite successfully) that four point editing is a relic of an
older workflow. others who have used 2, 3 and 4 point editing a lot on
other systems have argued back. nobody has been persuaded to change
their minds, and clearly nobody with the strong feelings in favor of
it has been motivated thus far to implement it.

> choose to interpret my words), but just that they are focussed
> on a 'type', 'class', 'category' or whatever you may call it
> of music that doesn't require it.

actually, i think i can speak clearly for carl and myself (the two
most active current developers; possibly most of the others too) when
i say that we are focussed on the feedback that we get from people who
repeatedly engage with us using the communication channels that we
find most convenient for this work. is that perfect? no. but its the
way things work out, at least for the last several years. the price of
entry into the exclusive club that is #ardour is simply time, nothing
more (or less).

> Well, I could pay or I could offer my time as a developer. During
> the last five years I have several times offered to integrate decent
> multichannel or AMB panning into Ardour, provided I could team up
> with someone taking care of the GUI aspects (I'm a nitwit regarding
> writing for GTK). Nothing has happened. I've arrived at the point
> where it quite clear that if I want certain functionality I'll be
> on my own to implement it.

if you can live with VBAP, this may interest you:

http://ardour.org/files/vbappanners.png
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Thu, Feb 24, 2011 at 08:02:21AM -0500, Paul Davis wrote:

> i don't agree with you that its about a type of music. it is about the
> difference between some different ways of producing music, and not
> just two of them. there are certainly approaches to making music that
> are not well served by a DAW. but they are approaches to the
> production of music, not kinds of music.

Well, 'type' or even 'a particular type' can refer to a leaf node
in the taxonomy or to a quite solid branch of it. 
The are classes of music that depend on sequencing etc. in order to
be produced at all - that's why people involved in them want those
features in the first place. I don't think it's wrong to call this
'a particular type of music', the type is defined by its dependence
on those tools.

> i think you're wrong. its not that a DAW represents one particular
> musical culture, it just reflects some cultures of music production
> and not others.

Indeed, see above.

> the notion that there is ever "one tool" for a task as
> incredibly varied as producing music is absurd. nobody with half a
> brain suggests that any DAW can be that tool.

Then maybe the term 'DAW' is misnomer. I wouldn't call a tool 
that can't do simple four point editing an 'audio workstation'.
The sad fact here is that Ardour probably has 99% of the code
required to do it. The final 1% is missing because the concept
doesn't exist in the mindset of the developers. And by that I
don't want to suggest they are too stupid for it (as some may
choose to interpret my words), but just that they are focussed
on a 'type', 'class', 'category' or whatever you may call it
of music that doesn't require it.

> not to be mercenary about it, but the difference is that if your needs
> were that important and not being met by anything available to an
> intolerable degree, you could (or some organization could) choose to
> pay to have your needs met and not face any licensing/access issues in
> doing so..

Well, I could pay or I could offer my time as a developer. During
the last five years I have several times offered to integrate decent
multichannel or AMB panning into Ardour, provided I could team up
with someone taking care of the GUI aspects (I'm a nitwit regarding
writing for GTK). Nothing has happened. I've arrived at the point
where it quite clear that if I want certain functionality I'll be
on my own to implement it.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Thu, Feb 24, 2011 at 04:07:41PM +0300, Alexandre Prokoudine wrote:
> On Thu, Feb 24, 2011 at 2:43 PM, Fons Adriaensen wrote:
> 
> > There's no doubt that many users or potential users want the
> > 'all integrated' DAW combining audio, sequencing, invasive
> > effects, etc. required to produce a particular type of music
> > (and some other content, e.g. ads) that happens to have a
> > wide audience. And consequently a large number of people
> > wanting to be involved in making it.
> 
> That sounds like an intentionally badly hidden sarcasm.
 
Absolutely none intended. It's just a fact. 

> > OTOH, this does not mean that some other people (who may be
> > a minority) can't have other needs, nor does it provide good
> > reasons to imply that they are in some way retarded, out of
> > sync with their time, old-fashioned or whatever.
> 
> MIDI tracks in A3 are not forced to users at knife-point.

I never said they were.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Thu, Feb 24, 2011 at 8:07 AM, Alexandre Prokoudine
 wrote:

> http://createdigitalmusic.com/2011/02/the-79-virtual-analog-console-now-on-both-mac-and-linux-harrison-mixbus/
>
> "Coming from the rarified world of high-end audio systems, we
> recognized a lot of the same qualities in Ardour. Some examples:
>  “customization on a truly deep level is important for
> enterprise-class facilities” …. stuff like that."

Well, *they* would say that. They like Ardour. And they live in
Nashville. Say no more, eh? :)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On Thu, Feb 24, 2011 at 2:43 PM, Fons Adriaensen wrote:

> There's no doubt that many users or potential users want the
> 'all integrated' DAW combining audio, sequencing, invasive
> effects, etc. required to produce a particular type of music
> (and some other content, e.g. ads) that happens to have a
> wide audience. And consequently a large number of people
> wanting to be involved in making it.

That sounds like an intentionally badly hidden sarcasm.

> OTOH, this does not mean that some other people (who may be
> a minority) can't have other needs, nor does it provide good
> reasons to imply that they are in some way retarded, out of
> sync with their time, old-fashioned or whatever.

MIDI tracks in A3 are not forced to users at knife-point.

> Also, 'ignoring the bits you don't need' is not always as simple
> as it may seem. The simple fact that these things _are_ provided
> has consequences on the overall design, they _do_ distract, they
> _have_ to be checked and disabled (often each time again), they
> _do_ take resources and they _do_ impact reliability. And they
> are not compile time options.

The question I'm inclined to ask is whether you ever saw A3 live.
Because, really, until you choose to add a MIDI track, the related
functionality barely exposes itself.

> And the most perverse consequence of preferring complex apps
> to complex systems is that it becomes near impossible to modify
> them to individual or 'minority' needs.

http://createdigitalmusic.com/2011/02/the-79-virtual-analog-console-now-on-both-mac-and-linux-harrison-mixbus/

"Coming from the rarified world of high-end audio systems, we
recognized a lot of the same qualities in Ardour. Some examples:
 “customization on a truly deep level is important for
enterprise-class facilities” …. stuff like that."

You had it coming, Fons.

Alexandre Prokoudine
http://libregraphicsworld.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Thu, Feb 24, 2011 at 6:43 AM, Fons Adriaensen  wrote:
> On Wed, Feb 23, 2011 at 07:41:56PM -0500, Paul Davis wrote:
>
>> and to answer that question: what happened was huge great
>> boatloads of data that need to be shovelled around between all the
>> relevant components, complicated synchronization in both the backend
>> models and the user interfaces of all the relevant components, and a
>> general disdain for complex *systems* when one can settle for merely
>> complex programs.
>
> There's no doubt that many users or potential users want the
> 'all integrated' DAW combining audio, sequencing, invasive
> effects, etc. required to produce a particular type of music

i don't agree with you that its about a type of music. it is about the
difference between some different ways of producing music, and not
just two of them. there are certainly approaches to making music that
are not well served by a DAW. but they are approaches to the
production of music, not kinds of music.

> OTOH, this does not mean that some other people (who may be
> a minority) can't have other needs, nor does it provide good
> reasons to imply that they are in some way retarded, out of
> sync with their time, old-fashioned or whatever.

of course not. but the question still remains whether that particular
group of people would rather deal with a complex app that is tuned to
their needs or a complex system that can, optionally, be tuned to
their needs. the question doesn't change. there are people who are far
happier to deal with PD or Max than with a collection of plugins
inside a modular host - its the same kind of distinction.

> It's also foolish to suggest that the 'all inclusive universal
> DAW' will cater for those needs - just ignore what you don't
> use etc. It most definitely does *not* because it's by no means
> as universal as you may think, but rather the reflection of
> one particular musical culture.

i think you're wrong. its not that a DAW represents one particular
musical culture, it just reflects some cultures of music production
and not others. the notion that there is ever "one tool" for a task as
incredibly varied as producing music is absurd. nobody with half a
brain suggests that any DAW can be that tool.

> Also, 'ignoring the bits you don't need' is not always as simple
> as it may seem. The simple fact that these things _are_ provided
> has consequences on the overall design, they _do_ distract, they
> _have_ to be checked and disabled (often each time again), they
> _do_ take resources and they _do_ impact reliability. And they
> are not compile time options.

i think you over-estimate the impact of this, although i agree that
its not zero.

> And the most perverse consequence of preferring complex apps
> to complex systems is that it becomes near impossible to modify
> them to individual or 'minority' needs.

i return to my earlier points above. why would you imagine that
tinkering with "the all inclusive universal DAW" is ever going to
produce the right tool for each individual or minority need. the whole
concept is just misformed.

> learning all of it. I'm at the mercy of its developers, and
> they have good reasons to ignore my needs as they have done
> for years. So the only remaining advantage is that it is free

not to be mercenary about it, but the difference is that if your needs
were that important and not being met by anything available to an
intolerable degree, you could (or some organization could) choose to
pay to have your needs met and not face any licensing/access issues in
doing so.. the open source nature of ardour, like the open source
nature of emacs and firefox and linux, doesn't mean that its going to
cater to everyone's needs as-is. the difference with protools is that
you can't even consider this as an option. is that a big difference?
it depends on whether a tool like ardour stands any hope of being the
solution. for people who like to make music with renoise or with
ensembles of cassette players and violins played with pencil erasers,
it very well may not be.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Jörn Nettingsmeier]

On 02/24/2011 12:47 PM, Fons Adriaensen wrote:

On Wed, Feb 23, 2011 at 05:11:33PM -0500, David Robillard wrote:


Entirely Redland free. I hand-wrote a Turtle parser and serialiser.

In short, it's been a PITA for everyone in numerous ways since day one.


Congratulations. I mean it.


seconded. it used to be quite tricky to chase the correct versions of 
redland and its various dependencies, and i recall that at least one 
library down dependency hell road would require hefty manual massaging 
to even compile, at least on the distros i tried it on.


> This is probably the best move in the entire history of LV2.

now that's a bit nasty :)
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Jörn Nettingsmeier]

On 02/24/2011 12:43 PM, Fons Adriaensen wrote:


Spending some money on Protools is not really different to doing
the same for a kilometer of microphone cable or some XLR plugs.


imnsho, this simile only holds if you intend to hang yourself with the 
microphone cable.


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

>> And for a professional user that is irrelevant.
>> Spending some money on Protools is not really different to doing
>> the same for a kilometer of microphone cable or some XLR plugs.
>
> You pay license fees for cables and plugs and you would never alter them  
> in any way?

Again that difference is not really signficant. Paying a license is
an investment that has some return, or maybe hasn't, and that is the
only thing that matters in a professional context. And the cables and
plugs wear out as well and have to be replaced every now and then.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Thorsten Wilms]

On 02/24/2011 12:43 PM, Fons Adriaensen wrote:


It's also foolish to suggest that the 'all inclusive universal
DAW' will cater for those needs - just ignore what you don't
use etc. It most definitely does *not* because it's by no means
as universal as you may think, but rather the reflection of
one particular musical culture. Which means that whatever is
not used in that particular scene will not be provided. Ardour,
despite all it qualities and being a magnificent piece of work,
is a good example of that.


Now you talk about features not being provided, when the starting point 
was features that are provided.




Also, 'ignoring the bits you don't need' is not always as simple
as it may seem. The simple fact that these things _are_ provided
has consequences on the overall design, they _do_ distract, they
_have_ to be checked and disabled (often each time again), they
_do_ take resources and they _do_ impact reliability. And they
are not compile time options.


Sure, a tool that offers exactly what you need and nothing more has 
something reassuring to it. But how much do you get to see of Ardour's 
MIDI support if you simply do not add any MIDI track to your session?



> And for a professional user that is irrelevant.

Spending some money on Protools is not really different to doing
the same for a kilometer of microphone cable or some XLR plugs.


You pay license fees for cables and plugs and you would never alter them 
in any way?



--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Wed, Feb 23, 2011 at 05:11:33PM -0500, David Robillard wrote:

> Entirely Redland free. I hand-wrote a Turtle parser and serialiser.
> 
> In short, it's been a PITA for everyone in numerous ways since day one.

Congratulations. I mean it. This is probably the best move in the entire
history of LV2.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Wed, Feb 23, 2011 at 07:41:56PM -0500, Paul Davis wrote:

> and to answer that question: what happened was huge great
> boatloads of data that need to be shovelled around between all the
> relevant components, complicated synchronization in both the backend
> models and the user interfaces of all the relevant components, and a
> general disdain for complex *systems* when one can settle for merely
> complex programs.

There's no doubt that many users or potential users want the
'all integrated' DAW combining audio, sequencing, invasive
effects, etc. required to produce a particular type of music
(and some other content, e.g. ads) that happens to have a
wide audience. And consequently a large number of people
wanting to be involved in making it.

OTOH, this does not mean that some other people (who may be
a minority) can't have other needs, nor does it provide good 
reasons to imply that they are in some way retarded, out of
sync with their time, old-fashioned or whatever.

It's also foolish to suggest that the 'all inclusive universal
DAW' will cater for those needs - just ignore what you don't
use etc. It most definitely does *not* because it's by no means
as universal as you may think, but rather the reflection of
one particular musical culture. Which means that whatever is
not used in that particular scene will not be provided. Ardour,
despite all it qualities and being a magnificent piece of work,
is a good example of that.

Also, 'ignoring the bits you don't need' is not always as simple
as it may seem. The simple fact that these things _are_ provided
has consequences on the overall design, they _do_ distract, they
_have_ to be checked and disabled (often each time again), they
_do_ take resources and they _do_ impact reliability. And they
are not compile time options.

And the most perverse consequence of preferring complex apps
to complex systems is that it becomes near impossible to modify
them to individual or 'minority' needs. To all effects, Ardour
is to me as closed as Protools is, just because it has become
so complex rather than just big, and I can't spend a year on
learning all of it. I'm at the mercy of its developers, and
they have good reasons to ignore my needs as they have done
for years. So the only remaining advantage is that it is free
as in free beer. And for a professional user that is irrelevant.
Spending some money on Protools is not really different to doing
the same for a kilometer of microphone cable or some XLR plugs.

Ciao,

-- 
FA


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On 2/24/11, Gordon JC Pearce wrote:

> It's a DAW.  It shouldn't have *any* MIDI beyond control automation and
> some idea of sync.  Leave that to a sequencer.

I think I know your next argument: we don't need virtual instruments
as plug-ins, eh?  And while at that, let's dump lash/ladish crap
altogether. Session management is for n00bs, real musicians have sound
engineers to do it for them, so they can focus on actual music :)

(On reflection, it provides a new dimension to my recent little visual
joke about Dream Theater's approach to music:
http://prokoudine.info/files/dream-theater.png (says "What's the
rush?") Paul, how about visualization of little pixies doing JACK
transport or pitch-shifting in A3? I know Gordon would love it :))

> Of course, there are no *usable* PC-based sequencers, so after gathering
> dust for some ten years my 1/4" tape machine and Alesis MMT-8 are having
> all the fun, and the PC just sits with pidgin, evolution and an ssh
> session to my IRC client.

Gordon, there's no shame admitting you make a good use of hardware for
making music. We all did it, honestly. Some of us still do. Hardware
is joy to use.

> Linux audio is nowhere.  There isn't a usable sample editor, there are a

"Sample editor" as in "Swami" or "gigedit"? I wouldn't mind see them
merged, actually.

> It's 2011.  I've been at this for a decade.  It's just as bad as it was
> when I started trying to use PCs for music.  I give up.

Giving up is easy. Patching A3 to remove offensive MIDI tracks so that
the sight of the word "MIDI" in few parts of UI doesn't give the
willies is a real task for a real man. Be a man, Gordon, control your
software :)

Alexandre Prokoudine
http://libregraphicsworld.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Wed, Feb 23, 2011 at 7:39 PM, Paul Davis  wrote:
> On Wed, Feb 23, 2011 at 7:33 PM, Gordon JC Pearce  wrote:
>
>> What happened to the idea of doing one thing, and doing it well?

oh, and to answer that question: what happened was huge great
boatloads of data that need to be shovelled around between all the
relevant components, complicated synchronization in both the backend
models and the user interfaces of all the relevant components, and a
general disdain for complex *systems* when one can settle for merely
complex programs.

i mean, good god, why do i need to deal with freaking color channels
in the GIMP when all i want to do is a posterization, rotation,
surface mask and illumination effect?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Wed, Feb 23, 2011 at 7:33 PM, Gordon JC Pearce  wrote:

> What happened to the idea of doing one thing, and doing it well?  I'm
> not even totally sold on the idea of having the recorder and mixer in
> the same app...

you probably want ayyi then. except ... oh well.

> To that end, why has no-one managed to produce a PC (by which I mean the
> general case of modern personal computer, not x86/PCI cards/beige box
> PC) sequencer that doesn't suck overweight elephants through extremely
> fine mesh?  Cubase 3 on the Atari was simple, intuitive

... and couldn't do shit with audio sequencing. so shall we move on?

> cannot be beyond the wit of man to come up with something as good as
> 20-year-old software on hardware a million times as fast?

what is beyond the wit of man is to define the meaning of "as good" in
a context where every neighbour has different intents and purposes.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Gordon JC Pearce]

On Wed, 2011-02-23 at 19:11 -0500, Paul Davis wrote:
> On Wed, Feb 23, 2011 at 5:58 PM, Gordon JC Pearce  wrote:
> 
> > There is no way in hell I'm going near the utterly fundamentally
> > retarded mess of shit and fail that is Ardour 3.
> 
> gordon, we love you too. honest.

Oh, that reminds me, it's just about donation time again, isn't it?

> > It's a DAW.  It shouldn't have *any* MIDI beyond control automation and
> > some idea of sync.  Leave that to a sequencer.
> 
> its wierd how the overwhelming majority of folks out there in the
> world don't seem to feel that this distinction is relevant to their
> working style, and even more, whenever anybody does bring out a cool
> new sequencer (e.g. nodal, or some of the hex- or octagonal sequencers
> that have appeared recently) everyone starts wondering about how it
> can be integrated into .

What happened to the idea of doing one thing, and doing it well?  I'm
not even totally sold on the idea of having the recorder and mixer in
the same app...

To that end, why has no-one managed to produce a PC (by which I mean the
general case of modern personal computer, not x86/PCI cards/beige box
PC) sequencer that doesn't suck overweight elephants through extremely
fine mesh?  Cubase 3 on the Atari was simple, intuitive (well, apart
from the Interactive Phrase Synthesizer, I never met anyone that could
figure that out except for one guy from Orkney who lived in a house full
of cats and ate only yoghurt and green tea) and reliable.  Surely it
cannot be beyond the wit of man to come up with something as good as
20-year-old software on hardware a million times as fast?

Gordon MM0YEQ



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Wed, 2011-02-23 at 22:58 +, Gordon JC Pearce wrote:
> On Wed, 2011-02-23 at 19:55 +0300, Alexandre Prokoudine wrote:
> 
> > For how many years did we have to use Rosegarden/MusE and Ardour *and*
> > Hydrogen simultaneously just to get *basic* DAW functionality only
> > because everyone went on saying things like "Oh, this is UNIX
> > philosophy -- do one thing and do it well" or "Divide and conqer"? So,
> > we divided, and what have we conquered? :) After so many years we are
> > ending up with A3 approaching that has integrated MIDI and audio
> > anyway, a decade (too?) late.
> 
> ... and this is why I've stopped using computers for music, and why the
> nekosynth plugins haven't progressed in two years.
> 
> There is no way in hell I'm going near the utterly fundamentally
> retarded mess of shit and fail that is Ardour 3.
> 
> It's a DAW.  It shouldn't have *any* MIDI beyond control automation and
> some idea of sync.  Leave that to a sequencer.

LOL. Let me see if I have this straight: "I don't personally want a
'sequencer', therefore this program is a 'DAW', and therefore it
obviously should not be doing MIDI anything because I have conveniently
defined it as something that shouldn't". Solid argument.

Did you happen to notice how virtually every single popular PC DAW in
existence doesn't agree with your take on what they should do? How you
completely disregard overwhelming user demand (with no actual argument
behind it, no less)?

I'm not sure how you would attempt to justify this hilariously
curmudgeony opinion to a user who wants to work with audio and MIDI on a
timeline, but I'd sure like to hear it for entertainment's sake. Or is
working with audio and MIDI on a timeline somehow an inherently invalid
goal? Why, exactly? If I want to arrange some MIDI and audio on a
timeline (i.e. make music) I'm supposed to deal with the massively
clunky PITA of using separate programs to do so? What, exactly, is the
win there? What, exactly, is the user gaining?

If you're into "do one thing and do it well", there is actually a
logical argument in saying Ardour shouldn't have a mixer: particularly
with Jack, a process barrier between timeline and mixer/effects/etc
actually makes some sense. A process barrier between two timelines based
on the irrelevant detail of what kind of data you can stick in them does
not. The obscene amount of code duplication involved in that scenario is
pretty telling evidence that something is crap. What you are saying
simply does not make any sense whatsoever, and, coincidentally,
virtually everybody who has made music on a computer in the past several
decades disagrees with it. Hm. Everyone is wrong and you are right, eh?
Must be rough. Kids these days!

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Wed, Feb 23, 2011 at 5:58 PM, Gordon JC Pearce  wrote:

> There is no way in hell I'm going near the utterly fundamentally
> retarded mess of shit and fail that is Ardour 3.

gordon, we love you too. honest.

> It's a DAW.  It shouldn't have *any* MIDI beyond control automation and
> some idea of sync.  Leave that to a sequencer.

its wierd how the overwhelming majority of folks out there in the
world don't seem to feel that this distinction is relevant to their
working style, and even more, whenever anybody does bring out a cool
new sequencer (e.g. nodal, or some of the hex- or octagonal sequencers
that have appeared recently) everyone starts wondering about how it
can be integrated into .

> Linux audio is nowhere.  There isn't a usable sample editor, there are a
> couple of brave attempts at sequencers that lack pretty fundamental
> features, and we have one DAW that seems to be going down the "do
> everything, even if badly" route.

we haven't done OSC sequencing yet, so we still have plenty of room to
screw things up even more. oh, i forgot, *video*. yep, once we're done
with that, the stink will be so bad you'll have to wear a class 5
volatile vapor breathing apparatus to even sit down in front of your
computer. yeah, we are going to fuck with your mind you'll wish you
could just get back to DOS. which we'll run in a virtualbox instance
reparented inside an ardour window, just so that dave phillips can run
sequencer gold without any hassles. the future's so bright i've got to
wear a straightjacket! frizz me down with that kielbasse, officer!

> It's 2011.  I've been at this for a decade.  It's just as bad as it was
> when I started trying to use PCs for music.  I give up.

/me slaps on the peter gabriel and   .

really, gordon, its OK. its going to be OK.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Gordon JC Pearce]

On Wed, 2011-02-23 at 19:55 +0300, Alexandre Prokoudine wrote:

> For how many years did we have to use Rosegarden/MusE and Ardour *and*
> Hydrogen simultaneously just to get *basic* DAW functionality only
> because everyone went on saying things like "Oh, this is UNIX
> philosophy -- do one thing and do it well" or "Divide and conqer"? So,
> we divided, and what have we conquered? :) After so many years we are
> ending up with A3 approaching that has integrated MIDI and audio
> anyway, a decade (too?) late.

... and this is why I've stopped using computers for music, and why the
nekosynth plugins haven't progressed in two years.

There is no way in hell I'm going near the utterly fundamentally
retarded mess of shit and fail that is Ardour 3.

It's a DAW.  It shouldn't have *any* MIDI beyond control automation and
some idea of sync.  Leave that to a sequencer.

Of course, there are no *usable* PC-based sequencers, so after gathering
dust for some ten years my 1/4" tape machine and Alesis MMT-8 are having
all the fun, and the PC just sits with pidgin, evolution and an ssh
session to my IRC client.

Linux audio is nowhere.  There isn't a usable sample editor, there are a
couple of brave attempts at sequencers that lack pretty fundamental
features, and we have one DAW that seems to be going down the "do
everything, even if badly" route.

It's 2011.  I've been at this for a decade.  It's just as bad as it was
when I started trying to use PCs for music.  I give up.

Gordon MM0YEQ

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Wed, 2011-02-23 at 20:21 +, Chris Cannam wrote:
> On 9 February 2011 16:49, David Robillard  wrote:
> > new librdf-free slv2
> 
> Entirely Redland-free, or still using Raptor?

Entirely Redland free. I hand-wrote a Turtle parser and serialiser.

> And: why?

In short, it's been a PITA for everyone in numerous ways since day one.
Some abandoned SLV2 entirely because of it. Others were in the process
of doing so, until I decided enough was enough. Clearly SLV2 was
deficient somehow if people were abandoning it, and they were abandoning
it explicitly because of Redland...

Redland is great if you really need a fully featured RDF implementation,
and I still use it in such cases. To simply implement LV2, however, you
don't, and such a heavyweight dependency certainly doesn't induce the
best knee-jerk reaction. Often the librdf packages would pull in
ridiculously massive mysql libraries and such - to implement a simple
LADSPA based plugin API?! That this left a bad taste in people's mouths
is completely understandable. It has definitely hurt LV2 adoption.

(Because of historical reasons, "RDF" can seem bloatey, but it's really
just an elegant abstract data model, and we are using a terse and simple
syntax for it. The new lean-and-mean SLV2 implementation shows that
there is no bloat inherent in LV2, and it's all a much easier pill to
swallow in practice).

Some less hand-wavey practical reasons: there were mysterious and very
un-fun problems with librdf-in-librdf that crop up when you have plugins
that load plugins (e.g. Ingen, NASPRO(*)). Portability was also an
issue. Stefano D'Angelo (of NASPRO) and myself are now cooperating on
LV2 implementation rather than duplicating effort because of Redland
related problems (e.g. he'll be helping with win32 portability, and
Ingen now depends on NASPRO for LADSPA support). I am all about
resolving any fragmentation that has happened in the LV2 world, and
dropping Redland has been a big positive step in that regard.

The new implementation is thousands of times smaller, lighter, and
faster. The entire thing is much smaller than libxml2 alone, for
example. I should have just written one like this from the get-go, and
the initial reception of LV2 would have been a lot better. Oh well, live
and learn.

SLV2 is now based on two new libraries: Serd (RDF syntax) and Sord (RDF
store). Both are roughly 2 thousand lines of C, solid and thoroughly
tested (about 95% code coverage, like SLV2 itself). Serd has zero
dependencies, Sord depends only on Glib (for the time being, possibly
not in the future). There is still some optimization to be done, but
it's already so much leaner it's not a huge priority for me.

The new SLV2 should be appropriate for, say, implementing LV2 on
embedded hardware with limited resources. The old one, frankly, smelled
of bloat even on a desktop system.

Unfortunately, this ground-up reimplementation thing consumed the
majority of my January, but I am very happy with the outcome.

-dr

(* For the unfamiliar, NASPRO is a bridge which transparently exposes
LADSPA, VST, etc. plugins as LV2 plugins, among other things)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Chris Cannam]

On 9 February 2011 16:49, David Robillard  wrote:
> new librdf-free slv2

Entirely Redland-free, or still using Raptor?

And: why?


Chris
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Wed, 2011-02-23 at 11:03 +, Rui Nuno Capela wrote:
> On Wed, 23 Feb 2011 10:57:25 +0100, torbenh  wrote:
> > On Wed, Feb 23, 2011 at 09:03:03AM +, Rui Nuno Capela wrote:
> >> On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard 
> >> wrote:
> >> >On Wed, 2011-02-23 at 12:33 +0900, michael noble wrote:
> >> >>
> >> >>Speaking of existing work, I vaguely recall mention of a
> >> >>plugin with a Qt GUI? Where is this, I need one for
> >> >>testing...
> >> >>
> >> >>
> >> >>Take a look at latest svn of CLAM Network Editor. It is apparently
> >> >>able to export networks as LV2 with a Qt GUI. See
> >> >>http://clam-project.org/wiki/Development_screenshots
> >> >
> >> >Interesting. Judging by the fact that they're shown in Ardour,
> >> >they must
> >> >be doing the wrapping in the UI code. It would be nice if the next
> >> >CLAM
> >> >release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
> >> >switched to a library to do the embedding.
> >> >
> >>
> >> red herring alert! :)
> >>
> >> this features a qt-widget embedded *in* a gtk-widget via gtk-socket
> >> w/e--the lv2 ui plugin produced by the clam framework implicitly
> >> assumes the lv2_gtk_ui (pseudo)extension and for that matter it is a
> >> plain gtk-gnostic ui :)--the host must still get to libgtk et al. to
> >> handle the gtk widget/socket--i'm afraid this is not what Dave
> >> really asked for :/
> >
> > i think this IS what dave asked for :)
> > he can just move the gtk shell code, and move it into his library, 
> > and
> > it will be a qt plug :)
> >
> 
>  oh come on. do you mean Dave's library will have a so called 
>  specialized "gtk shell" for each toolkit out there? wrapping everything 
>  under gtk is not what i would call a "pretty good solution" at least the 
>  one we've agreed about earlier.
> 
>  Fons is right suggesting a common-denominator term: the lv2_ui 
>  descriptor should have carried a system window-id instead, in 
>  alternative to, a plain toolkit-dependent widget pointer that 
>  lv2_gtk_ui's been doing all this time as LV2UI_Widget*. on X11 based 
>  systems it would cast to a Window type; on windows it would be a HWND; 
>  i'm sure there's something native and equivalent on macosx/carbon/cocoa 
>  w/e... depending on the system the plugins are built/targeted then the 
>  host will/must "know" what to do with that window-id--embed, show, hide, 
>  realize, destroy, trap and send events, etc... look, it is this 
>  window-id in fact the corner stone for the gtk-socket to xembed a 
>  qt-widget on the clam example.
> 
>  imnsho, a GtkWidget* is not, cannot and never will be the way to 
>  "toolkit agnosticism" :) why is that not obvious to you?

You seem to have forgotten, or decided to ignore, every single solitary
point brought up in this conversation over the night ;)

You are wrong, but why that is so, and what the correct solution is, has
been described plenty enough already, so I won't waste time doing so
once again. If you're just interested in blissfully ignorant trolling
about Gtk gnosticism or whatever, I'll adjust my mental ignore list
accordingly.  If you're actually interested in making the solution
happen, then let's do it:

This is Qt LV2 UIs embedded in Ingen:

http://drobilla.net/files/qt_in_ingen.png

Ingen has absolutely no idea about anything Qt or X11 related
whatsoever, and the float plugin has absolutely no idea about anything
Gtk or X11 related whatsoever. They both just do exactly what their
developers want, without any of the PITA of dealing with foreign
toolkits and window systems and embedding and whatever else. In other
words, this solution is superior.

This, of course, means I wrote that library:

http://svn.drobilla.net/lad/trunk/suil/

I have not tested the Gtk-in-Qt direction yet. You're a Qt host author.
Hint, hint. I got stuck in qtractor autohell and gave up last night.

The relevant code in Ingen is here:

http://svn.drobilla.net/lad/trunk/ingen/src/client/PluginUI.cpp

The "make a UI set" thing is a bit tedious, but is needed to avoid SLV2
<=> Suil dependency. I am thinking that maybe I should make SLV2 depend
on this library(*) and provide a simpler interface there (basically just
suil_instance_new, which is the real meat). The next SLV2 release will
break API slightly anyway. Feedback from you or any other SLV2 users
welcome, I am inclined to break the SLV2 UI related API if it makes it
obvious and trivial for hosts to do the right thing.

-dr

(* The library itself depends on no toolkits, it uses dynamically loaded
modules for all the wrapping, but this depends on packagers doing it
right)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On 2/23/11, Fons Adriaensen wrote:

>> Do you close your eyes and
>> pretend not to hear anything when you keep seing new cloud computing
>> services popping up with a workiing business model behind them,
>> because they contradict your view of a perfect world to live in?
>
> When I seen somehting that contradicts my view of a perfect world,
> and that thing is likely to affect me or people or things I care
> about, then I do not close my eyes, and I have every right to
> critisize it.

Fair enough :) My point however was about strangely easy dismissal of
modern web technologies. I'd hate to see Linux behind the game *again*
just because some old fashioned people who control essential parts of
the ecosystem decided that things they don't personally like won't
happen. Don't get me wrong -- there's nothing bad about being
old-fashioned, I am one in many ways :) But there's time and place.

For how many years did we have to use Rosegarden/MusE and Ardour *and*
Hydrogen simultaneously just to get *basic* DAW functionality only
because everyone went on saying things like "Oh, this is UNIX
philosophy -- do one thing and do it well" or "Divide and conqer"? So,
we divided, and what have we conquered? :) After so many years we are
ending up with A3 approaching that has integrated MIDI and audio
anyway, a decade (too?) late.

Even our open approach to multitude of toolkits is biting us in the
arse (LV2 again), whereas we are supposed to be having it by the
throat.

What I'd really like to see is some perspective. I'm not talking about
visionaries, gods, no :) I'm talking about acknowledgement of where
the industry is heading to and how we can part of the future without
trading off our essential values (and rights).

Honestly, in 12 years that I've been following libre audio and
graphics project I've had enough of "me-too-ism". It's about time we
had some "you-don't-but-we-do-ism" for difference's sake :) There are
perfectly valid and safe ways to do it, and this is already taking
place, but in a rather scattered, disorganized way.

> If providers of 'cloud computing' would be serious about data
> and privacy protection they would use systems that allow the
> users to protect their data in a verifiable way.

Verifiable how exactly?

> This is not what I see happening: they do the inverse and force
> the user to make his data exploitable.

Exactly how they do it? Please use SoundCloud as example.

> Like everything essentially driven by greed, it would be sort
> of acceptable (on a voluntary basis) if either
>
> * the relation between the parties is regulated by law,
>   ensuring a fair deal for both and protection of basic
>   rights of the weakest one,

And it isn't taking place? Exactly why?

Alexandre Prokoudine
http://libregraphicsworld.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Wed, 2011-02-23 at 13:20 +0300, Alexandre Prokoudine wrote:
> On 2/22/11, David Robillard wrote:
> 
> > I have a working plugin (called "dirg") that provides a UI by hosting a
> > web server which you access in the browser. It provides a grid UI either
> > via a Novation Launchpad, or in the browser if you don't have a
> > Launchpad. Web UIs definitely have a ton of wins (think tablets, remote
> > control (i.e. network transparency), etc.)
> >
> > I also have a complete LV2 "message" system based on Atoms which is
> > compatible with / based on the event extension.  Atoms, and thus
> > messages, can be serialised to/from JSON (among other things,
> > particularly Turtle).
> 
> Any of them available to have a look at?

It's all in my lad svn repository at http://svn.drobilla.net/lad/trunk/

The Atom extension is http://lv2plug.in/ns/ext/atom/

The idea is to use the 'standard' types in the Atom extension (and other
ones as necessary for e.g. waveforms) to build higher level things,
rather than make a different struct for every little thing. Then host
just need to implement serialisation/persistence/network
transparency/etc (all the same thing, essentially) once, and it just
works for everything. "Messages" are essentially dictionaries
(http://lv2plug.in/ns/ext/atom#Blank)

> > Currently dirg provides the web server on its own with no host
> > involvement, but every plugin doing this obviously doesn't scale, so
> > some day we should figure this out... first we need an appropriately
> > high-level/powerful communication protocol within LV2 land (hence the
> > messages stuff).
> 
> Where do you stand with priorities now? That sounds like something
> very much worth investing time in.

This is the sort of thing I would like to be working on, right now. It
somewhat works, but Ingen is not yet a powerful enough programming
environment to actually do anything with the message sent to/from Dirg
(other than print them).

First I need to sort out this UI stuff, and get LV2r4 out. Then finalize
the atom extension (i.e. get it used by a few people, replacing the use
of instance-access in the new IR plugin with it would be a good start).
This will solve the long-standing "LV2 RPC" problem needed to take
things to the next level.

Then, the required tech will be more or less sorted out, and I'll get on
with making plugins to do what I need (i.e. make Ingen as powerful as
Max by implementing LV2 plugins as necessary).

My ultimate end-user visible goal for this is to make a multi-track
looper/sequencer in Ingen, with Dirg functioning as the UI.

> You see, one thing I'm puzzled about is that you have beginnings of
> what could be significant part of a potentially successful cloud
> computing audio app, and then you talk about how donations don't even
> pay your rent :)

Tell me about it, but to be fair, it's all still in experimental svn
land. I understand people aren't all that inclined to support things
that aren't releases they can depend on. Hence, making releases is my
primary mission.

Unfortunately, there's always digressions down into technology that I
just want to have, but aren't there yet (i.e. all this LV2 stuff;
somebody has to do it...). C'est la vie. It's coming along...

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Wed, 2011-02-23 at 09:03 +, Rui Nuno Capela wrote:
> On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard  
>  wrote:
> > On Wed, 2011-02-23 at 12:33 +0900, michael noble wrote:
> >>
> >> Speaking of existing work, I vaguely recall mention of a
> >> plugin with a Qt GUI? Where is this, I need one for 
> >> testing...
> >>
> >>
> >> Take a look at latest svn of CLAM Network Editor. It is apparently
> >> able to export networks as LV2 with a Qt GUI. See
> >> http://clam-project.org/wiki/Development_screenshots
> >
> > Interesting. Judging by the fact that they're shown in Ardour, they 
> > must
> > be doing the wrapping in the UI code. It would be nice if the next 
> > CLAM
> > release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
> > switched to a library to do the embedding.
> >
> 
>  red herring alert! :)
> 
>  this features a qt-widget embedded *in* a gtk-widget via gtk-socket 
>  w/e--the lv2 ui plugin produced by the clam framework implicitly assumes 
>  the lv2_gtk_ui (pseudo)extension and for that matter it is a plain 
>  gtk-gnostic ui :)--the host must still get to libgtk et al. to handle 
>  the gtk widget/socket--i'm afraid this is not what Dave really asked for 
>  :/

Right. It isn't, but it should be.

-dr

P.S. The "gnostic" thing is getting old ;)

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Wed, Feb 23, 2011 at 04:43:50PM +0300, Alexandre Prokoudine wrote:

> Do you close your eyes and
> pretend not to hear anything when you keep seing new cloud computing
> services popping up with a workiing business model behind them,
> because they contradict your view of a perfect world to live in?

When I seen somehting that contradicts my view of a perfect world,
and that thing is likely to affect me or people or things I care
about, then I do not close my eyes, and I have every right to
critisize it. Even if you don't like that or if it interferes
with your dreams. Or do you say 'these are not dreams, what I
mean to say is that resistance is futile and you will be
assimilated' ? In that case we don't have a conspiracy _theory_,
but a real one.

> Quite a number of modern hospitals have centralized data storage
> as well.

That usually was centralised even before the days of computers.

> Would you resist being transferred to
> such a hospital, because information will be centralized?

Not because it is centralised (I rather expect it to be). But
I would certainly object to it being given to a third party
which has nothing to do with running medical services, but
only with exploiting the data it is handling for commercial
gain. 

If providers of 'cloud computing' would be serious about data
and privacy protection they would use systems that allow the
users to protect their data in a verifiable way. This is not
what I see happening: they do the inverse and force the user
to make his data exploitable. Because *that* is the business
model. 

Like everything essentially driven by greed, it would be sort
of acceptable (on a voluntary basis) if either

* the relation between the parties is regulated by law, 
  ensuring a fair deal for both and protection of basic
  rights of the weakest one,

* or the parties have approximately equal power, ensuring
  'mutual damage' if any of them misbehaves towards the
  other.

None of the two conditions is satisfied, e.g. in the case
of Google, Facebook, and the likes.

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On 2/23/11, Alexandre Prokoudine wrote:

>> I'm thinking mostly about blind users when I talk about accessibility,
>> and I'm not sure how usable graphical browsers are for the blind.
>
> Again, it's up to web developers how much efforts they put into making
> their apps accessible.

Oh, and speaking of accessibility, both GTK+ and Qt are somewhat
broken: GTK+ on Windows doesn't support accelerators in non-Latin
locales, and Qt on (at least) Linux doesn't do it either. How about
fixing that first? :)

Alexandre Prokoudine
http://libregraphicsworld.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On 2/23/11, Philipp Überbacher wrote:

>> > Example number one is the CUPS web interface, accessible using the
>> > obvious address http://localhost:631. First of all it gives me the
>> > creeps every time I have to use it, because I have to use the browser to
>> > modify my system.
>>
>> So problem number one is that you have old-fashioned view on system
>> configuration.
>
> That might be, I don't see why a new way would be necessary or
> benefitial, especially if the new way is to configure a local
> system using a web UI.

But it doesn't have to be a local system :)

>> > Besides that the interface is slow and buggy, despite running on the
>> > same machine. I wouldn't call it a good interface in general.
>>
>> So problem number two is that because CUPS's UI is bad, you
>> extrapolate that on other web UIs. Very interesting.
>
> No, I talked about specific examples instead of talking out of my arse.

*sigh*

I don't believe you did, the reason being -- you vote against the
whole web thing by providing examples of one bad web UI. How does this
one web UI affect other web UIs? Does it infect them fith influenza?
Do they cough and suck loads of throat sweets? :)

Can you remeber what Bill Gates said about Internet back in early 90s?
Can you remember what happened next? Do you close your eyes and
pretend not to hear anything when you keep seing new cloud computing
services popping up with a workiing business model behind them,
because they contradict your view of a perfect world to live in?

>> > The other example is google docs/spreadsheet which I have to use
>> > sometimes. There are the obvious privacy concerns, it should be clear
>> > that giving your possibly sensitive data to what's probably the worlds
>> > biggest Ad company isn't a good idea.
>>
>> So problem number three is conspiracy theories.
>
> This has nothing to do with conspiracy theories at all, and google not
> the topic here.

No wait, you did say "google docs/spreadsheet" and then google is
suddenly not the topic? :)

Personally, I find the whole anticloud-computing thing highly exaggerated.

Google doesn't start new services, because they feel so charitable.
This is business. They justify cost of production, maintenance and
further development by having some business model behind every new
service. The same is valid for other companies. Storing your data in a
cloud is how it works.

Quite a number of modern hospitals have centralized data storage as
well. Doctors only need a tablet to access information from it when
they do their rounds in a shift. Would you resist being transferred to
such a hospital, because information will be centralized? Would you
request all the information to be erased when you leave (and all the
cookies wiped :))?

Privacy is a valid concern. Exxagerating it, however, rarely helps.
It's up to you if you want trading anything off. These days anyone can
do a personal cloud computng service for just him-/herself with as
much privacy as desired. And you don't even need cloud computing: the
whole SparkleShare thing that is essentially a Git wrapper was born
out of a will to control data instead of further relying on Dropbox.

>> So problem number four is that you have no idea whatsoever about
>> possibility to use hotkeys in a web app. Just FYI Gmail has lots of
>> shortcuts for both replying, forwarding and navigation between mails.
>> I use it all the time. Why you have no idea it is possible with AJAX
>> -- I really couldn't say. But you said something about
>> short-sightedness :-P
>
> I know that shortcuts are possible,

Then what is your point exactly? Because some web app developers don't
care about accessibility, let's dump the whole thing altogether?

> I tried it before writing my mail,
> but they are limited, and the limits may change from browser to browser,
> system to system, and you use many different systems all the time,
> otherwise you wouldn't need a web UI.

Wrong :) Web UI is about more things then just using different
systems. Collaboration is the first thing I can think of.

>> So the problem number five is being one of few hundred people around
>> the globe who still use text browsers in the world of Firefox, Chrome,
>> Opera, Safari and IE.
>>
>> Ever heard of http://www.w3.org/WAI/ btw?
>>
>> In other words, most of your points are made on the basis of you not
>> being up to day with modern technologies.
>
> I'm thinking mostly about blind users when I talk about accessibility,
> and I'm not sure how usable graphical browsers are for the blind.

Again, it's up to web developers how much efforts they put into making
their apps accessible.

> I'd rather like to see examples of good web UIs including an explanation
> of their benefits over conventional UIs instead of 'you'r so uncool'.

Well, I quite like Gmail + Google Talk. People laughed at me when I
said "how about mating mail and Jabber?". They stopped doing so a year
later when Google Talk was announced and made available. After that
the

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Folderol]

On Wed, 23 Feb 2011 10:39:49 +
Fons Adriaensen  wrote:

> Or elementary security awareness. If exposing the old and deprecated
> non-ssh based X11 interface is a bad idea (there's no discussion about
> that probably), then storing your data unprotected on a third party
> system certainly is. And then there are the legal issues. If you store
> some data obtained under NDA in a Google App, do you violate the NDA ?
> I'd say yes. What if a medical doctor stores his patient's files this
> way ? Most professional activities involve keeping confidential data
> of some sort. I would not hesitate to say that Google Apps is a no-go
> for that reason alone.
> 
> Ciao,

As far as I am concerned this point overrides any and all other considerations.

You have absolutely no control over where your data is going or who may be
looking at it.

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[torbenh]

On Wed, Feb 23, 2011 at 11:03:52AM +, Rui Nuno Capela wrote:
> On Wed, 23 Feb 2011 10:57:25 +0100, torbenh  wrote:
> >On Wed, Feb 23, 2011 at 09:03:03AM +, Rui Nuno Capela wrote:
> >>On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard 
> >>wrote:
> >>>On Wed, 2011-02-23 at 12:33 +0900, michael noble wrote:
> 
> Speaking of existing work, I vaguely recall mention of a
> plugin with a Qt GUI? Where is this, I need one for
> testing...
> 
> 
> Take a look at latest svn of CLAM Network Editor. It is apparently
> able to export networks as LV2 with a Qt GUI. See
> http://clam-project.org/wiki/Development_screenshots
> >>>
> >>>Interesting. Judging by the fact that they're shown in Ardour,
> >>>they must
> >>>be doing the wrapping in the UI code. It would be nice if the next
> >>>CLAM
> >>>release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
> >>>switched to a library to do the embedding.
> >>>
> >>
> >>red herring alert! :)
> >>
> >>this features a qt-widget embedded *in* a gtk-widget via gtk-socket
> >>w/e--the lv2 ui plugin produced by the clam framework implicitly
> >>assumes the lv2_gtk_ui (pseudo)extension and for that matter it is a
> >>plain gtk-gnostic ui :)--the host must still get to libgtk et al. to
> >>handle the gtk widget/socket--i'm afraid this is not what Dave
> >>really asked for :/
> >
> >i think this IS what dave asked for :)
> >he can just move the gtk shell code, and move it into his library,
> >and
> >it will be a qt plug :)
> >
> 
> oh come on. do you mean Dave's library will have a so called
> specialized "gtk shell" for each toolkit out there? wrapping
> everything under gtk is not what i would call a "pretty good
> solution" at least the one we've agreed about earlier.

well it will have a specialised qt shell for the other toolkits too.

> 
> Fons is right suggesting a common-denominator term: the lv2_ui
> descriptor should have carried a system window-id instead, in
> alternative to, a plain toolkit-dependent widget pointer that
> lv2_gtk_ui's been doing all this time as LV2UI_Widget*. on X11 based
> systems it would cast to a Window type; on windows it would be a
> HWND; i'm sure there's something native and equivalent on
> macosx/carbon/cocoa w/e... depending on the system the plugins are
> built/targeted then the host will/must "know" what to do with that
> window-id--embed, show, hide, realize, destroy, trap and send
> events, etc... look, it is this window-id in fact the corner stone
> for the gtk-socket to xembed a qt-widget on the clam example.
> 
> imnsho, a GtkWidget* is not, cannot and never will be the way to
> "toolkit agnosticism" :) why is that not obvious to you?

nobody said that.
the library would hand you a Qt widget.

this would be a QtWidget wrapping an external ui, the Qt Widget from a
qt gui, or a gtk widget wrapped in a Qt shell. 

you already have more experience with this wrapping stuff. so far i have
gathered that you have problems with wrapping gtkmm guis, or something ?

this needs solving on the gtk side.
lets please move this discussion to naming the problems, instead of
claiming that it doesnt work.

the goal of the library, is to make the host not need to deal with the
nastities of embedding stuff.
(there are a few broken windowmanagers out there which dont really
support xembed) 

the host will just open the library, and if the library supports the
hosts toolkit, it will hand it out a native widget.
or if thats not possible for some reasons, it will just make the plug
open a toplevel window.

most of the code to do this, is already there. its just scattered.
we just need to put it into a central library with some dlopen stuff, so
that _you_ dont need to link against gtk :)

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Rui Nuno Capela]

On Wed, 23 Feb 2011 10:57:25 +0100, torbenh  wrote:

On Wed, Feb 23, 2011 at 09:03:03AM +, Rui Nuno Capela wrote:

On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard 
wrote:
>On Wed, 2011-02-23 at 12:33 +0900, michael noble wrote:
>>
>>Speaking of existing work, I vaguely recall mention of a
>>plugin with a Qt GUI? Where is this, I need one for
>>testing...
>>
>>
>>Take a look at latest svn of CLAM Network Editor. It is apparently
>>able to export networks as LV2 with a Qt GUI. See
>>http://clam-project.org/wiki/Development_screenshots
>
>Interesting. Judging by the fact that they're shown in Ardour,
>they must
>be doing the wrapping in the UI code. It would be nice if the next
>CLAM
>release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
>switched to a library to do the embedding.
>

red herring alert! :)

this features a qt-widget embedded *in* a gtk-widget via gtk-socket
w/e--the lv2 ui plugin produced by the clam framework implicitly
assumes the lv2_gtk_ui (pseudo)extension and for that matter it is a
plain gtk-gnostic ui :)--the host must still get to libgtk et al. to
handle the gtk widget/socket--i'm afraid this is not what Dave
really asked for :/


i think this IS what dave asked for :)
he can just move the gtk shell code, and move it into his library, 
and

it will be a qt plug :)



oh come on. do you mean Dave's library will have a so called 
specialized "gtk shell" for each toolkit out there? wrapping everything 
under gtk is not what i would call a "pretty good solution" at least the 
one we've agreed about earlier.


Fons is right suggesting a common-denominator term: the lv2_ui 
descriptor should have carried a system window-id instead, in 
alternative to, a plain toolkit-dependent widget pointer that 
lv2_gtk_ui's been doing all this time as LV2UI_Widget*. on X11 based 
systems it would cast to a Window type; on windows it would be a HWND; 
i'm sure there's something native and equivalent on macosx/carbon/cocoa 
w/e... depending on the system the plugins are built/targeted then the 
host will/must "know" what to do with that window-id--embed, show, hide, 
realize, destroy, trap and send events, etc... look, it is this 
window-id in fact the corner stone for the gtk-socket to xembed a 
qt-widget on the clam example.


imnsho, a GtkWidget* is not, cannot and never will be the way to 
"toolkit agnosticism" :) why is that not obvious to you?


cya
--
rncbc aka Rui Nuno Capela
rn...@rncbc.org

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Philipp Überbacher]

Excerpts from Alexandre Prokoudine's message of 2011-02-23 10:52:44 +0100:
> On 2/23/11, Philipp Überbacher  wrote:
> 
> > Again I disagree, in my opinion web UIs have exactly one benefit and
> > many drawbacks. The benefit is that they can be accessed from anywhere
> > with an internet connection and sufficiently capable browser (which is
> > pretty much everywhere these days) without installing anything. The
> > drawbacks are too many to list really but I'll try to show some with an
> > example or two:
> >
> > Example number one is the CUPS web interface, accessible using the
> > obvious address http://localhost:631. First of all it gives me the
> > creeps every time I have to use it, because I have to use the browser to
> > modify my system.
> 
> So problem number one is that you have old-fashioned view on system
> configuration.

That might be, I don't see why a new way would be necessary or
benefitial, especially if the new way is to configure a local
system using a web UI.

> > Besides that the interface is slow and buggy, despite running on the
> > same machine. I wouldn't call it a good interface in general.
> 
> So problem number two is that because CUPS's UI is bad, you
> extrapolate that on other web UIs. Very interesting.

No, I talked about specific examples instead of talking out of my arse.

> > The other example is google docs/spreadsheet which I have to use
> > sometimes. There are the obvious privacy concerns, it should be clear
> > that giving your possibly sensitive data to what's probably the worlds
> > biggest Ad company isn't a good idea.
> 
> So problem number three is conspiracy theories.

This has nothing to do with conspiracy theories at all, and google not
the topic here.

> > the way of the user interface. You want keyboard shortcuts to make your
> > life easier? Forget it, chances are the browser will chew them, all you
> > get is the mouse.
> 
> So problem number four is that you have no idea whatsoever about
> possibility to use hotkeys in a web app. Just FYI Gmail has lots of
> shortcuts for both replying, forwarding and navigation between mails.
> I use it all the time. Why you have no idea it is possible with AJAX
> -- I really couldn't say. But you said something about
> short-sightedness :-P

I know that shortcuts are possible, I tried it before writing my mail,
but they are limited, and the limits may change from browser to browser,
system to system, and you use many different systems all the time,
otherwise you wouldn't need a web UI.

> > Accessibility? Forget it, text browser don't do JS.
> 
> So the problem number five is being one of few hundred people around
> the globe who still use text browsers in the world of Firefox, Chrome,
> Opera, Safari and IE.
> 
> Ever heard of http://www.w3.org/WAI/ btw?
> 
> In other words, most of your points are made on the basis of you not
> being up to day with modern technologies.

I'm thinking mostly about blind users when I talk about accessibility,
and I'm not sure how usable graphical browsers are for the blind.

Might be that I'm not up-to-date, but I don't see a reason to be.
Especially JS, which seems to be at the heart of the 'modern' web, is
for me associated with security, privacy and compatibility problems as
well as lack of user control while tangible benefits are hard to find.

> > Sorry, I could rant on forever.
> 
> Pray continue. I love reading stuff like that.
> 
> Alexandre Prokoudine
> http://libregraphicsworld.org

I'd rather like to see examples of good web UIs including an explanation
of their benefits over conventional UIs instead of 'you'r so uncool'.
Maybe you can show me at LAC?

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Fons Adriaensen]

On Wed, Feb 23, 2011 at 12:52:44PM +0300, Alexandre Prokoudine wrote:

> On 2/23/11, Philipp Überbacher  wrote:
> 
> > Example number one is the CUPS web interface, accessible using the
> > obvious address http://localhost:631. First of all it gives me the
> > creeps every time I have to use it, because I have to use the browser to
> > modify my system.
> 
> So problem number one is that you have old-fashioned view on system
> configuration.

A realistic one I'd say. Using a web interface implies you have 
already a working system, and by no means a minimal one. 

> > Besides that the interface is slow and buggy, despite running on the
> > same machine. I wouldn't call it a good interface in general.
> 
> So problem number two is that because CUPS's UI is bad, you
> extrapolate that on other web UIs. Very interesting.

Apart from some very trivial ones I've never seen one that
was any better. I've seen a lot of them that are a pain to use. 
 
> > The other example is google docs/spreadsheet which I have to use
> > sometimes. There are the obvious privacy concerns, it should be clear
> > that giving your possibly sensitive data to what's probably the worlds
> > biggest Ad company isn't a good idea.
> 
> So problem number three is conspiracy theories.

Or elementary security awareness. If exposing the old and deprecated
non-ssh based X11 interface is a bad idea (there's no discussion about
that probably), then storing your data unprotected on a third party
system certainly is. And then there are the legal issues. If you store
some data obtained under NDA in a Google App, do you violate the NDA ?
I'd say yes. What if a medical doctor stores his patient's files this
way ? Most professional activities involve keeping confidential data
of some sort. I would not hesitate to say that Google Apps is a no-go
for that reason alone.

Ciao,

-- 
FA

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On 2/22/11, David Robillard wrote:

> I have a working plugin (called "dirg") that provides a UI by hosting a
> web server which you access in the browser. It provides a grid UI either
> via a Novation Launchpad, or in the browser if you don't have a
> Launchpad. Web UIs definitely have a ton of wins (think tablets, remote
> control (i.e. network transparency), etc.)
>
> I also have a complete LV2 "message" system based on Atoms which is
> compatible with / based on the event extension.  Atoms, and thus
> messages, can be serialised to/from JSON (among other things,
> particularly Turtle).

Any of them available to have a look at?

> Currently dirg provides the web server on its own with no host
> involvement, but every plugin doing this obviously doesn't scale, so
> some day we should figure this out... first we need an appropriately
> high-level/powerful communication protocol within LV2 land (hence the
> messages stuff).

Where do you stand with priorities now? That sounds like something
very much worth investing time in.

You see, one thing I'm puzzled about is that you have beginnings of
what could be significant part of a potentially successful cloud
computing audio app, and then you talk about how donations don't even
pay your rent :)

Alexandre Prokoudine
http://libregraphicsworld.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[torbenh]

On Wed, Feb 23, 2011 at 09:03:03AM +, Rui Nuno Capela wrote:
> On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard 
> wrote:
> >On Wed, 2011-02-23 at 12:33 +0900, michael noble wrote:
> >>
> >>Speaking of existing work, I vaguely recall mention of a
> >>plugin with a Qt GUI? Where is this, I need one for
> >>testing...
> >>
> >>
> >>Take a look at latest svn of CLAM Network Editor. It is apparently
> >>able to export networks as LV2 with a Qt GUI. See
> >>http://clam-project.org/wiki/Development_screenshots
> >
> >Interesting. Judging by the fact that they're shown in Ardour,
> >they must
> >be doing the wrapping in the UI code. It would be nice if the next
> >CLAM
> >release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
> >switched to a library to do the embedding.
> >
> 
> red herring alert! :)
> 
> this features a qt-widget embedded *in* a gtk-widget via gtk-socket
> w/e--the lv2 ui plugin produced by the clam framework implicitly
> assumes the lv2_gtk_ui (pseudo)extension and for that matter it is a
> plain gtk-gnostic ui :)--the host must still get to libgtk et al. to
> handle the gtk widget/socket--i'm afraid this is not what Dave
> really asked for :/

i think this IS what dave asked for :)
he can just move the gtk shell code, and move it into his library, and
it will be a qt plug :) 

> 
> cheers
> -- 
> rncbc aka Rui Nuno Capela
> rn...@rncbc.org
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-dev

-- 
torben Hohn
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Alexandre Prokoudine]

On 2/23/11, Philipp Überbacher  wrote:

> Again I disagree, in my opinion web UIs have exactly one benefit and
> many drawbacks. The benefit is that they can be accessed from anywhere
> with an internet connection and sufficiently capable browser (which is
> pretty much everywhere these days) without installing anything. The
> drawbacks are too many to list really but I'll try to show some with an
> example or two:
>
> Example number one is the CUPS web interface, accessible using the
> obvious address http://localhost:631. First of all it gives me the
> creeps every time I have to use it, because I have to use the browser to
> modify my system.

So problem number one is that you have old-fashioned view on system
configuration.

> Besides that the interface is slow and buggy, despite running on the
> same machine. I wouldn't call it a good interface in general.

So problem number two is that because CUPS's UI is bad, you
extrapolate that on other web UIs. Very interesting.

> The other example is google docs/spreadsheet which I have to use
> sometimes. There are the obvious privacy concerns, it should be clear
> that giving your possibly sensitive data to what's probably the worlds
> biggest Ad company isn't a good idea.

So problem number three is conspiracy theories.

> the way of the user interface. You want keyboard shortcuts to make your
> life easier? Forget it, chances are the browser will chew them, all you
> get is the mouse.

So problem number four is that you have no idea whatsoever about
possibility to use hotkeys in a web app. Just FYI Gmail has lots of
shortcuts for both replying, forwarding and navigation between mails.
I use it all the time. Why you have no idea it is possible with AJAX
-- I really couldn't say. But you said something about
short-sightedness :-P

> Accessibility? Forget it, text browser don't do JS.

So the problem number five is being one of few hundred people around
the globe who still use text browsers in the world of Firefox, Chrome,
Opera, Safari and IE.

Ever heard of http://www.w3.org/WAI/ btw?

In other words, most of your points are made on the basis of you not
being up to day with modern technologies.

> Sorry, I could rant on forever.

Pray continue. I love reading stuff like that.

Alexandre Prokoudine
http://libregraphicsworld.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Rui Nuno Capela]

On Wed, 23 Feb 2011 02:58:56 -0500, David Robillard  
wrote:

On Wed, 2011-02-23 at 12:33 +0900, michael noble wrote:


Speaking of existing work, I vaguely recall mention of a
plugin with a Qt GUI? Where is this, I need one for 
testing...



Take a look at latest svn of CLAM Network Editor. It is apparently
able to export networks as LV2 with a Qt GUI. See
http://clam-project.org/wiki/Development_screenshots


Interesting. Judging by the fact that they're shown in Ardour, they 
must
be doing the wrapping in the UI code. It would be nice if the next 
CLAM

release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
switched to a library to do the embedding.



red herring alert! :)

this features a qt-widget embedded *in* a gtk-widget via gtk-socket 
w/e--the lv2 ui plugin produced by the clam framework implicitly assumes 
the lv2_gtk_ui (pseudo)extension and for that matter it is a plain 
gtk-gnostic ui :)--the host must still get to libgtk et al. to handle 
the gtk widget/socket--i'm afraid this is not what Dave really asked for 
:/


cheers
--
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Wed, 2011-02-23 at 12:33 +0900, michael noble wrote:
> 
> Speaking of existing work, I vaguely recall mention of a
> plugin with a
> Qt GUI? Where is this, I need one for testing...
> 
> 
> Take a look at latest svn of CLAM Network Editor. It is apparently
> able to export networks as LV2 with a Qt GUI. See
> http://clam-project.org/wiki/Development_screenshots

Interesting. Judging by the fact that they're shown in Ardour, they must
be doing the wrapping in the UI code. It would be nice if the next CLAM
release just exposed Qt UIs directly, and Gtk hosts (e.g. Ardour)
switched to a library to do the embedding.

-dr



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[michael noble]

> Speaking of existing work, I vaguely recall mention of a plugin with a
> Qt GUI? Where is this, I need one for testing...
>
>
Take a look at latest svn of CLAM Network Editor. It is apparently able to
export networks as LV2 with a Qt GUI. See
http://clam-project.org/wiki/Development_screenshots

-m
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Cornette]

On Tue, Feb 22, 2011 at 01:45:35PM +0100, Nick Copeland wrote:
> 
> > ATM it doesn't even provide network transparency. Which means you can't
> > even do the equivalent of ssh -X. 
> 
> Does anybody even use this feature anymore?
> 
Are you kidding?  All the time.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Giblock]

Yeah, I was thinking the something regarding gtk. Too late to change it
though. I suppose the next one will just be versioned.

And you are right. Nobody cares about 3 anymore, except for backwards
compatibility. There is no reason to pull that into the UI spec, though, as
there are no Qt3 lv2 plugins.

Paul
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Gabriel M. Beddingfield]

On Tuesday, February 22, 2011 07:20:35 pm David Robillard 
wrote:
> OK, thanks. Does anyone care about 3 any more?

No.

Qt3 reached EOL a couple years ago, and even the Qt3Support 
library in Qt4 is (unofficially) deprecated.

-gabriel
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Tue, 2011-02-22 at 17:22 -0500, Paul Giblock wrote:
> Dave,
> 
> I do some work in Qt. Primarily helping to port Lmms to Qt4.  I am now
> working on a successor. This host is in Qt4 and uses lv2 as the
> primary plugin api. I desire embedded plugins, so this topic is close
> to my heart.
> 
> Anyways, I would name the URI after Qt4 instead of simply Qt. Qt
> breaks some ABI compatibility in major releases. So, including the 4
> in the name should protect us when 5 is released.

OK, thanks. Does anyone care about 3 any more?

(On a related note, the Gtk one should also have had a version number in
there, but whatever, it's just a name)

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Philipp Überbacher]

Excerpts from David Robillard's message of 2011-02-22 21:28:03 +0100:
> On Tue, 2011-02-22 at 19:50 +0100, Stefano D'Angelo wrote:
> > 2011/2/22 David Robillard :
> > > On Tue, 2011-02-22 at 04:52 +, Jeremy Salwen wrote:
> > > [...]
> > >> Hi David,
> > >>
> > >>
> > >> As a plugin developer, I'm very much looking forward to this,
> > >> especially since I proposed something similar to this a bit ago
> > >> (http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/14098999.html
> > >>  :)   But the fact that you're capable and willing to implement this 
> > >> solution means a lot more than my confused half-baked ideas.  I look 
> > >> forward to the day when embedding and cross-toolkitedness walk hand in 
> > >> hand.
> > >
> > > Right, what you describe here is more or less what I am getting at (it's
> > > come up several times in the past), except rather than bundling it with
> > > every UI (which is copy-paste code reuse and all sorts of nuisance
> > > waiting to happen), I think it should just be a normal system library
> > > that hosts can use to do the job.
> > >
> > > We generally have the philosophy that if there is a choice, complexity
> > > does not belong in the plugin (or UI). Putting the complexity in the
> > > plugin is bad bad bad, plugins should be small and easy to write. In
> > > this case, a plugin UI should just implement and expose its widget -
> > > dealing with that widget is the host's problem.
> > >
> > > In this case, we have a tricky enough complexity that we don't want it
> > > duplicated in all the hosts either, so a library is definitely the way
> > > to go. I call it Suil :)
> > 
> > I didn't follow the whole discussion, but I just want to toss out one
> > not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
> > at YUI.
> 
> I don't think it's stupid at all. Saying using browser technology for UI
> is stupid these days is the height of short-sightedness. That's clearly
> where everything is headed.

I disagree, it is short-sightedness. It's hard to miss that this is the
current hype, but this doesn't mean it's a good idea.

> I have a working plugin (called "dirg") that provides a UI by hosting a
> web server which you access in the browser. It provides a grid UI either
> via a Novation Launchpad, or in the browser if you don't have a
> Launchpad. Web UIs definitely have a ton of wins (think tablets, remote
> control (i.e. network transparency), etc.)

Again I disagree, in my opinion web UIs have exactly one benefit and
many drawbacks. The benefit is that they can be accessed from anywhere
with an internet connection and sufficiently capable browser (which is
pretty much everywhere these days) without installing anything. The
drawbacks are too many to list really but I'll try to show some with an
example or two:

Example number one is the CUPS web interface, accessible using the
obvious address http://localhost:631. First of all it gives me the
creeps every time I have to use it, because I have to use the browser to
modify my system. I even have to type in my root password. Yes, typing
the root password into some browser popup
(http://www.cups.org/articles.php?L274). I know that the web is a big
and scary place and that the browser is the way to access it, and that
it's a big pile of crap full of bugs and security vulnerabilities. The
barrier between the big scary web and root seems to be very very low.
Besides that the interface is slow and buggy, despite running on the
same machine. I wouldn't call it a good interface in general.

The other example is google docs/spreadsheet which I have to use
sometimes. There are the obvious privacy concerns, it should be clear
that giving your possibly sensitive data to what's probably the worlds
biggest Ad company isn't a good idea. They basically own the web these
days, they want you to do everything on the web, they know how to create
web UIs, and that's why this example is so good. It shows that the
browser, besides being a huge security and privacy problem, also gets in
the way of the user interface. You want keyboard shortcuts to make your
life easier? Forget it, chances are the browser will chew them, all you
get is the mouse. Right-click somewhere and you most likely get
completely nonsensical options, your browsers default, made for web
pages. Scrolling a few rows shouldn't be a problem, but try it and see
it stutter along. Trying to squish a program into a program that was
made for viewing web pages simply is a bad idea, the user experience
won't ever be great.
Accessibility? Forget it, text browser don't do JS. Sorry, I could rant
on forever. Web UIs have their uses but I simply don't thing they're a
good idea in general.

Google do it because their business model is deeply rooted in the web,
others do it because it's the current hype.

--snip--

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Giblock]

Dave,

I do some work in Qt. Primarily helping to port Lmms to Qt4.  I am now
working on a successor. This host is in Qt4 and uses lv2 as the primary
plugin api. I desire embedded plugins, so this topic is close to my heart.

Anyways, I would name the URI after Qt4 instead of simply Qt. Qt breaks some
ABI compatibility in major releases. So, including the 4 in the name should
protect us when 5 is released.

Regards
Paul
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Jörn Nettingsmeier]

On 02/22/2011 01:45 PM, Nick Copeland wrote:

 > ATM it doesn't even provide network transparency. Which means you can't
 > even do the equivalent of ssh -X.

Does anybody even use this feature anymore?



fwiw, 50% of my audio work happens on a laptop that i use to ssh into my 
audio workstation. (i find a laptop with wlan to be the tranzport as god 
intended it to be :-D).


about 80% of the unix systems administration i have done in the past 
happened over ssh, and i always had xforwarding enabled to be able to 
quickly start xosview or other metering tools.


x bashing is all very cool, but it's what we have and it works.

i wonder:  you are obviously willing to design for future graphical 
abstraction layers which are not yet available. good, but possibly a lot 
of extra (guess-)work. will it be that much worse to just design for x11 
today, and invest some extra work to port to future graphics layers in a 
few years? well-designed software should be easy to port to new 
graphical paradigms, and being lazy today prevents over-engineering.
heck, if your software kicks ass, chances are other people will do the 
porting ;)


fons is obviously being grumpy, but i can't help noticing that we've had 
an awful lot of "innovation" in linux lately that may or may not prove 
useful in the long term, but it definitely did invalidate a lot of 
sysadmin expertise. nobody seems to be factoring that into the equation.
and it's definitely true that most of the innovative replacements to 
traditional unix mechanisms we have seen are focusing on single-user 
desktop or mobile computing. if your usecase differs, you get many 
headaches without much tangible benefit.


so hooray for getting rid of decades of x11 cruft, but let's not throw 
out the baby with the bathwater (even though it's biodegradable).

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Philipp Überbacher]

Excerpts from Paul Davis's message of 2011-02-22 17:57:44 +0100:
> On Tue, Feb 22, 2011 at 11:48 AM, Philipp Überbacher
>  wrote:
> > I'm not sure it helps to talk about wayland, it seems to be very much
> > future music. It seems ubuntu and fedora talk about a year or so, but
> > after reading up about its current state (three years of development so
> > far, pretty much proof of concept, working with some drivers only,
> > crashing all over the place in the video demos) it seems to me that five
> > years is a more realistic estimate (rather longer if we talk about
> > replacing X). Just my guess, but it seems far from being in a reliably
> > working state, so it's future music.
> > Also, I don't see what's supposed to be so great about it, besides
> > removing X11 cruft.
> 
> it does a lot more than "remove xcruft". it moves *nix display
> technology into a modern era in which everything is just a drawing
> surface that gets composited and along the way can be subject to
> arbitrary transformation. rather than insist on the type of h/w
> abstraction that X uses, which is fundamentally based on display
> technology from 20 years ago, it uses an abstraction that is largely
> h/w independent even if it relies on h/w to get the best performance
> from the rendering model. you are not drawing to "windows", and you
> don't have a "rectangle on the screen" under your control: you render
> to a surface which will be composited into the frame buffer (possibly
> with vblank sync, a concept that X really cannot export because of
> network transparency).
> 
> another way to look at it is to take any sensible drawing API: Cairo,
> PostScript, CoreDraw ... extract the core concepts behind the way they
> relate drawing to a result ... now make that into the display server.
> like JACK, don't provide very much access to the h/w concepts at all,
> but instead provide a powerful, abstract model that is actually *more*
> capable and flexible than working at the level of "what the hardware
> does".
> 
> of course, you have to add event handling too, but wayland's approach
> to this is also much more in line with contemporary technology than
> X's fundamental models of input devices and so forth.
> 
> i agree that its a way from becoming the standard thing, but i'm
> convinced that something like wayland is what we will all be on in a
> few years.
> 
> --p

The 'remove X cruft' is the most tangible aspect for me (if it means
actually reducing complexity).

The rest sounds nice, and it might well be that X has become old, but I
don't see the big improvement coming up. Windows are called surfaces
now, can have different shapes and are more flexible, compositing,
transformations, I got that bit, but I don't see the UI improvement.
I've seen the demos with shapes flying around the desktop, I've seen
the conventional compositing window managers and wayland will probably
do all that and more, but I don't see the improvement in User
Interfaces. I see fancy effects that are good for a couple of 'wow,
looks cool' moments, but I can't see an improvement in usability coming
up. Maybe I'm just not enough of a visionary to see the great things
that will be possible but I'd sure like to see examples of User
Interfaces that will really benefit from it. I want to see things that
weren't possible before, real improvements for the user, not just
eye candy.

Again, I do hope that it will reduce complexity, code complexity,
difficulties with UI coding, etc. rather than increasing them. If it
will achieve that then it will be an improvement. Sadly though things
tend to become more complex. We'll see how it'll pan out, wayland in ~5
years or X for another decade. I haven't made many predictions yet, I
still dare to make them :).

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Tue, 2011-02-22 at 13:55 -0500, Paul Davis wrote:
> On Tue, Feb 22, 2011 at 1:50 PM, Stefano D'Angelo  
> wrote:
> 
> > I didn't follow the whole discussion, but I just want to toss out one
> > not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
> > at YUI.
> 
> I wrote an XML schema for plugin GUIs, oh, about 8 years ago.
> 
> Plugin developers who write their own GUIs aren't interested in
> learning another not-in-my-toolkit method of trying to get the thing
> to look right. Either they don't care, and they leave it to the host,
> or they do care, and these meta-toolkit methods are inadequate to meet
> their goals.

HTML/etc. is a very different thing from some random XML format for a
particular purpose. It is the most widely known, deployed, and portable
UI technology by a very, very, very wide margin, and this is only going
to get more true over time. Nobody ever got fired for buying HTML, so to
speak.

(Within LV2, as far as host generated UIs go, it makes more sense to
define that data in Turtle, but that's a different approach entirely
than making a "UI" in the toolkit sense).

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Tue, 2011-02-22 at 19:50 +0100, Stefano D'Angelo wrote:
> 2011/2/22 David Robillard :
> > On Tue, 2011-02-22 at 04:52 +, Jeremy Salwen wrote:
> > [...]
> >> Hi David,
> >>
> >>
> >> As a plugin developer, I'm very much looking forward to this,
> >> especially since I proposed something similar to this a bit ago
> >> (http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/14098999.html
> >>  :)   But the fact that you're capable and willing to implement this 
> >> solution means a lot more than my confused half-baked ideas.  I look 
> >> forward to the day when embedding and cross-toolkitedness walk hand in 
> >> hand.
> >
> > Right, what you describe here is more or less what I am getting at (it's
> > come up several times in the past), except rather than bundling it with
> > every UI (which is copy-paste code reuse and all sorts of nuisance
> > waiting to happen), I think it should just be a normal system library
> > that hosts can use to do the job.
> >
> > We generally have the philosophy that if there is a choice, complexity
> > does not belong in the plugin (or UI). Putting the complexity in the
> > plugin is bad bad bad, plugins should be small and easy to write. In
> > this case, a plugin UI should just implement and expose its widget -
> > dealing with that widget is the host's problem.
> >
> > In this case, we have a tricky enough complexity that we don't want it
> > duplicated in all the hosts either, so a library is definitely the way
> > to go. I call it Suil :)
> 
> I didn't follow the whole discussion, but I just want to toss out one
> not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
> at YUI.

I don't think it's stupid at all. Saying using browser technology for UI
is stupid these days is the height of short-sightedness. That's clearly
where everything is headed.

I have a working plugin (called "dirg") that provides a UI by hosting a
web server which you access in the browser. It provides a grid UI either
via a Novation Launchpad, or in the browser if you don't have a
Launchpad. Web UIs definitely have a ton of wins (think tablets, remote
control (i.e. network transparency), etc.)

I also have a complete LV2 "message" system based on Atoms which is
compatible with / based on the event extension.  Atoms, and thus
messages, can be serialised to/from JSON (among other things,
particularly Turtle). This IMO definitely The Way Forward for more
advanced communication between UI and plugin: float control ports really
don't cut it, and instance-access is evil. This kind of thing is why I
have always strongly advocated the 'host handled' communication between
plugin and UI. Instance-access was designed to kludge VST UIs into LV2,
but really should not be used in new code. This is the other high
priority "alarming LV2 situation" right now.

Currently dirg provides the web server on its own with no host
involvement, but every plugin doing this obviously doesn't scale, so
some day we should figure this out... first we need an appropriately
high-level/powerful communication protocol within LV2 land (hence the
messages stuff).

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Tue, 2011-02-22 at 18:32 +, Rui Nuno Capela wrote:
> On 02/22/2011 05:38 PM, David Robillard wrote:
> > 
> > Speaking of existing work, I vaguely recall mention of a plugin with a
> > Qt GUI? Where is this, I need one for testing...
> > 
> 
> afaict, there's none
> 
> i recall there are only two lv2 ui (sub)extensions in use, to my
> knowledge of course, and you probably know better:
> 1) lv2_gtk_ui (http://lv2plug.in/ns/extensions/ui#GtkUI)
> 2) lv2_external_ui (http://lv2plug.in/ns/extensions/ui#external)
> nb. qtractor, honors 2) if a plugin exposes both, although i suspect
> there's none in the wild. if there were a qt or, most generally a
> *non-gtk* based lv2 plugin, it would be actually using 2)--no surprise
> there as 2) is currently the only existing "de facto toolkit agnostic"
> form ;)

OK. If an existing one is not currently in use, I will add a URI for Qt
widget to the UI extension (which needs a new revision anyway for other
reasons).

I am not familiar with Qt. What should the definition be? IIRC Qt4 broke
a bunch of stuff, do we need different types for different versions of
Qt?

Thanks,

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Tue, Feb 22, 2011 at 1:50 PM, Stefano D'Angelo  wrote:

> I didn't follow the whole discussion, but I just want to toss out one
> not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
> at YUI.

I wrote an XML schema for plugin GUIs, oh, about 8 years ago.

Plugin developers who write their own GUIs aren't interested in
learning another not-in-my-toolkit method of trying to get the thing
to look right. Either they don't care, and they leave it to the host,
or they do care, and these meta-toolkit methods are inadequate to meet
their goals.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Gabriel M. Beddingfield]

On Tue, 22 Feb 2011, Philipp Überbacher wrote:


I'm not sure it helps to talk about wayland, it seems to be very much
future music. It seems ubuntu and fedora talk about a year or so, but
after reading up about its current state (three years of development so


No, it's very much going to happen.  Several distros 
(including Ubuntu[1]) have made firm decisions that they 
will be moving to Wayland... at least for the mobile 
versions of their distro.


-gabriel

[1] http://www.markshuttleworth.com/archives/551___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/22 David Robillard :
> On Tue, 2011-02-22 at 04:52 +, Jeremy Salwen wrote:
> [...]
>> Hi David,
>>
>>
>> As a plugin developer, I'm very much looking forward to this,
>> especially since I proposed something similar to this a bit ago
>> (http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/14098999.html
>>  :)   But the fact that you're capable and willing to implement this 
>> solution means a lot more than my confused half-baked ideas.  I look forward 
>> to the day when embedding and cross-toolkitedness walk hand in hand.
>
> Right, what you describe here is more or less what I am getting at (it's
> come up several times in the past), except rather than bundling it with
> every UI (which is copy-paste code reuse and all sorts of nuisance
> waiting to happen), I think it should just be a normal system library
> that hosts can use to do the job.
>
> We generally have the philosophy that if there is a choice, complexity
> does not belong in the plugin (or UI). Putting the complexity in the
> plugin is bad bad bad, plugins should be small and easy to write. In
> this case, a plugin UI should just implement and expose its widget -
> dealing with that widget is the host's problem.
>
> In this case, we have a tricky enough complexity that we don't want it
> duplicated in all the hosts either, so a library is definitely the way
> to go. I call it Suil :)

I didn't follow the whole discussion, but I just want to toss out one
not-so-stupid-as-it-may-seem possibility: HTML + CSS + JS. Take a look
at YUI.

Stefano
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Rui Nuno Capela]

On 02/22/2011 05:38 PM, David Robillard wrote:
> 
> Speaking of existing work, I vaguely recall mention of a plugin with a
> Qt GUI? Where is this, I need one for testing...
> 

afaict, there's none

i recall there are only two lv2 ui (sub)extensions in use, to my
knowledge of course, and you probably know better:
1) lv2_gtk_ui (http://lv2plug.in/ns/extensions/ui#GtkUI)
2) lv2_external_ui (http://lv2plug.in/ns/extensions/ui#external)
nb. qtractor, honors 2) if a plugin exposes both, although i suspect
there's none in the wild. if there were a qt or, most generally a
*non-gtk* based lv2 plugin, it would be actually using 2)--no surprise
there as 2) is currently the only existing "de facto toolkit agnostic"
form ;)

cheers
-- 
rncbc aka Rui Nuno Capela
rn...@rncbc.org
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Tue, 2011-02-22 at 04:52 +, Jeremy Salwen wrote:
[...]
> Hi David,
> 
> 
> As a plugin developer, I'm very much looking forward to this,
> especially since I proposed something similar to this a bit ago
> (http://www.opensubscriber.com/message/linux-audio-dev@lists.linuxaudio.org/14098999.html
>  :)   But the fact that you're capable and willing to implement this solution 
> means a lot more than my confused half-baked ideas.  I look forward to the 
> day when embedding and cross-toolkitedness walk hand in hand.

Right, what you describe here is more or less what I am getting at (it's
come up several times in the past), except rather than bundling it with
every UI (which is copy-paste code reuse and all sorts of nuisance
waiting to happen), I think it should just be a normal system library
that hosts can use to do the job.

We generally have the philosophy that if there is a choice, complexity
does not belong in the plugin (or UI). Putting the complexity in the
plugin is bad bad bad, plugins should be small and easy to write. In
this case, a plugin UI should just implement and expose its widget -
dealing with that widget is the host's problem.

In this case, we have a tricky enough complexity that we don't want it
duplicated in all the hosts either, so a library is definitely the way
to go. I call it Suil :)

Cheers,

-dr



___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Tue, 2011-02-22 at 12:43 +, Fons Adriaensen wrote:
> On Mon, Feb 21, 2011 at 09:26:09PM -0500, David Robillard wrote:
>  
> > It is obviously not useful to have hundreds of plugin UI windows open at
> > once anyway.
> 
> Unless they are embedded instead of being separate top level windows.
>  
> > If you're on an X11 system, then you can use X11 as a base to support
> > several toolkits in exactly the way you described (if those toolkits use
> > X11, of course). The experiment you described is an implementation
> > strategy, and possibly one we should use in the aforementioned library
> > to avoid the out-of-process overhead. The source code would be useful.
> 
> 
> > However, there is no need or even benefit to forcing UI and/or host
> > authors to deal with X11 directly. That is simply a poor API design, and
> > a nuisance for everyone.
> 
> I think you misunderstood things a bit. Neither the host nor the plugin
> has to deal with X11 directly, each of them uses whatever toolkit they
> like. The essential point is that what is exchanged (once) between
> them is something that is common to both - an X window ID in the case
> of X11 systems or the equivalent if the basic system is not X. The
> plugin uses this as the  parent for its own window. Which means that
> the plugin window's position, visibility, etc. are now under control
> of the host. 
> 
> The code needed to do this can be part of a plugin support library on
> both sides. 

Bingo. You said yourself, "or the equivalent if the basic system is not
X". In other words, the UI API should not be X11 based. In other other
words, the UI API needs to be toolkit agnostic, which it is. Yay.

I fully agree with everything you have said here, otherwise.

-dr


___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Tue, 2011-02-22 at 09:43 +, Rui Nuno Capela wrote:
> On Mon, 21 Feb 2011 21:55:04 -0500, David Robillard  
[...]
>  You seem to want to argue "against" me, but there's no 
> > mention
> > of my proposed solution at all here... unless new information comes 
> > up,
> > I'll take that as a sign that this is indeed the way to go, and get 
> > on
> > with doing it.
> >
> 
>  well, i never said your proposed solution isn't any good, did i?
> 
>  in fact, i apologise for the noise and wish to sincerely nod and 
>  commend it, by all means.
> 
>  please do not take my stance on defending the lv2_external_ui as a 
>  counter-argument to your proposal. quite the contrary ;)
> 
>  carry on

Heh, fair enough. I get frustrated when things stray from the useful
thread of conversation, what can I say :)

I should say that, though the API design and long-term implications of
the external UI extension are a problem I have been harping on, you're
of course right in that it works. Those who implemented the external UI
stuff have already done the actual implementation of making external UIs
work, it's just in the wrong place(s). My task is basically to play the
architect and put that useful working code in the place where it belongs
to make the architectural problems go away. I'm certainly not saying the
work is entirely crap and wasted time, it just needs a bit of moulding.
Since I enjoy the architect thing quite a bit more than the nitty gritty
make-it-work thing, I'm quite grateful for what's been done, because I
don't want to do it :)

Speaking of existing work, I vaguely recall mention of a plugin with a
Qt GUI? Where is this, I need one for testing...

Cheers,

-dr

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Sean Bolton]

On Feb 22, 2011, at 4:45 AM, Nick Copeland wrote:

> ATM it doesn't even provide network transparency. Which means you  
can't

> even do the equivalent of ssh -X.

Does anybody even use this feature anymore?


Of course.  I very rarely even turn on the monitor of my linux box.  
Usually
I'm using it via an 'ssh -X' session on my laptop, from the other  
side of the

room, if not elsewhere in the house.

-Sean

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Paul Davis]

On Tue, Feb 22, 2011 at 11:48 AM, Philipp Überbacher
 wrote:
> I'm not sure it helps to talk about wayland, it seems to be very much
> future music. It seems ubuntu and fedora talk about a year or so, but
> after reading up about its current state (three years of development so
> far, pretty much proof of concept, working with some drivers only,
> crashing all over the place in the video demos) it seems to me that five
> years is a more realistic estimate (rather longer if we talk about
> replacing X). Just my guess, but it seems far from being in a reliably
> working state, so it's future music.
> Also, I don't see what's supposed to be so great about it, besides
> removing X11 cruft.

it does a lot more than "remove xcruft". it moves *nix display
technology into a modern era in which everything is just a drawing
surface that gets composited and along the way can be subject to
arbitrary transformation. rather than insist on the type of h/w
abstraction that X uses, which is fundamentally based on display
technology from 20 years ago, it uses an abstraction that is largely
h/w independent even if it relies on h/w to get the best performance
from the rendering model. you are not drawing to "windows", and you
don't have a "rectangle on the screen" under your control: you render
to a surface which will be composited into the frame buffer (possibly
with vblank sync, a concept that X really cannot export because of
network transparency).

another way to look at it is to take any sensible drawing API: Cairo,
PostScript, CoreDraw ... extract the core concepts behind the way they
relate drawing to a result ... now make that into the display server.
like JACK, don't provide very much access to the h/w concepts at all,
but instead provide a powerful, abstract model that is actually *more*
capable and flexible than working at the level of "what the hardware
does".

of course, you have to add event handling too, but wayland's approach
to this is also much more in line with contemporary technology than
X's fundamental models of input devices and so forth.

i agree that its a way from becoming the standard thing, but i'm
convinced that something like wayland is what we will all be on in a
few years.

--p
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ANN] IR: LV2 Convolution Reverb

[Philipp Überbacher]

Excerpts from Paul Davis's message of 2011-02-22 03:14:31 +0100:
> On Mon, Feb 21, 2011 at 6:12 PM, Fons Adriaensen  wrote:
> 
> > This excludes Windows (TM), but again, I couln't care less.
> 
> It also excludes OS X, which despite having "X11 support" isn't really
> what you mean by "supports X11".
> 
> at some point, focusing on X11 will  also start to exclude the next
> generation of linux UI systems which are not going to be X11 (even
> though they are re-using a lot of the internal code and can host X11
> windows). once you've seen them in action, i think that even you will
> be a believer :) I'm talking primarily about Wayland
> 
> http://en.wikipedia.org/wiki/Wayland_%28display_server_protocol%29

--snip--

I'm not sure it helps to talk about wayland, it seems to be very much
future music. It seems ubuntu and fedora talk about a year or so, but
after reading up about its current state (three years of development so
far, pretty much proof of concept, working with some drivers only,
crashing all over the place in the video demos) it seems to me that five
years is a more realistic estimate (rather longer if we talk about
replacing X). Just my guess, but it seems far from being in a reliably
working state, so it's future music.
Also, I don't see what's supposed to be so great about it, besides
removing X11 cruft.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev