Connect Policy

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

Re: Connect Policy

Glynn Clements

Chris Cannam wrote:

> > Simple example. I'm mixing an Ardour session. Main output (to the
> > monitors) is P 11,12 (SPDIF to monitor amp). P and C 1, 2 are in
> > use as Ardour inserts to send and receive signals to / from external
> > analog effect processors.
> >
> > No I start SuperJackEQ that autoconnects itself to C and P 1. This
> > creates a loop with the external processor. Very likely this
> > will produce some high pitched oscillation that will burn out
> > my monitor's tweeters in a second.
>
> Perhaps it might be more helpful for you (with such strong requirements for
> predictable behaviour from JACK connections) if you could configure JACK
> itself not to accept connection changes at all, from any but a set of known,
> trusted connection manager clients?

That would certainly be preferable. If you don't want auto-connect,
you probably /really/ don't want auto-connect, and you would rather
have better guarantees than a "recommended policy" which application
developers may or may not honour.

--
Glynn Clements <[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: Connect Policy

Lee Revell
In reply to this post by Kjetil S. Matheussen
On Tue, 2006-02-28 at 22:50 -0800, Kjetil S. Matheussen wrote:

> On Wed, 1 Mar 2006, Esben Stien wrote:
>
> > "Kjetil S. Matheussen" <[hidden email]> writes:
> >
> >> Thats not a rational argument. Give me a real life situation.
> >
> > I would disagree. It's pretty real life that you can't possibly know
> > how the user wants the application connected to their JACK network.
> >
> Well, who is this user? Who is it that don't want to connect their
> application to their physical output? I guess there might be one or two
> out there who have a very special setup, but unless more than 50% don't,
> I don't understand why it shouldn't autoconnect by default.
>

Because if you have more 2 outputs which do you autoconnect to?  "The
first two" is arbitrary and IMHO wrong.

And Esben already gave a perfectly valid use case where autoconnect is
bad - what if the ports the app deviced to connect to are connected to a
really loud amp?  You could damage your hearing.

The arguments for JACK not autoconnecting by default are the same as the
arguments for ALSA muting everything by default.

>
> >> What if you have to close your application? And what about sndplay
> >
> > I'm not saying connect it once and forget about it and then do the
> > same when you close it at open it again. I'm saying, favor a
> > connection management solution and once and for all, determine where
> > the app connects to.
> >
> >> not everyone bothers to do that
> >
> > Maybe we need to figure out why then. Is it because there is only a
> > command driven application for this available maybe?.
>
> Two important reasons: 1. Most users don't need it. 2. Applications need
> to support it, and they currently don't, probably because most users don't
> need it.
>
>
> > I prefer command
> > driven tools exclusively, but people might prefer a GUI. Maybe the
> > connection management daemon could be set to a remembering state, so
> > that it would remember connections automatically; that way you would
> > only connect it the first time and then the daemon would remember that
> > and act accordingly the next time you start it, unless you specify a
> > rule for that application.
> >
>
> Its impossible to have a daemon autoconnect for the applications
> properly unless the applications give special concerns for the daemons.
>
>
>
> -------------------------------------------------------
> 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
>



-------------------------------------------------------
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 Kjetil S. Matheussen
On Wed, 2006-03-01 at 02:01 -0800, Kjetil S. Matheussen wrote:
>
> Nope, defaults should do what most people would have done if there
> hadn't been a default.

And if you have 10 outputs it's IMPOSSIBLE to tell which two "most
people" would connect to.

It's like trying to guess which two channels on a multichannel mixing
board you should plug into.  It's IMPOSSIBLE to tell without some
knowledge of how the sound guy has set up the board.

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: Connect Policy

Lee Revell
In reply to this post by cannam
On Wed, 2006-03-01 at 14:13 +0000, Chris Cannam wrote:

> On Wednesday 01 Mar 2006 12:53, Alfons Adriaensen wrote:
> > Simple example. I'm mixing an Ardour session. Main output (to the
> > monitors) is P 11,12 (SPDIF to monitor amp). P and C 1, 2 are in
> > use as Ardour inserts to send and receive signals to / from external
> > analog effect processors.
> >
> > No I start SuperJackEQ that autoconnects itself to C and P 1. This
> > creates a loop with the external processor. Very likely this
> > will produce some high pitched oscillation that will burn out
> > my monitor's tweeters in a second.
>
> Perhaps it might be more helpful for you (with such strong requirements for
> predictable behaviour from JACK connections) if you could configure JACK
> itself not to accept connection changes at all, from any but a set of known,
> trusted connection manager clients?

That's ass backwards.  It should behave sanely by DEFAULT.

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: Connect Policy

Glynn Clements
In reply to this post by D. Michael McIntyre-3

D. Michael 'Silvan' McIntyre wrote:

> > Should it not be a policy of JACK applications to not auto connect to
> > anything?. Could we put it on the web page as a recommended policy?.
>
> I wonder why?  As a user, JACK applications that have to be hooked up manually
> really annoy me, and I configure everything to auto-connect when it can.

Who said anything about having to hook up applications manually? The
problem isn't that auto-connection happens, it's that individual
applications are deciding for themselves to auto-connect, and to what,
rather than leaving it to the patch manager to connect them.

> So what's evil about that?  What's the behind the scenes insider audio hacker
> objection to this perfectly user-friendly behavior?

Individual applications have no idea what they are supposed to be
connected to and when.

If your setup begins and ends with a single audio player connecting
directly to the hardware ports on startup, JACK is probably the wrong
solution; you may as well just use ALSA.

If I start an audio player, I don't want it connected to the hardware
ports. I probably want it connected to the input of the Ardour,
JACK-rack, etc network whose output is connected to the hardware ports.

In particular, if the intended path through network has significant
negative gain, I don't want sources bypassing it and coming out at full
volume.

--
Glynn Clements <[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: Connect Policy

cannam
In reply to this post by Lee Revell
On Wednesday 01 Mar 2006 17:12, Lee Revell wrote:
> That's ass backwards.  It should behave sanely by DEFAULT.

That's not a helpful or polite response, Lee.


Chris


-------------------------------------------------------
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

Fons Adriaensen
In reply to this post by Lee Revell
On Wed, Mar 01, 2006 at 12:11:01PM -0500, Lee Revell wrote:
> On Wed, 2006-03-01 at 02:01 -0800, Kjetil S. Matheussen wrote:
> >
> > Nope, defaults should do what most people would have done if there
> > hadn't been a default.
>
> And if you have 10 outputs it's IMPOSSIBLE to tell which two "most
> people" would connect to.

Right. And what I'd do has probably no relation at all with what
most people will do, and I see no reason why I should be bothered
with their choices. And before someone remarks that I'd bother
them with my choices, that is simply not true. Having a default
of no connections is perfectly neutral.

--
FA




-------------------------------------------------------
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

Fons Adriaensen
In reply to this post by Glynn Clements
On Wed, Mar 01, 2006 at 05:02:20PM +0000, Glynn Clements wrote:

> > > Simple example. I'm mixing an Ardour session. Main output (to the
> > > monitors) is P 11,12 (SPDIF to monitor amp). P and C 1, 2 are in
> > > use as Ardour inserts to send and receive signals to / from external
> > > analog effect processors.
> > >
> > > No I start SuperJackEQ that autoconnects itself to C and P 1. This
> > > creates a loop with the external processor. Very likely this
> > > will produce some high pitched oscillation that will burn out
> > > my monitor's tweeters in a second.
> >
> > Perhaps it might be more helpful for you (with such strong requirements for
> > predictable behaviour from JACK connections) if you could configure JACK
> > itself not to accept connection changes at all, from any but a set of known,
> > trusted connection manager clients?
>
> That would certainly be preferable. If you don't want auto-connect,
> you probably /really/ don't want auto-connect, and you would rather
> have better guarantees than a "recommended policy" which application
> developers may or may not honour.

For some reason Chris' post didn't arrive here. Since his question
seems to put to me I take the liberty to override your answer :-)

No, that is not what I'd prefer. I'm perfectly happy with connections
being made from within apps. What I do not want is apps doing this
without being told to do it, by a command line option, configuration
option, or as a result of user interaction.

--
FA


-------------------------------------------------------
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 cannam
On Wed, 2006-03-01 at 17:47 +0000, Chris Cannam wrote:
> On Wednesday 01 Mar 2006 17:12, Lee Revell wrote:
> > That's ass backwards.  It should behave sanely by DEFAULT.
>
> That's not a helpful or polite response, Lee.

And this is a development mailing list not a user list so I'm not sugar
coating my responses ;-).

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: Connect Policy

Lee Revell
In reply to this post by cannam
On Wed, 2006-03-01 at 17:47 +0000, Chris Cannam wrote:
> On Wednesday 01 Mar 2006 17:12, Lee Revell wrote:
> > That's ass backwards.  It should behave sanely by DEFAULT.
>
> That's not a helpful or polite response, Lee.

What I mean is, JACK is a professional app and should behave the way
professionals expect it to, not new users.  And audio professionals
expect to have to plug boxes together before the sound from the first
comes out of the second.  Their systems may in fact be set up such that
autoconnection is disastrous.

Autoconnection is fine if the user has told the app to do that - it must
not just happen mysteriously.

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: Connect Policy

cannam
In reply to this post by Lee Revell
On Wednesday 01 Mar 2006 18:00, Lee Revell wrote:
> On Wed, 2006-03-01 at 17:47 +0000, Chris Cannam wrote:
> > On Wednesday 01 Mar 2006 17:12, Lee Revell wrote:
> > > That's ass backwards.  It should behave sanely by DEFAULT.
> >
> > That's not a helpful or polite response, Lee.
>
> And this is a development mailing list not a user list so I'm not sugar
> coating my responses ;-).

I wouldn't mind if your response had been merely impolite.  The problem was
that it was also useless.

We obviously all agree that default behaviour should be sane.  We just
disagree on what the sane default is, and you know that.

What may be productive would be to find a better method for applications such
as Rosegarden and Hydrogen (whose users probably mostly want autoconnection,
and whose developers are unlikely to be swayed by your opinion that their
views are insane) to get what they consider reasonable behaviour.  If there's
no better alternative, then obviously we're going to continue defaulting to
connecting to the first couple of physical JACK ports.  "Making no sound by
default" is not a better alternative, to most users of these programs.


Chris


-------------------------------------------------------
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
On Wed, 2006-03-01 at 18:07 +0000, Chris Cannam wrote:

> On Wednesday 01 Mar 2006 18:00, Lee Revell wrote:
> > On Wed, 2006-03-01 at 17:47 +0000, Chris Cannam wrote:
> > > On Wednesday 01 Mar 2006 17:12, Lee Revell wrote:
> > > > That's ass backwards.  It should behave sanely by DEFAULT.
> > >
> > > That's not a helpful or polite response, Lee.
> >
> > And this is a development mailing list not a user list so I'm not sugar
> > coating my responses ;-).
>
> I wouldn't mind if your response had been merely impolite.  The problem was
> that it was also useless.
>
> We obviously all agree that default behaviour should be sane.  We just
> disagree on what the sane default is, and you know that.
>
> What may be productive would be to find a better method for applications such
> as Rosegarden and Hydrogen (whose users probably mostly want autoconnection,
> and whose developers are unlikely to be swayed by your opinion that their
> views are insane) to get what they consider reasonable behaviour.  If there's
> no better alternative, then obviously we're going to continue defaulting to
> connecting to the first couple of physical JACK ports.  "Making no sound by
> default" is not a better alternative, to most users of these programs.

You should pop up a splash screen the first time the app is run telling
users that to get sound they will either have enable autoconnection
(maybe with "Click here to enable autoconnect"), or connect the
program's outputs manually to some JACK ports.

It's fine to enable autoconnect once the user has asked for it but Fons'
use cases clearly show that unsolicited auto-connect is undesirable.

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: Connect Policy

Fons Adriaensen
On Wed, Mar 01, 2006 at 01:20:11PM -0500, Lee Revell wrote:

> You should pop up a splash screen the first time the app is run telling
> users that to get sound they will either have enable autoconnection
> (maybe with "Click here to enable autoconnect"), or connect the
> program's outputs manually to some JACK ports.

This makes a lot of sense and it is more user-friendly than I ever
will be :-)
 
> It's fine to enable autoconnect once the user has asked for it but Fons'
> use cases clearly show that unsolicited auto-connect is undesirable.

This reminds me of that computerised car that switches on the lights
when it gets dark. It also cuts the radio when you switch off the main
contact. Fine, that's what most people want most of the time.
Until you go to a drive-in cinema and have to switch on the radio
to receive the sound.

--
FA


-------------------------------------------------------
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

Luis Garrido-4
In reply to this post by cannam
Correct me if I am too mistaken, but if I understood everything that
was said here, I think that an acceptable default behaviour, both for
pro and noob users, and not very difficult to implement, either in CLI
or GUI, would be some interaction like:

----------------------------------------------------------------------------------------------------

"This application needs to be connected to the jack audio server in
order to make any sound."

"Select the jack ports you want this application to be connected to
(if you don't know what this means, you probably want to set the
volume of your loudspeakers at a sensible level and accept the current
selection.)"

(list of jack ports with the two first ones selected by default and a
'none' option)

"Do you want to the application to remember this setting a the default
for future sessions?"

----------------------------------------------------------------------------------------------------

Doesn't seem too much/difficult work, either for the LAU and the LAD.

If what I said is dumb-assed, half-brained or just plain stupid,
answers like "you're wrong because..." will do, thanks ;-)

Luis
N�HS^�隊X���'���u��<�ڂ�.���y�"� �*m�x%jx.j���^�קvƩ�X�jب�ȧ��m�ݚ���v&��קv�^�+����j�Z���{az���^��h��஋�n���)��{h�����ا�׫�+h�(m�����Z��jY�w��ǥrg�y$��Oxḝۍ{�GZ�׮6%�$��^��fj)b� b��ZrH�u�ޖX���(��~��zw���i����l���q���z���l�X��)ߣ��rH�u�ޔ
Reply | Threaded
Open this post in threaded view
|

Re: Connect Policy

Lee Revell
In reply to this post by Fons Adriaensen
On Wed, 2006-03-01 at 19:45 +0100, fons adriaensen wrote:
> This reminds me of that computerised car that switches on the lights
> when it gets dark. It also cuts the radio when you switch off the main
> contact. Fine, that's what most people want most of the time.
> Until you go to a drive-in cinema and have to switch on the radio
> to receive the sound.

Or laptops that can't do low latency audio because the vendor chose to
implement all the BIOS power management stuff via SMM traps.  "Most
people won't notice if the CPU goes away for a few ms".

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: Connect Policy

Lee Revell
In reply to this post by Luis Garrido-4
On Wed, 2006-03-01 at 19:46 +0100, Luis Garrido wrote:
> Doesn't seem too much/difficult work, either for the LAU and the LAD.
>
> If what I said is dumb-assed, half-brained or just plain stupid,
> answers like "you're wrong because..." will do, thanks ;-)

Great idea for GUI apps and complex CLI ones.  It's the standard way to
solve problems like this where both choices of default are unacceptable
to part of the user base (like the Microsoft "you are about to send info
over a non-secure connection" dialog).

I think for simple apps that auto-plays when you launch them and don't
maintain any state, it's OK to autoconnect - it's probably a safe bet
that if someone does "jack_play file.wav" they want to hear the sound
right now.

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: Connect Policy

cannam
In reply to this post by Lee Revell
On Wednesday 01 Mar 2006 18:20, Lee Revell wrote:
> You should pop up a splash screen the first time the app is run
> telling users that to get sound they will either have enable
> autoconnection (maybe with "Click here to enable autoconnect"), or
> connect the program's outputs manually to some JACK ports.

Thank you (and Luis).  Yes, something like that makes a lot more sense,
at least for larger applications.

We have "first-time user setup wizard thing" on the Rosegarden TODO list
already, so any ideas about what might want to go in it are always
welcome.  Finding the time to implement it is another matter, as ever.


Chris


-------------------------------------------------------
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

Kjetil S. Matheussen
In reply to this post by Alfons Adriaensen-2
On Wed, 1 Mar 2006, Alfons Adriaensen wrote:

> On Wed, Mar 01, 2006 at 02:01:46AM -0800, Kjetil S. Matheussen wrote:
>
>> On Wed, 1 Mar 2006, Alfons Adriaensen wrote:
>>
>>> In my case there are 10 capture and 10 playback ports, all connected
>>> to the multitrack interface and / or the auxiliary sends of an
>>> external mixing desk. None of them have a fixed function.
>>>
>>> When I start I new application I want to be *_100 percent_* sure it
>>> does *not* connect to anything. If it did it could e.g. easily create
>>> a feedback loop, and destroy my speakers or someone's ears in a second.
>>>
>>
>> This is not jacks responsibility. If you're not sure what you're doing,
>> you should turn down some volume so that you don't destroy anything.
>
> It's the application's responsibility - there is no alternative.
>
> When working in a real studio, or with high power PA equipment, it's
> an engineers reflex to check connections before powering up a piece of
> equipment. Software apps that connect themselves defeat this elementary
> precaution. Turning down the volume is no solution - in many cases
> you can't interrupt what's going on, and there may be other destinations
> than just your studio monitors: musicians' headphones, a broadcast
> output, recording, whatever.
>
> I can guarantee you that when you blow up some expensive equipment
> in this way, people won't be happy. If you are a visiting engineer,
> you're probably less welcome afterwards. If you are an intern or
> apprentice you can forget your career at that studio and possibly
> some others.
>
>
>> I also wonder what kind of situations you specifically are thinking
>> about. I don't think the scenaria you draw up is something most jack
>> apps should care the least about.
>
> Simple example. I'm mixing an Ardour session. Main output (to the
> monitors) is P 11,12 (SPDIF to monitor amp). P and C 1, 2 are in
> use as Ardour inserts to send and receive signals to / from external
> analog effect processors.
>
> No I start SuperJackEQ that autoconnects itself to C and P 1. This
> creates a loop with the external processor. Very likely this
> will produce some high pitched oscillation that will burn out
> my monitor's tweeters in a second.
>


This is a special case. The audio engeneer have to find
workarounds for the few programs that might cause the kinds of trouble
you are worried about here.



>
>>> It is trivially simple to have no default connections, and let the
>>> user specificy any connection he / she wants in a config file that
>>> will be there anyway. The default should be none.
>
>> Sorry, but I think you are in a bit fantasy-world-mode now. Very few
>> bother to edit configuration files unless they have to, and its also very
>> little point in doing so, since most people want their programs to
>> connect to the physical ports.
>
> Maybe they don't bother, but they [explicit language deleted] should.
> Jack is supposed to be the audio interconnect system for professional
> use. It should not be dumbed down to suit nitwits (*) or people who
> are just to lazy to learn elementary things. Why does qjackctl exist ?
>

Jack can be used for many purposes. I don't like that you are trying to
force your view upon other programs. I'm going to keep my jack software to
continue autoconnecting no matter what your special concerns are. However,
if there are good reasons for the software _not_ to autoconnect, in
some cases, I will of course make an option not to autoconnect. As a
matter of fact, we are discussing how to do that with sndlib right now on
the cm mailing list, after getting a request from Esben.



  >> I also don't think programmers bothers to  add configuration file
>> options for their programs just because someones got the idea that
>> autoconnecting is a bad idea.
>
> And why not ?

Time. Theres so much software I want to make, and only very little time.
If _you_ need configuration file for some software, I recommend you to
send patches.




-------------------------------------------------------
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

Kjetil S. Matheussen
In reply to this post by Lee Revell
On Wed, 1 Mar 2006, Lee Revell wrote:

> On Wed, 2006-03-01 at 02:01 -0800, Kjetil S. Matheussen wrote:
>>
>> Nope, defaults should do what most people would have done if there
>> hadn't been a default.
>
> And if you have 10 outputs it's IMPOSSIBLE to tell which two "most
> people" would connect to.
>
> It's like trying to guess which two channels on a multichannel mixing
> board you should plug into.  It's IMPOSSIBLE to tell without some
> knowledge of how the sound guy has set up the board.

I can't believe this argumentation. 99.999% of all users will of course
use the two first physical output ports. And those two ports are very easy
to find because jack has a special flag to find those ports.

Because of some artificial perfect-world argumentation (meaning: people
have different setups, a computer can't read the minds of a human so lets
just bail out and do nothing, because we can't make it perfect for
everyone by default), you try to make most jack software more inconvenient
to use for 99.999% of the users.





-------------------------------------------------------
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

Kjetil S. Matheussen
In reply to this post by Fons Adriaensen
On Wed, 1 Mar 2006, fons adriaensen wrote:

> On Wed, Mar 01, 2006 at 12:11:01PM -0500, Lee Revell wrote:
>> On Wed, 2006-03-01 at 02:01 -0800, Kjetil S. Matheussen wrote:
>>>
>>> Nope, defaults should do what most people would have done if there
>>> hadn't been a default.
>>
>> And if you have 10 outputs it's IMPOSSIBLE to tell which two "most
>> people" would connect to.
>
> Right. And what I'd do has probably no relation at all with what
> most people will do, and I see no reason why I should be bothered
> with their choices. And before someone remarks that I'd bother
> them with my choices, that is simply not true. Having a default
> of no connections is perfectly neutral.
>

Sorry, but I care more about the thousands of other users than of you.
I will make concern for you if you wish, but I won't make my software less
convenient to use, just because of your special setup.



-------------------------------------------------------
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
123456