Connect Policy

classic Classic list List threaded Threaded
112 messages Options
1 ... 3456
Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

Esben Stien
Esben Stien <[hidden email]> writes:

> it needs to connect when it starts up, but I don't think this
> problem should lie with the application.

Well, this is not exactly true, either. Applications may choose to
implement handling for connecting to what it is told to connect to. In
the case of LASH, applications will be told to restore a session,
which would include restoring a great deal of connections.

This really has nothing to do with auto connecting.

--
Esben Stien is b0ef@e     s      a            
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
          [sip|iax]:   e     e
           jid:b0ef@    n     n


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

federico-3
In reply to this post by Kjetil S. Matheussen
Kjetil S. Matheussen wrote:

>
> Melanie:
>
>>
>> My $0.02 would be this:
>>
>> The users who would want auto connect are commonly using apps that have
>> stereo outputs.
>> Therefore, autoconnect does not concern any application unless it
>> provides a stereo output signal.
>> Professional apps usually are designed to connect to multitrack
>> interfaces and cannot use autoconnect anyway.
>>
>
> *sigh*
>
> This has got nothing to do with professional apps or not. Its natural
> for sound-editors, multitrackers, softsynths, or synthesis tools like
> pd, supercollider or clm to autoconnect both inputs and outputs by
> default. And its natural for programs like jamin, jack-rack or
> freqtweak to autoconnect the outputs (only) by default.


I generally agree with your point.
In a "studio conception" of the audio workstation, I tend to think to
connections like real connections, like those in my analog equipment.
So in my /analog/ studio I choose(d) to connect an amp output to the
speakers, synthesizer's outputs to my ADAT I/O interface, and various
connections to the soundcard.
Each time I turn on all the devices, I don't have to connect all cables
from soundcard to amp, from amp to speakers, etc., they are still there,
cause I decided to route those connections in this way that day.

So it is right to have programs autoconnect by default to certain
in/outs, but this *should* be a decision that should be taken by the
user, and *then* the program should follow whatever the user preference is.

A real software example could be that, I want some soundcard outputs
being compressed and equalized before being sent to the speakers.
I achieve this by running jack-rack (just an example) and loading my
patch of effects.
Here I would like the ability to create a similar rule:

"the default stereo output is: jack_rack_in0 jack_rack_in1"

Looking to the software programming interface (I'm not too much involved
in programming, even if I work with computers), I think programs should
query the jack daemon for getting if and what the default outputs are.
Maybe I don't want a default connection at all, so I don't create any
rule, and the jack daemon would tell to programs that aren't any default
connections. Easy :)

If you like your users not to do stupid and repetitive tasks, just
create your rules. Computer has much memory than you and is very
appropriate to do this ;)

These are my two cents.
Sorry for my bad english, I guess I have not hurt you with my Italian
humour :)

--
Federico




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connect Policy

Eric Dantan Rzewnicki
In reply to this post by Lee Revell
On Thu, Mar 02, 2006 at 08:27:42PM -0500, Lee Revell wrote:
> On Thu, 2006-03-02 at 19:14 -0600, [hidden email] wrote:
> I think ALSA is good enough - the problems with it are well understood
> at this point, I'd expect ALSA 2.x to address them.  It does what it was

I've been a little out of touch for a while. Is alsa 2.x actually in the
works?

--
Eric Dantan Rzewnicki
Apprentice Linux Audio Developer and Mostly Harmless Sysadmin
(text below this line mandated by management)
Technical Operations Division  |  Radio Free Asia
2025 M Street, NW  |  Washington, DC 20036  |  202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
[hidden email].


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

Eric Dantan Rzewnicki
In reply to this post by Lee Revell
On Fri, Mar 03, 2006 at 06:07:39PM -0500, Lee Revell wrote:
> On Fri, 2006-03-03 at 22:48 +0000, Melanie wrote:
> > Hi,
> > Glynn Clements wrote:
> > > Auto-connection shouldn't be left to the individual applications, but
> > > performed by the connection manager (qjackctl, JACK patch bay etc).

> > That won't work. Apps like the xmms jack plugin connect and play
> > audio immediately. If you wait for qjackctl to connect them, it will
> > chop off the first 1/2 sec. of audio. That would happen for each
> > song with some settings. Apps must be able to autoconnect, only
> > there should be a way for the user to specify what they autoconnect to.

> That's broken behavior, JACK applications should open their ports on
> startup and leave them open until they're done.  It seems to be an
> artifact of non-mixing sound systems where you have to release the
> device when you're not playing audio so you don't block other apps.

I was just about to ask for clarification on this point. So, this means
that Audacity is broken in this regard?

Currently Audacity with portaudio-v19 creates and destroys its ports for
each play or record action, autoconnecting/disconnecting in the process.
Does anyone know if this is a limitation of portaudio's jack support or
something that can be fixed inside Audacity?

--
Eric Dantan Rzewnicki
Apprentice Linux Audio Developer and Mostly Harmless Sysadmin
(text below this line mandated by management)
Technical Operations Division  |  Radio Free Asia
2025 M Street, NW  |  Washington, DC 20036  |  202-530-4900
CONFIDENTIAL COMMUNICATION
This e-mail message is intended only for the use of the addressee and
may contain information that is privileged and confidential. Any
unauthorized dissemination, distribution, or copying is strictly
prohibited. If you receive this transmission in error, please contact
[hidden email].


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

federico-3
In reply to this post by Kjetil S. Matheussen
Kjetil S. Matheussen wrote:

>
> Melanie:
>
>>
>> My $0.02 would be this:
>>
>> The users who would want auto connect are commonly using apps that have
>> stereo outputs.
>> Therefore, autoconnect does not concern any application unless it
>> provides a stereo output signal.
>> Professional apps usually are designed to connect to multitrack
>> interfaces and cannot use autoconnect anyway.
>>
>
> *sigh*
>
> This has got nothing to do with professional apps or not. Its natural
> for sound-editors, multitrackers, softsynths, or synthesis tools like
> pd, supercollider or clm to autoconnect both inputs and outputs by
> default. And its natural for programs like jamin, jack-rack or
> freqtweak to autoconnect the outputs (only) by default.


I generally agree with your point.
In a "studio conception" of the audio workstation, I tend to think to
connections like real connections, like those in my analog equipment.
So in my /analog/ studio I choose(d) to connect an amp output to the
speakers, synthesizer's outputs to my ADAT I/O interface, and various
connections to the soundcard.
Each time I turn on all the devices, I don't have to connect all cables
from soundcard to amp, from amp to speakers, etc., they are still there,
cause I decided to route those connections in this way that day.

So it is right to have programs autoconnect by default to certain
in/outs, but this *should* be a decision that should be taken by the
user, and *then* the program should follow whatever the user preference is.

A real software example could be that, I want some soundcard outputs
being compressed and equalized before being sent to the speakers.
I achieve this by running jack-rack (just an example) and loading my
patch of effects.
Here I would like the ability to create a similar rule:

"the default stereo output is: jack_rack_in0 jack_rack_in1"

Looking to the software programming interface (I'm not too much involved
in programming, even if I work with computers), I think programs should
query the jack daemon for getting if and what the default outputs are.
Maybe I don't want a default connection at all, so I don't create any
rule, and the jack daemon would tell to programs that aren't any default
connections. Easy :)

If you like your users not to do stupid and repetitive tasks, just
create your rules. Computer has much memory than you and is very
appropriate to do this ;)

These are my two cents.
Sorry for my bad english, I guess I have not hurt you with my Italian
humour :)

--
Federico





-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

federico-3
In reply to this post by Kjetil S. Matheussen
Kjetil S. Matheussen wrote:

>
> Melanie:
>
>>
>> My $0.02 would be this:
>>
>> The users who would want auto connect are commonly using apps that have
>> stereo outputs.
>> Therefore, autoconnect does not concern any application unless it
>> provides a stereo output signal.
>> Professional apps usually are designed to connect to multitrack
>> interfaces and cannot use autoconnect anyway.
>>
>
> *sigh*
>
> This has got nothing to do with professional apps or not. Its natural
> for sound-editors, multitrackers, softsynths, or synthesis tools like
> pd, supercollider or clm to autoconnect both inputs and outputs by
> default. And its natural for programs like jamin, jack-rack or
> freqtweak to autoconnect the outputs (only) by default.


I generally agree with your point.
In a "studio conception" of the audio workstation, I tend to think to
connections like real connections, like those in my analog equipment.
So in my /analog/ studio I choose(d) to connect an amp output to the
speakers, synthesizer's outputs to my ADAT I/O interface, and various
connections to the soundcard.
Each time I turn on all the devices, I don't have to connect all cables
from soundcard to amp, from amp to speakers, etc., they are still there,
cause I decided to route those connections in this way that day.

So it is right to have programs autoconnect by default to certain
in/outs, but this *should* be a decision that should be taken by the
user, and *then* the program should follow whatever the user preference is.

A real software example could be that, I want some soundcard outputs
being compressed and equalized before being sent to the speakers.
I achieve this by running jack-rack (just an example) and loading my
patch of effects.
Here I would like the ability to create a similar rule:

"the default stereo output is: jack_rack_in0 jack_rack_in1"

Looking to the software programming interface (I'm not too much involved
in programming, even if I work with computers), I think programs should
query the jack daemon for getting if and what the default outputs are.
Maybe I don't want a default connection at all, so I don't create any
rule, and the jack daemon would tell to programs that aren't any default
connections. Easy :)

If you like your users not to do stupid and repetitive tasks, just
create your rules. Computer has much memory than you and is very
appropriate to do this ;)

These are my two cents.
Sorry for my bad english, I guess I have not hurt you with my Italian
humour :)

--
Federico






-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Connect Policy

Lee Revell
In reply to this post by Eric Dantan Rzewnicki
On Sun, 2006-03-05 at 04:33 -0500, Eric Dantan Rzewnicki wrote:
> On Thu, Mar 02, 2006 at 08:27:42PM -0500, Lee Revell wrote:
> > On Thu, 2006-03-02 at 19:14 -0600, [hidden email] wrote:
> > I think ALSA is good enough - the problems with it are well understood
> > at this point, I'd expect ALSA 2.x to address them.  It does what it was
>
> I've been a little out of touch for a while. Is alsa 2.x actually in the
> works?
>

I am not aware of any work on it, and in fact I think it would be a
waste of effort now - we can already deliver better latency on almost
all existing hardware than Windows or OSX with ALSA 1.x, JACK and the
-rt kernel.

There's an ALSA 1.x TODO in the distribution, which contains more
pressing issues.  But if anyone wanted to start contributing to ALSA
now, I think their time would be best spent fixing driver problems.

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

Fernando Lopez-Lezcano
In reply to this post by Eric Dantan Rzewnicki
On Sun, 2006-03-05 at 04:52 -0500, Eric Dantan Rzewnicki wrote:

> On Fri, Mar 03, 2006 at 06:07:39PM -0500, Lee Revell wrote:
> > On Fri, 2006-03-03 at 22:48 +0000, Melanie wrote:
> > > Hi,
> > > Glynn Clements wrote:
> > > > Auto-connection shouldn't be left to the individual applications, but
> > > > performed by the connection manager (qjackctl, JACK patch bay etc).
>
> > > That won't work. Apps like the xmms jack plugin connect and play
> > > audio immediately. If you wait for qjackctl to connect them, it will
> > > chop off the first 1/2 sec. of audio. That would happen for each
> > > song with some settings. Apps must be able to autoconnect, only
> > > there should be a way for the user to specify what they autoconnect to.
>
> > That's broken behavior, JACK applications should open their ports on
> > startup and leave them open until they're done.  It seems to be an
> > artifact of non-mixing sound systems where you have to release the
> > device when you're not playing audio so you don't block other apps.
>
> I was just about to ask for clarification on this point. So, this means
> that Audacity is broken in this regard?

>From my point of view, very broken.

It is quite difficult to use in the context of a normal Jack setup (ie:
I want to record a synth so I have to go to the "Preferences" menu and
change the input there!, I seem to remember that it does not scan things
again so if you did not have the synth open when audacity started it
won't see it - I may be wrong as it's been a while since I tested
this[*]).

> Currently Audacity with portaudio-v19 creates and destroys its ports for
> each play or record action, autoconnecting/disconnecting in the process.
> Does anyone know if this is a limitation of portaudio's jack support or
> something that can be fixed inside Audacity?

I'd like to know that as well, any audacity insiders around here?.
-- Fernando

[*] this behavior would imply that the limitation _may_ be in portaudio
itself - I have seen the same broken behavior in its cousin portmidi,
there is nothing in the portmidi api (that I know of) that you can use
to make it rescan the alsa sequencer and refresh what ports are
available.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

riwright
In reply to this post by melanie-36


Melanie wrote:
Hi,

Glynn Clements wrote:
  
Auto-connection shouldn't be left to the individual applications, but
performed by the connection manager (qjackctl, JACK patch bay etc).
    

That won't work. Apps like the xmms jack plugin connect and play
audio immediately. If you wait for qjackctl to connect them, it will
chop off the first 1/2 sec. of audio. That would happen for each
song with some settings. Apps must be able to autoconnect, only
there should be a way for the user to specify what they autoconnect to.

Melanie
Partially untrue.

I put a feature request in to the author of xmms-jack (Chris Morgan) last fall and as a result, starting in ver0.15 of xmms jack plugin, the auto-connect behavior is user configurable with three options: 1) connect to all jack ports.  2) connect to all output ports.  3) connect none.

I requested the "connect none" feature for similar reasons that others on this list don't want client programs auto-connecting to jack ports.  I didn't want connections going to the default ports, but rather I wanted them connected to a different jack client.  After weeks of finding myself manally removing the default connections and creating my desired connections, I made the feature request.  Similarly, I don't see why a configuration solution cannot be found that meets the needs of all users discussed here - both professional and casual.

I'm not a hacker so my input is what it is, but  it seems a reasonable solution could be similar to the xmms-jack behavior with additional improvements.  Someone here mentioned earlier popping up a dialog box when a client program is first run that offers different default auto-connect behavior options with the default of those choices aimed at the casual user who wants the audio to Just Play.  However, perhaps a global auto-connect allow/deny option in jack is also appropriate to allow the pro users protection from ill behaving client programs?  Again, I've seen several similar suggestions here already.

One point I still don't fully understand is this: for those inexperienced users that want a media player to Just Play sound, why is JACK being used at all?  Why not just use the ALSA driver?  Maybe the problem is that JACK is already running for other reasons and has grabbed the sound card?

Rick

Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

Paul Davis
> One point I still don't fully understand is this: for those
> inexperienced users that want a media player to Just Play sound, why
> is JACK being used at all?  Why not just use the ALSA driver?  Maybe
> the problem is that JACK is already running for other reasons and has
> grabbed the sound card?

precisely.




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

Lee Revell
In reply to this post by riwright
On Tue, 2006-03-07 at 11:59 -0500, Rick Wright wrote:
> I put a feature request in to the author of xmms-jack (Chris Morgan)
> last fall and as a result, starting in ver0.15 of xmms jack plugin,
> the auto-connect behavior is user configurable with three options: 1)
> connect to all jack ports.  2) connect to all output ports.  3)
> connect none.

So if I have 16 output channels 1 and 2 connect to all of them?!?
That's crazy.  Does the left XMMS output connect to odd numbered ports
and the right XMMS output to the even ones?

Lee



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel
Reply | Threaded
Open this post in threaded view
|

Re: Re: Connect Policy

riwright


Lee Revell wrote:
On Tue, 2006-03-07 at 11:59 -0500, Rick Wright wrote:
  
I put a feature request in to the author of xmms-jack (Chris Morgan)
last fall and as a result, starting in ver0.15 of xmms jack plugin,
the auto-connect behavior is user configurable with three options: 1)
connect to all jack ports.  2) connect to all output ports.  3)
connect none.
    

So if I have 16 output channels 1 and 2 connect to all of them?!?
That's crazy.
Agreed.  I only use the connect-none option and then use QJC's patchbay.
Does the left XMMS output connect to odd numbered ports
and the right XMMS output to the even ones?

Lee


  
Just checked:
"Connect All" connects Left XMMS output to all odd numbered ports and Right XMMS output to all even ports.
"Connect Output" connects Left XMMS output to playback_1 and Right XMMS output to playback_2 (i.e. the first 2)
"Connect None" (obviously) makes no connections.


For the record, my feature request was the "connect-none" option.  The author decided to include the other options.

Rick
1 ... 3456