Connect Policy

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

Re: Connect Policy

Rui Nuno Capela
>
> 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):
>

Haham... QjackCtl has a configurable patchbay for ages. Just in case you
have missed it, it is a place where you can setup all your auto-connection
paraphernalia, in the way you really want for your soft-studio, regarding
all JACK _and_ ALSA Sequencer connectivity and, best of all, automagically
persistent along power-cycles. You have to be running QjackCtl though ;)

Problem is, its been very poorly documented, if at all :/ Mea culpa. Does
someone have a wiki around for me to put the barebones of it? ;)

Cheers.
--
rncbc aka Rui Nuno Capela
[hidden email]

P.S. Incidentally, it has come recently to my attention that there's a
QjackCtl Patchbay page dangling on http://ubuntostudio.com . Dana?




-------------------------------------------------------
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
On Thursday 02 Mar 2006 09:35, Rui Nuno Capela wrote:
> > 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):
>
> Haham... QjackCtl has a configurable patchbay for ages.

Yes, and it's very nice, but it doesn't really have anything to do with
_default_ connections.  After all, it would be even nicer if an unknown
application did what you wanted the very first time you ran it.

Some documentation would be great though, don't let me talk you out of that!


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

Fons Adriaensen
In reply to this post by John Rigg-3
On Thu, Mar 02, 2006 at 09:06:57AM +0000, 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.

Yes. And this reminds me once again that there are quite few Linux
audio apps that even come close to professional standards.
 
> 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.

Yep. When you are recording and the musicians alone cost 20 k$ per
day, or when you're driving a 50 kW PA rig, you don't want some
sorts of 'user friendliness'. You want to be 100% sure your tools do
exactly what you want and nothing behind your back. All assumptions
that maybe make sense to an amateur break down in such conditions.

When evaluating software for professional use, one of the things
I try to grasp is the developer's mindset. It's quite evident in
most cases. When an app has numerous options relating to its looks
(skins and themes), when it uses acres of screen estate to show
fancy graphics but doesn't have a single control that's clearly
and correctly calibrated, or when elementary things just can't
be controlled or monitored at all, that's a giveaway.

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

Michael Schnake
In reply to this post by cannam
Hi all,

in my opinion both camps have valid arguments.

For new users (and the devs of the applications they use) the "No sound after
starting <someApp>" experience is bothersome.

And educating those class of users about the "inner workings" probably does
not work well most of the time, too (albeit by far the best option), because
they will simply stop using <someApp> or start complaining to the devs or
yell "Linux is not yet ready for the desktop" or ..., but refuse to learn
even the very basics first. That's sad (in my opinion), but it is the way it
is nowadays.

For those class of users "autoconnect" is good (and I really do care more
about the poor devs being spammed by those users than those users
themself ;-). Ah, and it simply would *not* be fair (nor clever, nor good for
any user at all) to tell those devs "go and use ALSA then" just because their
app happen to have a mostly "autoconnect-type" user base.

On the other hand, if there is potential to damage external gear, or having an
forgotten mail client telling "You have new mail" over the PA live, or
wanting everything to go through some effect rack first, or just make
absolutely sure that you are in total control over your sound setup,
"autoconnect" is evil.

To serve both I like the idea of having the Jack API provide something like
the already mentioned "jack_autoconnect_ports(...)" method, together with a
jackd flag to globally enable/disable autoconnect.

If disabled, the function simply does nothing, else it autoconnects to pysical
out ports. At some time the actual decision on how to autoconnect could even
be delegated internally to some registered "connection policy manager". And
all client applications would be required to use that function instead of
doing any autoconnect-voodoo themself.

That way I could be sure that I am in control. Oh, and the default jackd
setting for autoconnect should be "enabled" IMHO. That way for the more
"innocent" class of users it just works, and the "pro's" should have no
problem starting their jackd instance with one additional "no-autoconnect"
flag (because *they are* supposed to know what they do ;-)

MS


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

If I can expand on my earlier thesis a bit here.

I work a video editor, which of course involves a certain amount of audio. I
have used desktop computer systems in broadcast playout and live PA
systems - the only thing you have to watch in Windows is that the "No
Sounds" scheme doesn't actually mean silence! With more and more Windows
apps becoming savvy to the selection of multiple sound devices, it's just
another thing that Linux is seen to need to "catch up" on. Couldn't agree
more with the guy who said that it's exactly this kind of thing which puts
people like me off.

I think the real issue here is the common assumption that "professional" and
"software engineer" are synonymous; it is difficult to use most Linux
applications currently unless you have a college-level understanding of C
code and computer systems engineering, which means that it can never really
be applied to media production work. Of course I'm making the assumption
that this is not how most of us would like it to be - and it certainly isn't
how I'd like it to be, exactly because of the frustrations of trying to do
professional work on a commercial OS that looks like it was designed using
Lego bricks and big, child-safe crayons. Others may prefer to keep things
like Linux elitist; you're free to disagree, of course.

In short - sensible default behaviour is -more- sensible than doing nothing
because you won't always be right. I'd have thought that was self-evident.

Regards,

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

R Parker
In reply to this post by Kjetil S. Matheussen


--- "Kjetil S. Matheussen" <[hidden email]>
wrote:

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

Having control is a good thing.

 BTW, ardour
> autoconnects by default.

Ardour does nothing by default. The user must create a
session and define the sources, routes and
"connections".

Compare Ardour to mplayerplug-in[1]:
*Ardour is configured to make appropriate connections
*mplayerplug-in cannot be configured it connects to
playback_0,1

The problem is playback_0,1 are used by every sound
engineer in the world for kick and snare. Unless that
engineer doesn't care about working with other people
or doesn't have enough experience. When the Ardour
user accesses a webpage with streaming audio and
mplayerplug-in connects to playback_0,1 we have a
stereo stream running through equalization,
compression, aux buses, etc.

The lack of control is an unfriendly design.
Configuring qjackctl to connect mplayerplug-in to
playback_25,26 doesn't disconnect its playback_0,1
routes.

The correct thing is for mplayerplug-in to be
configurable so that it can safely autoconnect because
it would absolutely suck to manually connect it. I am
an audio pro and recently have done some website
development so I'm pretty aware of the need for
control. I make my living being a control phreak who
prevents every concievable problem from happening and
makes everything work very quickly and smoothly. It's
all about control. All of us want control. Control is
beautiful and being in my mid 40s i'm losing control
of my bowels and I must go now.

NOTES:
1. I recently installed mplayerplug-in and didn't
immediately see a way to reconfigure its default
playback_0,1. I'm assuming it can't be configured but
it's very possible that I'm wrong. In that event I'm
only using it as an example which should remain
perfectly usable.

ron

 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
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 


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

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.

Nonsense. What's the point of using JACK if you aren't going to route
the audio?

However, your comment is useful, insofar as it demonstrates that a
recommended policy simply won't suffice. There /will/ be application
developers who believe that they understand the users' needs better
than the users do, so there needs to be some way to prevent
autoconnection which doesn't rely upon individual applications.

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

Glynn Clements
In reply to this post by Michael Schnake

Michael Schnake wrote:

> To serve both I like the idea of having the Jack API provide something like
> the already mentioned "jack_autoconnect_ports(...)" method, together with a
> jackd flag to globally enable/disable autoconnect.
>
> If disabled, the function simply does nothing, else it autoconnects to pysical
> out ports.

Physical outputs are almost never the right choice. If there are any
other outputs available, two of them will probably be the "processor"
(mixer, effects rack etc) to which "sources" are supposed to be
connected.

The one application which should connect to the physical ports
probably isn't going to be a simplistic end-user application (e.g. MP3
player) but something like JACK-rack.

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

Glynn Clements
In reply to this post by John Rigg-3

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

Me too. Actually somewhere between 50%-90% of this list's subscribers
are probaly in that .001%.

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

Yep. What's next? Drop Linux support because most people use Windows?

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

SciFi-3
In reply to this post by Esben Stien


On Thu, 02 Mar 2006 11:31:14 -0600 Glynn Clements
<[hidden email]> wrote:

> 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.
>
> Nonsense. What's the point of using JACK if you
> aren't going to route the audio?

I guess I'll chime-in again, in case my 2-copper-coins
weren't noticed the other day.  ;)

I want to route the first two physical output ports into
DarkIce by default.  Fortunately, DarkIce has just such
an option, so long as the multitude of MacOSX CoreAudio
configuration apps (including third-party in the case of
non-Apple devices & cards etc.) are in-&-of-themselves
set-up properly.  [Too bad we can't have /dev/sound type
devices (which I thought OpenAL was suppose to provide)
then we would be more *ix-like.]

Another point of using JackIt in my case:  MacOSX does
not have that many free open-source projects available
for it that actually work(!).  There are a few commercial
apps that integrate into CoreAudio much better, because
they use the OSX-specific APIs directly without worry to
be cross-platform, and most Mac users do expect a GUI.  I
believe JackOSX and JackdMP can provide such GUIs for
those users, while us OSX CLI folk can be happy with the
original JackIt project (and help with the latest code as
well).  Of course, I presume the GUI "wrapper" code would
probably be a good place to put the logic for choosing
some form of "default" on behalf of the average
non-technical Mac user, which is a whole 'nuther
discussion...

But getting back to my main point:  I do not want
DarkIce's device=jack_auto function to be interfered
with.  ;)





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



-------------------------------------------------------
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 Thu, 2006-03-02 at 12:33 -0600, [hidden email] wrote:
> [Too bad we can't have /dev/sound type
> devices (which I thought OpenAL was suppose to provide)
> then we would be more *ix-like.]

No!!!  That's  a TERRIBLE interface.  We have been trying to break Unix
people of that habit for years!

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 Glynn Clements
On Thu, 2 Mar 2006, Glynn Clements wrote:

>
> 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.
>
> Nonsense. What's the point of using JACK if you aren't going to route
> the audio?
>
> However, your comment is useful, insofar as it demonstrates that a
> recommended policy simply won't suffice. There /will/ be application
> developers who believe that they understand the users' needs better
> than the users do, so there needs to be some way to prevent
> autoconnection which doesn't rely upon individual applications.
>

Yeah, theres different philosopies of jack usage and generally
misunderstandings going on here. Jack is a wonderful system compaired
to all other alternatives, and although its features shouldn't be
compromised to suit more users, I think its a bad idea to ignore
other kinds of uses than sound engineering stuff, which I have a feeling
is the case here.

What I use jack for is mostly SND, CLM, PD, aqualung and xmms.
This is not that uncommon software, its also software that is natural
to work with jack (callback, routing), and its definitely programs that
should autoconnect by default. I agree that autoconnecting for example
freqtweak or jack-rack to both inputs and outputs could be very dangerous
because of feedback, and you often don't want to connect hardware inputs
and outputs to software like freqtweak or jack-rack anyway.

However, and this is the point, saying, like some people here, that _all_
programs should _never_, autoconnect by default, is just ignorant.



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

Glynn Clements:

>>>>> 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.
>
> Me too. Actually somewhere between 50%-90% of this list's subscribers
> are probaly in that .001%.
>

Are you saying that 50%-90% of this list have their stereo-monitors
connected to something else than the first two physical jack output
boards? Wake up! jack is a far more general system than an
emulation of an old-fashioned studio patch-bay.




-------------------------------------------------------
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
In reply to this post by R Parker
On Thu, 2 Mar 2006, R Parker wrote:

>>
>>
>> Nah, that you "pros" don't realize that
>> autoconnecting by default
>> generally is a good thing definitely makes me
>> wonder.
>
> Having control is a good thing.
>
> BTW, ardour
>> autoconnects by default.
>
> Ardour does nothing by default. The user must create a
> session and define the sources, routes and
> "connections".
>

Not really. Ardour autoconnects the auditioner ports, the
click port and the master out ports to my alsa_pcm ports when you create
a new session. And it does this by default.



> Compare Ardour to mplayerplug-in[1]:
> *Ardour is configured to make appropriate connections
> *mplayerplug-in cannot be configured it connects to
> playback_0,1
>

Yeah, thats bad. But thats what most people expect mplayer to do. Guess
its possible to write a program that autodisconnects, as a workaround.



<snip>

Anyway, thanks for your insightful comments. Its a bit of the side of
being discussed here, but I guess this is the world you sound technician
swim around in.
(Well, I have been a sound technician too, though, but I do other things
as well.)



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

Fons Adriaensen
In reply to this post by Kjetil S. Matheussen
On Thu, Mar 02, 2006 at 03:14:45PM -0800, Kjetil S. Matheussen wrote:

> Are you saying that 50%-90% of this list have their stereo-monitors
> connected to something else than the first two physical jack output
> boards?

> Wake up! jack is a far more general system than an
> emulation of an old-fashioned studio patch-bay.

I completely fail to see how the second sentence is relevant in
relation to the first.

In my case, the first two jack ports are indeed *not* connected
to a monitoring system.

The first 8 outputs go to the 'tape return' inputs of a mixer.
In mixdown mode these are just 8 line inputs, to be used for
whatever purpose I want. The first 8 inputs are patched from
either one of the 8 groups or 8 auxiliary sends of the same
mixer.

Outputs 9 and 10 (spdif) either go to the main monitoring
amp or can be converted to analog and sent to a stereo line
input and a 2-track monitor selection on the mixer. They are
the only ones ever used directly for monitoring.

So except for 9 and 10 its impossible to predict what any
channel will be used for.

I don't think this is an atypical setup for users of
multichannel cards.

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

Kjetil S. Matheussen
On Fri, 3 Mar 2006, fons adriaensen wrote:

> On Thu, Mar 02, 2006 at 03:14:45PM -0800, Kjetil S. Matheussen wrote:
>
>> Are you saying that 50%-90% of this list have their stereo-monitors
>> connected to something else than the first two physical jack output
>> boards?
>
>> Wake up! jack is a far more general system than an
>> emulation of an old-fashioned studio patch-bay.
>
> I completely fail to see how the second sentence is relevant in
> relation to the first.
>

Well, yes, good point.
I ment that jack is used for other things than emulating an
analog studio.



> In my case, the first two jack ports are indeed *not* connected
> to a monitoring system.
>
> The first 8 outputs go to the 'tape return' inputs of a mixer.
> In mixdown mode these are just 8 line inputs, to be used for
> whatever purpose I want. The first 8 inputs are patched from
> either one of the 8 groups or 8 auxiliary sends of the same
> mixer.
>
> Outputs 9 and 10 (spdif) either go to the main monitoring
> amp or can be converted to analog and sent to a stereo line
> input and a 2-track monitor selection on the mixer. They are
> the only ones ever used directly for monitoring.
>
> So except for 9 and 10 its impossible to predict what any
> channel will be used for.
>
> I don't think this is an atypical setup for users of
> multichannel cards.
>

Maybe not. But it has to be an atypical setup for linux audio users in
general, and also on this list.



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

SciFi-3
In reply to this post by Esben Stien


On Thu, 02 Mar 2006 12:45:29 -0600 Lee Revell <rlrevell@joe-
job.com> wrote:
>On Thu, 2006-03-02 at 12:33 -0600, [hidden email] wrote:
>> [Too bad we can't have /dev/sound type
>> devices (which I thought OpenAL was suppose to provide)
>> then we would be more *ix-like.]
>
>No!!!  That's  a TERRIBLE interface.  We have been trying to break
>Unix people of that habit for years!
>
>Lee

Oh I know ... all I meant to say is it probably would be easier to
port  such apps to OSX in their present forms.

What then would be a good "audio device" interface to use?  I
(sadly) don't think Apple will ever open-source CoreAudio/CoreMIDI
to the point it could be an official cross-platform *BSD subsystem.





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



-------------------------------------------------------
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 Thu, 2006-03-02 at 19:14 -0600, [hidden email] wrote:

>
> On Thu, 02 Mar 2006 12:45:29 -0600 Lee Revell <rlrevell@joe-
> job.com> wrote:
> >On Thu, 2006-03-02 at 12:33 -0600, [hidden email] wrote:
> >> [Too bad we can't have /dev/sound type
> >> devices (which I thought OpenAL was suppose to provide)
> >> then we would be more *ix-like.]
> >
> >No!!!  That's  a TERRIBLE interface.  We have been trying to break
> >Unix people of that habit for years!
> >
> >Lee
>
> Oh I know ... all I meant to say is it probably would be easier to
> port  such apps to OSX in their present forms.
>
> What then would be a good "audio device" interface to use?  I
> (sadly) don't think Apple will ever open-source CoreAudio/CoreMIDI
> to the point it could be an official cross-platform *BSD subsystem.

I think ALSA is good enough - the problems with it are well understood
at this point, I'd expect ALSA 2.x to address them.  It does what it was
designed to do (provide a complete audio device HAL for higher level
APIs like JACK and PortAudio to be built on).

Any app that uses a callback based model should be easily portable to
another such API.  After all the ALSA code in Juce is less than 1000
lines.

Lee



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

Re: Re: Connect Policy

SciFi-3
In reply to this post by Esben Stien


On Thu, 02 Mar 2006 17:14:45 -0600 "Kjetil S. Matheussen"
<[hidden email]> wrote:
>Glynn Clements:
>>>>>> 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.
>>
>> Me too. Actually somewhere between 50%-90% of this list's
subscribers
>> are probaly in that .001%.
>>
>
>Are you saying that 50%-90% of this list have their stereo-
monitors
>connected to something else than the first two physical jack
output
>boards?

For our KOKF netcasts, I monitor the localhost:port netcast feed
for quality (and to be sure it's working at least that far out!)
since we are also testing Altivec patches on LAME-CVS etc.  JackIt
is not involved with this playback, since iTunes, MPlayer, VLC, et
al. can drive CoreAudio directly (and be routed by using other
control panels at that level).

If I want to monitor the sound card input directly, the M-Audio
Control Panel has its own patch facilities so I could parallel hook
the analogue inputs to the SPDIF outputs with absolute lowest
latency etc. (it is probably a chip-level connection directly on
the board, something JackIt probably cannot do itself).

There are ways to trouble-shoot things, of course, which involves
hooking various levels of all this goop on OSX to see where the
failure is.

>Wake up! jack is a far more general system than an
>emulation of an old-fashioned studio patch-bay.

Yes it is.  :)

I only want to make sure no one disturbes DarkIce's
device=jack_auto function.





Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485



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

Re: Re: Connect Policy

Lee Revell
On Thu, 2006-03-02 at 19:38 -0600, [hidden email] wrote:
> Yes it is.  :)
>
> I only want to make sure no one disturbes DarkIce's
> device=jack_auto function.

No one objects to apps having the option to auto-connect, as long as
it's configurable and can be disabled, which I think puts DarkIce in the
clear...

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
123456