Connect Policy

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

Connect Policy

Esben Stien
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?.

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

D. Michael McIntyre-3
On Tuesday 28 February 2006 1:11 pm, Esben Stien 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.

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

--
D. Michael 'Silvan' McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621

Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/


-------------------------------------------------------
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 Tue, 2006-02-28 at 21:49 -0500, D. Michael 'Silvan' McIntyre wrote:

> On Tuesday 28 February 2006 1:11 pm, Esben Stien 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.
>
> So what's evil about that?  What's the behind the scenes insider audio hacker
> objection to this perfectly user-friendly behavior?
>

The same reason ALSA mutes everything by default - because you might
damage your hearing otherwise.  And there's no sane default - connecting
to the first 2 ports is not necessarily correct.

I like the policy of no auto connection 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

Kjetil S. Matheussen
In reply to this post by Esben Stien

Esben Stien:
> 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 actually think that we should do the opposite. Put on the web page that
the recommended policy is to autoconnect, but keep an option not to
autoconnect.

Perhaps having a common environment variable called JACK_DONT_AUTOCONNECT
that can be set by people that for some reasons don't want their jack
programs to autoconnect.



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

Esben Stien
"Kjetil S. Matheussen" <[hidden email]> writes:

> Put on the web page that the recommended policy is to autoconnect

Scary;). Most JACK apps fortunately follow the policy of not touching
connection management.

> Perhaps having a common environment variable

I think this is a bad idea. Connecting anything should be left up to
the user and he may automate it if he wants. This can be done in a
general manner for all applications.

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

Kjetil S. Matheussen
On Wed, 1 Mar 2006, Esben Stien wrote:

> "Kjetil S. Matheussen" <[hidden email]> writes:
>
>> Put on the web page that the recommended policy is to autoconnect
>
> Scary;). Most JACK apps fortunately follow the policy of not touching
> connection management.
>
>> Perhaps having a common environment variable
>
> I think this is a bad idea. Connecting anything should be left up to
> the user and he may automate it if he wants.
>
>

Okey, but can you explain _why_ you think it should not autoconnect?

And here is my reason why it _should_ autoconnect:
*So you don't have to do it yourself*


> This can be done in a general manner for all applications.

Do you mean by jacklib somehow? Well, that sounds good, please
explain in more detail what you are thinking about...




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

Esben Stien
"Kjetil S. Matheussen" <[hidden email]> writes:

> can you explain _why_ you think it should not autoconnect?

As Lee put it so perfectly; there can never be a sensible default.

> my reason why it _should_ autoconnect: So you don't have to do it
> yourself

Well, you set it up once and then don't bother with it anymore.

> explain in more detail what you are thinking about...

jack.plumbing, f.ex, or LASH

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

Kjetil S. Matheussen
On Wed, 1 Mar 2006, Esben Stien wrote:

> "Kjetil S. Matheussen" <[hidden email]> writes:
>
>> can you explain _why_ you think it should not autoconnect?
>
> As Lee put it so perfectly; there can never be a sensible default.
>

Thats not a rational argument. Give me a real life situation.


>> my reason why it _should_ autoconnect: So you don't have to do it
>> yourself
>
> Well, you set it up once and then don't bother with it anymore.
>
What if you have to close your application? And what about sndplay,
for example. sndplay is used as the player in applications such as clm and
ceres3. Its a sample player that is often used to play short sounds. If it
hadn't autoconnected, chance is that the user would often spend more time
manually connecting the ports than the time it takes to play the sample,
and no sound would be heard.



>> explain in more detail what you are thinking about...
>
> jack.plumbing, f.ex, or LASH
>

Okey, but not everyone bothers to do that.



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

D. Michael McIntyre-3
In reply to this post by Kjetil S. Matheussen
On Tuesday 28 February 2006 11:38 pm, Kjetil S. Matheussen wrote:

> I actually think that we should do the opposite. Put on the web page that
> the recommended policy is to autoconnect, but keep an option not to
> autoconnect.
>
> Perhaps having a common environment variable called JACK_DONT_AUTOCONNECT
> that can be set by people that for some reasons don't want their jack
> programs to autoconnect.

I think having an option to disable the behavior should be obligatory.  I see
Lee's point about there being no sane default, but I maintain that the
defaults most apps use are good enough for most of the users most of the
time.  Most of the Rosegarden users in any event, who are, as a class,
probably only futzing around with JACK at all because we leave them no
alternative.  I know I'm certainly in that category myself.  I rue the day I
ever heard that four-letter word.  JACK has been my arch nemesis ever since
it came out.  All of this nonsense is WAY, WAY, WAY too complicated.

I and the users I speak of are not really the target demographic for JACK
anyway, I know.  I'm sure it's really exciting to people who get it, and I
know people who get it, who think JACK is the most awesome thing since
electric light.  For the rest of us, it's just an obstacle, and I think
people who use Rosegarden (as opposed to, say, Ardour) for audio work are
more likely than not to fall into this category.  I base that not only on my
own personal experiences as one of those people, but on years of helping new
users get over these substantial hurdles, and on spending months and months
working and reworking the "how to get sound working" part of my Rosegarden
book, which has still proven to be woefully inadequate.

As such, I advocate making the default connections configurable, but not doing
away with the concept entirely.  Indeed, I wish every app had default
connections, because I would then have less to explain to these poor souls
who entrust me to lead them through the mine field to a happier place.

--
D. Michael 'Silvan' McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621

Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/


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

Esben Stien
In reply to this post by Kjetil S. Matheussen
"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.

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

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

Kjetil S. Matheussen
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.


>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Connect Policy

Alfons Adriaensen-2
In reply to this post by Kjetil S. Matheussen
On Tue, Feb 28, 2006 at 08:38:12PM -0800, Kjetil S. Matheussen wrote:
 
> Esben Stien:
> > 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 actually think that we should do the opposite. Put on the web page that
> the recommended policy is to autoconnect, but keep an option not to
> autoconnect.

Autoconnect to what ? Simple enough maybe if you have just two ins
and to outs. And that may even be a very common situation. But that
is still no reason IMHO to make it the default. Defaults should
support the most general situtation, not to the simplest one.

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.

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.

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

Kjetil S. Matheussen
On Wed, 1 Mar 2006, Alfons Adriaensen wrote:

> On Tue, Feb 28, 2006 at 08:38:12PM -0800, Kjetil S. Matheussen wrote:
>
>> Esben Stien:
>>> 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 actually think that we should do the opposite. Put on the web page that
>> the recommended policy is to autoconnect, but keep an option not to
>> autoconnect.
>
> Autoconnect to what ? Simple enough maybe if you have just two ins
> and to outs. And that may even be a very common situation. But that
> is still no reason IMHO to make it the default. Defaults should
> support the most general situtation, not to the simplest one.
>

Nope, defaults should do what most people would have done if there
hadn't been a default.


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



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




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

Petter Sundlöf


Kjetil S. Matheussen wrote:

> On Wed, 1 Mar 2006, Alfons Adriaensen wrote:
>
>> On Tue, Feb 28, 2006 at 08:38:12PM -0800, Kjetil S. Matheussen wrote:
>>
>>> Esben Stien:
>>>
>>>> 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 actually think that we should do the opposite. Put on the web page
>>> that
>>> the recommended policy is to autoconnect, but keep an option not to
>>> autoconnect.
>>
>>
>> Autoconnect to what ? Simple enough maybe if you have just two ins
>> and to outs. And that may even be a very common situation. But that
>> is still no reason IMHO to make it the default. Defaults should
>> support the most general situtation, not to the simplest one.
>>
>
> Nope, defaults should do what most people would have done if there
> hadn't been a default.

 From a user's perspective: I would really like it if all JACK apps
automatically connected, to 0 & 1 out.


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

Alfons Adriaensen-2
In reply to this post by Kjetil S. Matheussen
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.


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

> 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 ? Anyway, any jack app that autoconnects itself by
default and can't be modified easily to not do so, will be not
have a long life on my system.


(*) Except maybe when running under KDE.

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

Paul Davis
In reply to this post by D. Michael McIntyre-3
On Wed, 2006-03-01 at 01:29 -0500, D. Michael 'Silvan' McIntyre wrote:

> time.  Most of the Rosegarden users in any event, who are, as a class,
> probably only futzing around with JACK at all because we leave them no
> alternative.  I know I'm certainly in that category myself.  I rue the day I
> ever heard that four-letter word.  JACK has been my arch nemesis ever since
> it came out.  All of this nonsense is WAY, WAY, WAY too complicated.
>
> I and the users I speak of are not really the target demographic for JACK
> anyway, I know.  I'm sure it's really exciting to people who get it, and I
> know people who get it, who think JACK is the most awesome thing since
> electric light.  For the rest of us, it's just an obstacle, and I think
> people who use Rosegarden (as opposed to, say, Ardour) for audio work are
> more likely than not to fall into this category.  I base that not only on my
> own personal experiences as one of those people, but on years of helping new
> users get over these substantial hurdles, and on spending months and months
> working and reworking the "how to get sound working" part of my Rosegarden
> book, which has still proven to be woefully inadequate.

coming soon, i hope: libjackdirect: JACK without a server. same API as
libjack, but talks directly to the hardware.

        LD_PRELOAD=/path/to/libjackdirect.so rosegarden

JACK is dead, long live JACK!

--p




-------------------------------------------------------
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 Kjetil S. Matheussen
On Wednesday 01 Mar 2006 04:38, Kjetil S. Matheussen wrote:
> Esben Stien:
> > 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 actually think that we should do the opposite. Put on the web page that
> the recommended policy is to autoconnect, but keep an option not to
> autoconnect.

Hey, I think we should do both.  Put on the web page that the recommended
policy is to autoconnect, and also that the recommended policy is not to
autoconnect.  That'll solve it.

The problem is that the most sensible default behaviour varies depending on
the application.  I'm sure 95% of Rosegarden users would agree that for
Rosegarden not to autoconnect at least its outputs would be bizarre and
hostile.  Same goes probably for Hydrogen, LMMS etc, as well as most
applications that have audio outputs but not inputs.  (In that I would
include Aeolus -- something that Fons must presumably disagree about.)  
Meanwhile an application like jack-rack is unlikely to even _want_ to
autoconnect, because it's routinely going to be used with inputs and outputs
other than the soundcard.

The situation at the moment is probably not far from ideal, at least from the
point of view of having each individual application do the thing that most of
its users would want.  But that means it's also inconsistent between
applications, and that in itself is annoying.  I don't imagine it's possible
to be both consistent and always right.

I guess the only vague consensus is that it would be nice if each application
had an option for it.  (And then we can argue about the default setting of
that.)  A global option wouldn't cut it, unless it was some sort of tristate
"Never connect / Do what you think is best / Always connect".


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

Mr Shunz
On 3/1/06, Petter Sundlöf <[hidden email]> wrote:

From a user's perspective: I would really like it if all JACK apps
automatically connected, to 0 & 1 out.

Personally, I like to play my mp3s (most of which are ripped from my LPs) through a stack
of LADSPA plugins to give the songs a bit of life, so I usually connect player to jack-rack
which in turn connects to card outputs.

From my point of view it's a poblem of clients, which should always have an option to save
connection preferences (as in ardour). And, a bit OT, all clients should not fail to load
when the jack server isn't up, but should provide a connect/reconnect option (again, as in
ardour...)
Reply | Threaded
Open this post in threaded view
|

Re: Connect Policy

cannam
In reply to this post by Alfons Adriaensen-2
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?


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

D. Michael McIntyre-3
In reply to this post by Paul Davis
On Wednesday 01 March 2006 8:02 am, Paul Davis wrote:

> coming soon, i hope: libjackdirect: JACK without a server. same API as
> libjack, but talks directly to the hardware.
>
> LD_PRELOAD=/path/to/libjackdirect.so rosegarden
>
> JACK is dead, long live JACK!

Interesting.

What's more interesting to me is that in spite of everything I just said, I
don't find that notion as immediately appealing as I would have thought I
would.  It seems like such a notion would get the audio in Rosegarden working
quickly, but at the expense of interoperability with other applications.

Maybe this means I'm starting to get JACK?

Hrm.

--
D. Michael 'Silvan' McIntyre  ----   Silvan <[hidden email]>
Linux fanatic, and certified Geek;  registered Linux user #243621

Author of Rosegarden Companion http://rosegarden.sourceforge.net/tutorial/


-------------------------------------------------------
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
1234 ... 6