Connect Policy

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

Re: Connect Policy

cannam

Y'know, it might be nice to have some sort of global hint about what an
application should do with its inputs and outputs by default.

For example, something that tells subscribing applications "I generally
want the default audio outputs connected to [soundcard outputs 1+2]
[SPDIF outputs] [etc]", or "never connect anything to anything, ever".

A connection manager can't do this for you, because it doesn't know the
purpose of the particular ports in an application (e.g. which are the
default listening outs and which are specialised outputs for effects or
other uses).

I imagine the potential rules are complicated enough to make this a
usability nightmare rather than enhancement, but maybe it's worth
pondering.


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

Phil Rhodes
In reply to this post by Kjetil S. Matheussen
Hi,

I have to admit that I've only followed this discussion vaguely, so I'm only
just willing to stick my oar in.

However, it strikes me as a generally sensible principle of software
development that when there are legitimately diverse opinions as to the
proper behaviour, and that behaviour has real-world effects on more than a
few percent of users, then that behaviour should be optional.

Further, if there's still controversy over what the default behaviour should
be, especially in situations where any sensible option could cause
real-world problems for more than a few percent of users in either case,
environment variables are an obvious answer; but it's sensible to provide a
default that will work for a large proportion of users (even if not a
majority.)

I don't mean to come off as preachy, but as mainly a Windows user who'd love
to move to Linux for more things, I think there's a few basic tests that
could solve a lot of usability issues in situations just such as the one
you're discussing.

- Does this problem have noticeable, real-world effects? Am I being
technically pedantic? (It is better that the thing work than save an
infinitesimal amount of CPU time or have prettier code. I am an engineer too
and I appreciate the need for technical excellence, but while I love you all
and respect the work of the opensource community, it's hard to deny that
opensource authors have an alarming tendency to tie themselves up in
minutiae that no sane user would ever be aware of.)
- Does this problem have real-world, non-pedantic effects on more than a few
percent of users? Does this only affect the application I'm particularly
interested in? (Mainly a default-determining test, but really what I'm
trying to say here is don't spend an enormous amount of effort trying to
avoid rare issues which could easily be optioned out, even if the rare issue
is technically interesting. Users in rare situations will RTFM. Users in
everyday situations might not.)
- Have I documented the problem fully? (One software project I was involved
with solved an important problem with an option called, in
essence, --enable-foo, which was documented as "Enables foo processing",
where "foo" was a term known only to the dev team.)

Enabling sensible defaults is one of the issues that really puts Windows
users off Linux. I mention this only because that is my perspective; I'm not
trying to tell you to turn JACK and ALSA into the audio component of
directX, and neither would I ever want to see Firefox with "download and run
activeX plugins automatically" as the default, of course. If the three tests
above tire you, I think my attitude to this can be summed up as "things
should usually work."

Submitted in a "back to basics" sort of mindset,

Phil



-------------------------------------------------------
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 cannam
On Wed, 2006-03-01 at 20:42 +0000, Chris Cannam wrote:
> Y'know, it might be nice to have some sort of global hint about what an
> application should do with its inputs and outputs by default.
>
> For example, something that tells subscribing applications "I generally
> want the default audio outputs connected to [soundcard outputs 1+2]
> [SPDIF outputs] [etc]", or "never connect anything to anything, ever".

something along the lines of JACK_DEFAULT_IO={physical|physicalStartAtN|
relax|list_of_ports,more_ports,and_more_ports} ?




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

rj (Bugzilla)
In reply to this post by Petter Sundlöf
Hi,

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

To follow that thought into the land of things that probably won't happen
because of a probable interface freeze...
I don't know where it came up but once I was almost convinced that it was
possible to tell Jack which ports are the default ports. In which case you
would programmatically ask for getJackDefaultOutput(s).
If you really don't want any output you would point them to logical ports or
not define them at all.

/Robert

--
http://spamatica.se/musicsite/


-------------------------------------------------------
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 Paul Davis
On Wednesday 01 Mar 2006 20:58, Paul Davis wrote:
> On Wed, 2006-03-01 at 20:42 +0000, Chris Cannam wrote:
> > For example, something that tells subscribing applications "I
> > generally want the default audio outputs connected to [soundcard
> > outputs 1+2] [SPDIF outputs] [etc]", or "never connect anything to
> > anything, ever".
>
> something along the lines of
> JACK_DEFAULT_IO={physical|physicalStartAtN|
> relax|list_of_ports,more_ports,and_more_ports} ?

Ye-ee-e-ee-esss... I can't help thinking that the set of things people
will "normally want" is probably rather larger though.  For example,
different policies for input and output ports, or different policies
for apps that "play stuff" and apps that "process stuff".


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

melanie-36
In reply to this post by cannam
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.

Therefore, the only apps that would _want_ to autoconnect are apps that
provide stereo outputs.
It is therefore safe to assume that it would be sufficient to provide
default stereo outputs.

I propose to create two "pseudo ports", named, for example, "out_left"
and "out_right", and corresponding input ports.
These should not be real jack ports, rather they should be names that
are accepted as aliases by the cnnecting functions.

An application which wants to autoconnect will just simply connect to
these aliases, which map to the first two physical ports, unless the
server config says something different.

There, other physical ports, logical ports or "none" could be defined as
the target of these aliases.

Melanie


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

Dave Robillard
In reply to this post by D. Michael McIntyre-3
On Tue, 2006-28-02 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?

Apps should not connect to interface ports _by default_ (for numerous
reasons).  There needs to at least be some way of disabling that
behaviour, or the app is broken and needs fixing.

Providing the option is a good idea though.

-DR-



-------------------------------------------------------
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 Kjetil S. Matheussen
On Wed, Mar 01, 2006 at 12:17:28PM -0800, Kjetil S. Matheussen wrote:

> I can't believe this argumentation. 99.999% of all users

which means that for every one I find you have to find 99999

> will of course

of course ?? Please explain.

> use the two first physical output ports.

Users who systematically connect everything to the first two
ports don't need JACK at all. It was designed to provide
completely free and flexible routing.

I'll conclude this silly argument with a philosophical
observation. Even if 99.999% of all humans would be idiots,
that would still not make me treat every new one I meet by
default as an idiot.

--
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, fons adriaensen wrote:

> On Wed, Mar 01, 2006 at 12:17:28PM -0800, Kjetil S. Matheussen wrote:
>
>> I can't believe this argumentation. 99.999% of all users
>
> which means that for every one I find you have to find 99999
>

Well, maybe I'm exaggerating, maybe not. Guess I am though. :-)


>> will of course
>
> of course ?? Please explain.
>

They want sound. Therefore "of course". Sorry for generalizing though, its
just totally obvious to me, so therefore I do.


>> use the two first physical output ports.
>
> Users who systematically connect everything to the first two
> ports don't need JACK at all. It was designed to provide
> completely free and flexible routing.
>

Jack has other advances as well, like working very well and running more
than one program at once. So users definitely need jack. dmix is not
always an alternative.


> I'll conclude this silly argument with a philosophical
> observation. Even if 99.999% of all humans would be idiots,
> that would still not make me treat every new one I meet by
> default as an idiot.
>

Running out of arguments?



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

John Rigg-3
In reply to this post by Kjetil S. Matheussen
On Wed, Mar 01, 2006 at 12:17:28PM -0800, Kjetil S. Matheussen wrote:

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

I guess I'm in the other .001% along with Fons. I and most other
sound engineers I know use whichever inputs or outputs are appropriate
for a particular job. JACK was intended for pro users, and I would guess
that most of these would have similar requirements. If `ordinary'
users want to use JACK there's nothing wrong with that, but I'd be a
little concerned if it became less usable for those of us who do this to
earn a living.

John


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

Fernando Lopez-Lezcano
In reply to this post by Lee Revell
On Wed, 2006-03-01 at 12:08 -0500, Lee Revell wrote:

> 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 because useful ports are not restricted to ports that go to
soundcard outputs. I may want my apps to always autoconnect to jack-rack
because that's running a reverb I like.

-- Fernando




-------------------------------------------------------
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 Kjetil S. Matheussen
On Wed, Mar 01, 2006 at 02:46:33PM -0800, Kjetil Svalastog Matheussen wrote:
 
> Running out of arguments?

Taking those words literally, yes. In the sense that I'm in need
of new ones, no. The ones I gave are still perfectly valid, and
sufficient. There is just no point in repeating them.


--
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 Fernando Lopez-Lezcano
On Wed, Mar 01, 2006 at 03:29:42PM -0800, Fernando Lopez-Lezcano wrote:

> And because useful ports are not restricted to ports that go to
> soundcard outputs. I may want my apps to always autoconnect to jack-rack
> because that's running a reverb I like.

Indeed. Even if I want nothing more than just to listen to audio files,
I may want to connect any player I use to

- a room equaliser
- an impulse convolver
- a crossover filter
- a limiter
- ...

or any combination thereof, rather than straight to the physical
outputs. Simple fact is that in a JACK system there is nothing
special about the physical ports.

If an autoconnect feature has to be useful, it should at least be
configurable by the user. The 'none' option comes for free in that
case.


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

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

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

I was thinking that just now too.

I don't have any code work done on that yet, but still very much intend to do
so.  I've taken note of this suggestion.

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

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

> On Wed, Mar 01, 2006 at 02:46:33PM -0800, Kjetil Svalastog Matheussen wrote:
>
>> Running out of arguments?
>
> Taking those words literally, yes. In the sense that I'm in need
> of new ones, no. The ones I gave are still perfectly valid, and
> sufficient. There is just no point in repeating them.
>

Well, at least I do acknowledge your need. I guess this functionality
is something that should go into the jack API. There are two reasons
for that, the first one is your arguments, and the other is that its
quite complicated to do autoconnecting.

A function like the following would solve all our problems:

"int jack_autoconnect_ports(jack_ports_t *ports,int num_ports);"

And a function like this to control the behaviour of autoconnecting
(can be used from qjackctl):

"int jack_set_client_to_autoconnect_to(const char *client_name);"

Well, something like that at least.





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

Dave Robillard
In reply to this post by Kjetil S. Matheussen
On Tue, 2006-28-02 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.

Given that the entire purpose of jack is the ability to route audio
through multiple applications, a lot of users.

If everyone just connected every single app up to the audio outputs,
there wouldn't be a need for jack in the first place ;)

I have never once hooked hydrogen up to the interface ports
intentionally...

Either way, I don't think the default is really that important (who
doesn't change at least one setting on an app they use?), but the option
MUST be there to disable autoconnect.

-DR-



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

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.

Rant rant rant:
I'm scared by the hostility shown on this list towards
userfriendlyness. Theres no contradiction between giving configurability
and userfriendlyness. No wonder so many windows/mac users are frustrated
when using linux. I just thought it was because many programs are
immature, but its obviously also because many developers are out of
contact with reality. Well, things are getting better and better though.



> Therefore, the only apps that would _want_ to autoconnect are apps that
> provide stereo outputs.

No no no.


> It is therefore safe to assume that it would be sufficient to provide
> default stereo outputs.
>

Nope.


> I propose to create two "pseudo ports", named, for example, "out_left"
> and "out_right", and corresponding input ports.
> These should not be real jack ports, rather they should be names that
> are accepted as aliases by the cnnecting functions.
>
> An application which wants to autoconnect will just simply connect to
> these aliases, which map to the first two physical ports, unless the
> server config says something different.
>
> There, other physical ports, logical ports or "none" could be defined as
> the target of these aliases.
>

I like the idea, except thats its limited to stereo, and that its too
complicated.






-------------------------------------------------------
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
> No wonder so many windows/mac users are frustrated when using linux. I just
> thought it was because many programs are immature, but its obviously also
> because many developers are out of contact with reality.

Sorry about that, let me change that last line to:
"because many developers don't care enough about making the programs work
as simple as possible for the users without sacrificing power of the
program."

I really didn't mean that anyone had lost contact with reality. Sorry
again.




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

John Rigg-3
In reply to this post by Kjetil S. Matheussen
On Wed, Mar 01, 2006 at 07:48:23PM -0800, Kjetil S. Matheussen wrote:
> I'm scared by the hostility shown on this list towards
> userfriendlyness. Theres no contradiction between giving configurability
> and userfriendlyness. No wonder so many windows/mac users are frustrated
> when using linux. I just thought it was because many programs are
> immature, but its obviously also because many developers are out of
> contact with reality. Well, things are getting better and better though.

The trouble is that one user's idea of `user-friendliness' is another
user's showstopper. A lot of supposedly professional sound equipment
is virtually unusable by pro users because the manufacturers have put
in `user-friendly' features for amateurs and hobbyists, who have
different requirements. I've seen online articles purporting to be
about professional sound recording where the author has dismissed Ardour
as too difficult to use, and advocated using apps like Audacity
instead; but for pro work Ardour is so easy it's a no brainer and the
hobby level apps just don't do the job, period.

If you want a dose of reality, try recording a commercial album or
mixing a live gig on equipment you've never seen before. You'll soon
learn what `user-friendliness' means in this context. JACK works
as well as it does because the developers are well aware of the
realities of pro sound work.

John


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

Kjetil S. Matheussen
On Thu, 2 Mar 2006, John Rigg wrote:

> On Wed, Mar 01, 2006 at 07:48:23PM -0800, Kjetil S. Matheussen wrote:
>> I'm scared by the hostility shown on this list towards
>> userfriendlyness. Theres no contradiction between giving configurability
>> and userfriendlyness. No wonder so many windows/mac users are frustrated
>> when using linux. I just thought it was because many programs are
>> immature, but its obviously also because many developers are out of
>> contact with reality. Well, things are getting better and better though.
>
> The trouble is that one user's idea of `user-friendliness' is another
> user's showstopper. A lot of supposedly professional sound equipment
> is virtually unusable by pro users because the manufacturers have put
> in `user-friendly' features for amateurs and hobbyists, who have
> different requirements. I've seen online articles purporting to be
> about professional sound recording where the author has dismissed Ardour
> as too difficult to use, and advocated using apps like Audacity
> instead; but for pro work Ardour is so easy it's a no brainer and the
> hobby level apps just don't do the job, period.
>
> If you want a dose of reality, try recording a commercial album or
> mixing a live gig on equipment you've never seen before. You'll soon
> learn what `user-friendliness' means in this context. JACK works
> as well as it does because the developers are well aware of the
> realities of pro sound work.
>


Nah, that you "pros" don't realize that autoconnecting by default
generally is a good thing definitely makes me wonder. BTW, ardour
autoconnects by default. I don't think we disagree _that_ much.




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