Re: [LAD] [ann] CAPS 0.4.5

2011-04-13 Thread Tim E. Real 
On April 13, 2011 05:03:45 pm you wrote:
> On April 13, 2011 02:11:02 pm David Robillard wrote:
> > On 12/04/11 06:00 AM, Tim Goetze wrote:
> > > [David Robillard]
> > >
> > >> No, the pragmatic thing to do is not deliberately break your plugin
> > >> when several knowledgeable people have pointed out that doing so can
> > >> cause countless problems.
> > >
> > > Again: not the plugin is broken, but the host that assumes the port
> > > signature not to change over different plugin versions.
> >
> > No, a given index on your plugin no longer refers to the same port,
> > therefore the interface to the plugin has been broken, period.
>
> But he only wants to add a new port, not change them around or
>  remove them, doesn't he? So the indexes are not changing.
> So long as this new port comes after all the others, including audio,
>  what's the problem? Our MusE can cope, can the others?
> I agree that if this new port were to be sandwiched among the others
>  or if he were removing ports, that's breakage.
> How is a plugin supposed to grow and mature?
> I mean the Caps ToneStack gained a few 'model' values over the years.
> Did it change unique ID?
> Every time he wants to add a new port he's got to change the ID?
> So we end up with ten different versions with ten different IDs?
> Maybe the others are referring to breaking lrdf (I'm just learning lrdf
> now). Or if someone tries to load a song referring to the new plugin
> version, on an older system having the old plugin version.
> But I know MusE can still handle that, when loading a song it just ignores
>  any port ID out of range of the number of ports.
> It's a tough decision I know, I empathize, and if the consensus is that
>  the ID should be changed, I guess you gotta do it.
> But surely we could accept this small change, can't we?
> I mean what, really, would break?
>
> Thanks.
> Tim E.
Ah, just read up the thread terribly sorry. LV2 issues and such plus
 that bridge. 

A new plugin would be best. 

It's OK, we see it in some other plugins, incremental upgrades.
I never seemed to notice or mind much, guess I've always assumed
 that maybe other versions were made by someone else. 

Tim E.

>
> > > There is no mention of such a requirement in the interface
> > > specification, therefore the assumption is invalid and the
> > > responsibility for potential breakage lies with the host.
> >
> > This "assumption" is obvious, since indices are the ID for a port. To
> > argue that this is not true is literally equivalent to arguing that
> > LADSPA does not support saving session/patch/etc files in any way, at
> > all, whatsoever, since indices are meaningless and can not be relied
> > upon to refer to the same port when the plugin is reloaded later.
> > Obviously this is absurd.
> >
> > Your assumption, that hosts must refer to ports by an index within a
> > special separate index namespace for control and audio ports, is a much
> > greater one: it is not obvious, and the alternative is not absurd. It
> > is, in other words, clearly not in the language or spirit of LADSPA.
> > There is no reason someone reading ladspa.h and writing an
> > implementation would reasonably come to the conclusion that this is the
> > required correct behavior.
> >
> > > It has been shown that properly designed hosts handle the port
> > > addition just fine.
> >
> > This is just conveniently, but erroneously, redefining "properly
> > designed hosts" to mean "hosts that won't break when I break my plugin
> > in this particular way".
> >
> > > You may of course argue - not entirely unreasonably - that it is more
> > > pragmatic for the plugin author to cater for broken hosts than to
> > > expect them to be fixed.  Do you?
> >
> > No, because the host is not broken, as myself and others (including one
> > of the main authors of LADSPA itself, and the main author of the host in
> > question) have explained several times over.
> >
> > You are trying to argue that LADSPA does not present this "assumption"
> > that indices refer to a constant port, but as mentioned above, this is
> > an obvious conclusion, since the alternative is absurd (ports clearly
> > must have /some/ ID). LADSPA certainly does not specify the more complex
> > definition of "correct" use of port indices that you are trying to
> > justify (nor should it, for several reasons, but that is beside the
> > point).
> >
> > The simplest, most obvious, and intended rule is: If a given port index
> > does not refer to the same port on a new version of a plugin, then the
> > plugin interface has broken and the plugin ID MUST be changed. As Fons
> > mentioned, this is effectively a different plugin.
> >
> > Your definition, which splits the port index namespace into two separate
> > namespaces, one for control and one for audio, is not obviously intended
> > and is not mentioned or alluded to anywhere in LADSPA whatsoever. Hosts
> > that do not do this are not broken. That every single host author who
> > has participated in t

Re: [LAD] [ann] CAPS 0.4.5

2011-04-13 Thread Tim E. Real 
On April 13, 2011 02:11:02 pm David Robillard wrote:
> On 12/04/11 06:00 AM, Tim Goetze wrote:
> > [David Robillard]
> >
> >> No, the pragmatic thing to do is not deliberately break your plugin when
> >> several knowledgeable people have pointed out that doing so can cause
> >> countless problems.
> >
> > Again: not the plugin is broken, but the host that assumes the port
> > signature not to change over different plugin versions.
>
> No, a given index on your plugin no longer refers to the same port,
> therefore the interface to the plugin has been broken, period.
But he only wants to add a new port, not change them around or 
 remove them, doesn't he? So the indexes are not changing.
So long as this new port comes after all the others, including audio,
 what's the problem? Our MusE can cope, can the others?
I agree that if this new port were to be sandwiched among the others
 or if he were removing ports, that's breakage.
How is a plugin supposed to grow and mature?
I mean the Caps ToneStack gained a few 'model' values over the years.
Did it change unique ID?
Every time he wants to add a new port he's got to change the ID?
So we end up with ten different versions with ten different IDs?
Maybe the others are referring to breaking lrdf (I'm just learning lrdf now).
Or if someone tries to load a song referring to the new plugin version, 
 on an older system having the old plugin version.
But I know MusE can still handle that, when loading a song it just ignores 
 any port ID out of range of the number of ports.
It's a tough decision I know, I empathize, and if the consensus is that 
 the ID should be changed, I guess you gotta do it.
But surely we could accept this small change, can't we?
I mean what, really, would break?

Thanks.
Tim E.

>
> > There is no mention of such a requirement in the interface
> > specification, therefore the assumption is invalid and the
> > responsibility for potential breakage lies with the host.
>
> This "assumption" is obvious, since indices are the ID for a port. To
> argue that this is not true is literally equivalent to arguing that
> LADSPA does not support saving session/patch/etc files in any way, at
> all, whatsoever, since indices are meaningless and can not be relied
> upon to refer to the same port when the plugin is reloaded later.
> Obviously this is absurd.
>
> Your assumption, that hosts must refer to ports by an index within a
> special separate index namespace for control and audio ports, is a much
> greater one: it is not obvious, and the alternative is not absurd. It
> is, in other words, clearly not in the language or spirit of LADSPA.
> There is no reason someone reading ladspa.h and writing an
> implementation would reasonably come to the conclusion that this is the
> required correct behavior.
>
> > It has been shown that properly designed hosts handle the port
> > addition just fine.
>
> This is just conveniently, but erroneously, redefining "properly
> designed hosts" to mean "hosts that won't break when I break my plugin
> in this particular way".
>
> > You may of course argue - not entirely unreasonably - that it is more
> > pragmatic for the plugin author to cater for broken hosts than to
> > expect them to be fixed.  Do you?
>
> No, because the host is not broken, as myself and others (including one
> of the main authors of LADSPA itself, and the main author of the host in
> question) have explained several times over.
>
> You are trying to argue that LADSPA does not present this "assumption"
> that indices refer to a constant port, but as mentioned above, this is
> an obvious conclusion, since the alternative is absurd (ports clearly
> must have /some/ ID). LADSPA certainly does not specify the more complex
> definition of "correct" use of port indices that you are trying to
> justify (nor should it, for several reasons, but that is beside the point).
>
> The simplest, most obvious, and intended rule is: If a given port index
> does not refer to the same port on a new version of a plugin, then the
> plugin interface has broken and the plugin ID MUST be changed. As Fons
> mentioned, this is effectively a different plugin.
>
> Your definition, which splits the port index namespace into two separate
> namespaces, one for control and one for audio, is not obviously intended
> and is not mentioned or alluded to anywhere in LADSPA whatsoever. Hosts
> that do not do this are not broken. That every single host author who
> has participated in this thread agrees, and the fact that you need to
> add a version number so one can kludge around the broken plugin, makes
> that pretty clear...
>
> Cheers,
>
> -dr
>
> P.S. I do empathize with the fact that changing IDs where it /could/ not
> be necessary sucks; this is why LV2 has symbols which are the ID for a
> port instead. However, LADSPA is LADSPA, and doing what you are
> proposing is going to cause real headaches for real people, and would be
> remarkably unskillful given the feedback in this thread... pleas

[LAD] LAC 2011 programme is online.

2011-04-13 Thread Robin Gareus 
Hi all,

It's been online for a while, but with 4 weeks to go: the
conference-programme is now officially fixed:
  http://lac.linuxaudio.org/2011/?page=program
and for your xPhone or googol-calendar:
  http://lac.linuxaudio.org/2011/vcal.php

Should you attend LAC, please register if you have not done so:
  http://lac.linuxaudio.org/2011/?page=registration

If you can not make it to Maynooth: live streams will be available
during the conference and the recordings and papers will also be
published online afterward.


Looking forward to seeing you in Maynooth!


PS. We are going to provide some printed copies of the programme at
the conference registration-desk, but if you wish to do a colorful print
yourself:
  http://lac.linuxaudio.org/2011/printprogram.php

Set your browser's File->Print->Options->Print background colors
or simply run:
 wkhtmltopdf -s A4 --minimum-font-size 18 \
   http://lac.linuxaudio.org/2011/printprogram.php \
   lac2011.pdf

-- 
Robin Gareus
84bis Rue de Grenelle
75007 Paris, France

mobile: +33 612 738 346
mailto: ro...@gareus.org
jabber: xmpp:rgar...@ik.nu

phone & fax: +33 95 222 567 2

Public Key at http://pgp.mit.edu/
Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [ann] CAPS 0.4.5

2011-04-13 Thread David Robillard 

On 12/04/11 06:00 AM, Tim Goetze wrote:

[David Robillard]
   

No, the pragmatic thing to do is not deliberately break your plugin when
several knowledgeable people have pointed out that doing so can cause countless
problems.
 

Again: not the plugin is broken, but the host that assumes the port
signature not to change over different plugin versions.
   
No, a given index on your plugin no longer refers to the same port, 
therefore the interface to the plugin has been broken, period.

There is no mention of such a requirement in the interface
specification, therefore the assumption is invalid and the
responsibility for potential breakage lies with the host.
   
This "assumption" is obvious, since indices are the ID for a port. To 
argue that this is not true is literally equivalent to arguing that 
LADSPA does not support saving session/patch/etc files in any way, at 
all, whatsoever, since indices are meaningless and can not be relied 
upon to refer to the same port when the plugin is reloaded later.  
Obviously this is absurd.


Your assumption, that hosts must refer to ports by an index within a 
special separate index namespace for control and audio ports, is a much 
greater one: it is not obvious, and the alternative is not absurd. It 
is, in other words, clearly not in the language or spirit of LADSPA. 
There is no reason someone reading ladspa.h and writing an 
implementation would reasonably come to the conclusion that this is the 
required correct behavior.

It has been shown that properly designed hosts handle the port
addition just fine.
   
This is just conveniently, but erroneously, redefining "properly 
designed hosts" to mean "hosts that won't break when I break my plugin 
in this particular way".

You may of course argue - not entirely unreasonably - that it is more
pragmatic for the plugin author to cater for broken hosts than to
expect them to be fixed.  Do you?
   
No, because the host is not broken, as myself and others (including one 
of the main authors of LADSPA itself, and the main author of the host in 
question) have explained several times over.


You are trying to argue that LADSPA does not present this "assumption" 
that indices refer to a constant port, but as mentioned above, this is 
an obvious conclusion, since the alternative is absurd (ports clearly 
must have /some/ ID). LADSPA certainly does not specify the more complex 
definition of "correct" use of port indices that you are trying to 
justify (nor should it, for several reasons, but that is beside the point).


The simplest, most obvious, and intended rule is: If a given port index 
does not refer to the same port on a new version of a plugin, then the 
plugin interface has broken and the plugin ID MUST be changed. As Fons 
mentioned, this is effectively a different plugin.


Your definition, which splits the port index namespace into two separate 
namespaces, one for control and one for audio, is not obviously intended 
and is not mentioned or alluded to anywhere in LADSPA whatsoever. Hosts 
that do not do this are not broken. That every single host author who 
has participated in this thread agrees, and the fact that you need to 
add a version number so one can kludge around the broken plugin, makes 
that pretty clear...


Cheers,

-dr

P.S. I do empathize with the fact that changing IDs where it /could/ not 
be necessary sucks; this is why LV2 has symbols which are the ID for a 
port instead. However, LADSPA is LADSPA, and doing what you are 
proposing is going to cause real headaches for real people, and would be 
remarkably unskillful given the feedback in this thread... please just 
don't do it :)

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

Re: [LAD] questions about jack session

2011-04-13 Thread Rui Nuno Capela 

On 04/13/2011 01:00 PM, James Morris wrote:

On 13 April 2011 12:44, James Morris  wrote:

On 13 April 2011 12:42, Rui Nuno Capela  wrote:

please read your qjackctl/about box whether there's a "JACK Session support
disabled" written in red. that should say it all


Yeah, that says it all :/ Doh. Thanks.


...

The ARCH qjackctl package needs to be rebuilt against the newer JACK
then... ? The release date of the ARCH package is a couple of days
after the release of the recent QjackCtl. Will QjackCTL cope if it was
built with JACK Session support (on machine x) but running (on machine
y) against a  JACK without session support?



theoretically yes but murphy may have a different opinion ;)

byee
--
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] questions about jack session

2011-04-13 Thread James Morris 
On 13 April 2011 12:44, James Morris  wrote:
> On 13 April 2011 12:42, Rui Nuno Capela  wrote:
>> please read your qjackctl/about box whether there's a "JACK Session support
>> disabled" written in red. that should say it all
>
> Yeah, that says it all :/ Doh. Thanks.

...

The ARCH qjackctl package needs to be rebuilt against the newer JACK
then... ? The release date of the ARCH package is a couple of days
after the release of the recent QjackCtl. Will QjackCTL cope if it was
built with JACK Session support (on machine x) but running (on machine
y) against a  JACK without session support?

Cheers,
James.


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

Re: [LAD] questions about jack session

2011-04-13 Thread James Morris 
On 13 April 2011 12:42, Rui Nuno Capela  wrote:
> please read your qjackctl/about box whether there's a "JACK Session support
> disabled" written in red. that should say it all

Yeah, that says it all :/ Doh. Thanks.

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

Re: [LAD] questions about jack session

2011-04-13 Thread Rui Nuno Capela 

On 04/13/2011 12:29 PM, James Morris wrote:

Hi,

What is needed for a working jack session environment?

I was hoping to be able to use it with qjackctl-0.3.7 and jack-0.120.1
but this fails to work:

1) When "Save and Quit" is selected and "Save.." has finished, nothing quits.
2) Applications rarely start when a session is loaded and the entries
in the session window have red crosses next to them.

I need a working jack session environment because I'm trying to code
and test Petri-Foo's Jack session support.

So far the set session callback returns without error, but the
callback is never called (when using the setup mentioned above).

I briefly tried pyjacksm but get "inconsistent use of tabs and spaces
in indentation" errors (is that because of python3/python2 conflicts
arising from scripts starting with #!/usr/bin/python ?  I tried adding
a sed to the AUR PKGBUILD but failed to find the correct
search/replace terms.)



qjackctl >= 0.3.7 will only get full jack-session support *iif* it was 
ever built against libjack-dev-0.120.0 providing the necessary 
"jack/session.h" header.


otherwise, it's all just a dumbed-down patchbay alternative. as is, it 
only saves and loads for existing client connections--eventually, it may 
succeed and those "red crosses" will disapeer, one after another.


please read your qjackctl/about box whether there's a "JACK Session 
support disabled" written in red. that should say it all


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

[LAD] questions about jack session

2011-04-13 Thread James Morris 
Hi,

What is needed for a working jack session environment?

I was hoping to be able to use it with qjackctl-0.3.7 and jack-0.120.1
but this fails to work:

1) When "Save and Quit" is selected and "Save.." has finished, nothing quits.
2) Applications rarely start when a session is loaded and the entries
in the session window have red crosses next to them.

I need a working jack session environment because I'm trying to code
and test Petri-Foo's Jack session support.

So far the set session callback returns without error, but the
callback is never called (when using the setup mentioned above).

I briefly tried pyjacksm but get "inconsistent use of tabs and spaces
in indentation" errors (is that because of python3/python2 conflicts
arising from scripts starting with #!/usr/bin/python ?  I tried adding
a sed to the AUR PKGBUILD but failed to find the correct
search/replace terms.)

Any help appreciated,
Cheers,
James.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [offtopic] loopback

2011-04-13 Thread Jens M Andreasen 
On Wed, 2011-04-13 at 07:16 -0400, gene heskett wrote:

> Doing a  reply all this time, so you should get 2 copies if you get one 
> from the list.
> 

List is not responding. But I got a letter frpm
linux-audio-dev-boun...@lists.linuxaudio.org

when I tried to resubscribe. No go. 

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

Re: [LAD] [offtopic] loopback

2011-04-13 Thread gene heskett 
On Wednesday, April 13, 2011 07:15:19 AM Jens M Andreasen did opine:

> I did not get any? ... Not from LAD and not from Gene. Something is
> working though since  Veronica apparently could see the message from
> Gene.
> 
> Trying once more
> 
> /j
> 
> On Tue, 2011-04-12 at 23:08 -0700, Veronica Merryfield wrote:
> > On 2011-04-12, at 2:04 PM, gene heskett wrote:
> > > On Tuesday, April 12, 2011 05:03:51 PM Jens M Andreasen did opine:
> > >> Test: ISP ate my e-mail ...
> > >> 
> > >> /j
> > > 
> > > And this one made it through the gauntlet.
> > 
> > Or the ISP was sleeping off it's meal.

Doing a  reply all this time, so you should get 2 copies if you get one 
from the list.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)


 but, then I used an Atari, I was more likely to win the lottery in
ten countries simultaneously than get accelerated X
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Re: [LAD] [offtopic] loopback

2011-04-13 Thread Jens M Andreasen 
Nope. And not this one either. Only from you Veronica.
/j

On Wed, 2011-04-13 at 00:56 -0700, Veronica Merryfield wrote:
> Did you get your original test returned to you?
> 
> On 2011-04-13, at 12:49 AM, Jens M Andreasen wrote:
> 
> > I did not get any? ... Not from LAD and not from Gene. Something is
> > working though since  Veronica apparently could see the message from
> > Gene.
> > 
> > Trying once more
> > 
> > /j
> > 
> > On Tue, 2011-04-12 at 23:08 -0700, Veronica Merryfield wrote:
> >> On 2011-04-12, at 2:04 PM, gene heskett wrote:
> >> 
> >>> On Tuesday, April 12, 2011 05:03:51 PM Jens M Andreasen did opine:
> >>> 
>  Test: ISP ate my e-mail ...
>  
>  /j
>  
> >>> And this one made it through the gauntlet.
> >>> 
> >> Or the ISP was sleeping off it's meal.
> >> 
> >> 
> >> 
> > 
> > 
> 


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

Re: [LAD] [offtopic] loopback

2011-04-13 Thread Jens M Andreasen 
I did not get any? ... Not from LAD and not from Gene. Something is
working though since  Veronica apparently could see the message from
Gene.

Trying once more

/j

On Tue, 2011-04-12 at 23:08 -0700, Veronica Merryfield wrote:
> On 2011-04-12, at 2:04 PM, gene heskett wrote:
> 
> > On Tuesday, April 12, 2011 05:03:51 PM Jens M Andreasen did opine:
> > 
> >> Test: ISP ate my e-mail ...
> >> 
> >> /j
> >> 
> > And this one made it through the gauntlet.
> > 
> Or the ISP was sleeping off it's meal.
> 
> 
> 


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