Jack and pro-audio

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

Jack and pro-audio

Ralf Mardorf
Sorry, quasi a reply to something I won't reply anymore.

Two festive two cents

- would it be pro-audio to have a selection of different versions of
Jack to fit to different session handlers?

- would it be pro-audio to run 50 applications for one audio production?

Here on planet earth I guess we should be able to go to a studio and to
be able to work, what ever DAW they use, a proprietary or a FLOSS DAW.
There's nothing that needs to be handled for pro-audio, that could not
easily be handled by a script and a AIO app such as Ardour.

If people really should need a special version of Jack for a session
handler, than please agree upon one session handler, so that there
simply just will be Jack3 and not Jack3 to Jack2001.

Sorry, 50 apps for an audio production sounds like hobby-audio and not
pro-audio. This should be no flame! But I really wonder if rt audio
Linux shouldn't be based on realistic usage by a common denominator.
Theoretical the usage of 50 apps could be pro-audio too, but I suspect
this would be an exception.

Please keep in mind that Linux should provide pro-audio too and that
some ideas simply are ideas from people who don't work in audio and
video business. Their/your ideas aren't bad, but they are far away from
today's professional audio and video engineering.

I'm not addicted to proprietary apps, it's the other way around. I 'm
more conform with ideas similar to Bob Katz and Linux audio, so 50 apps.
resp. handling tons of apps is useless for many audio engineers, but
having tons of sound servers with tasks that don't belong to sound
servers are a PITA.

Please, it's Christmas, reconsider all claims regarding to what's needed
for pro-audio.

I'm surrounded by 19" audio devices, guitars and synth and a mixing
console, enough to make a professional analog recording. But this are
less than 50 devices and I don't need a robot to connect those devices.
We don't need a virtual robot for tons of virtual Linux devices too,
this is not pro-audio reality.

- Ralf


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and pro-audio

Jörn Nettingsmeier-5
On 12/26/2011 02:55 PM, Ralf Madorf wrote:

> - would it be pro-audio to run 50 applications for one audio production?

who knows?

earlier today, i ran a session with two instances of an ambisonic
decoder, two instances of a reverberator, an analyser, a convolver, two
external signal processors, a jack-enabled video viewer, a midi bridge,
a daw, and two jack recording tools, in a jack session with over 1000
connected ports to the master bus alone. all those tools were
mission-critical.
i like to think it was a professional production. at least if
"professional" == "making a substantial contribution to paying the rent".

morale: i don't know, you don't know.
what makes jack great is it makes no assumptions on what people might
end up doing with it, it just provides clean plumbing, as best as we know.

i want a jack that scales to high heaven, can pipe stuff over the
network if necessary, and doesn't get in the way. i want to use the
greatest tools written by great programmers, despite the fact they can't
agree on basic architectural issues, and whose stuff will never be "just
plugins" for one another because they would be all in each other's hair
all the time about the interface design. harnessing all this mutually
exclusive creativity is a tremendously powerful thing.

jack connects all those diverse tools and programming paradigms - it
creates a workflow (often kludgy, but still) from tools whose designs
are diametrical and whose programmers have perfectly disjunct opinions.
that's the biggest praise i have for any plumbing tool. it's inspired,
and tremendously powerful. with a bow to dennis ritchie, i'd like to
call it "unixy" :-D

i'm watching the future of jack with keen interest (not the least
because my livelihood has come to depend on it). but i'm sort of relaxed
about the schisms we seem to have, because the basic thing is there: the
jack api is dead easy to implement for a client, and its restrictions
are beneficial to code quality (because they clean up and simplify,
rather than add complications).

only today, i had two very contrasting experiences, once of ardour3 and
xjadeo on jack (which just did the job, for pretty much any content i
threw at them) on the one hand and some cubase version including some
obscure set of windows codecs on the other (which most patently didn't,
until i had found a way - with free open-source tools - to massage the
video content just so, until it finally worked).

morale 2: sometimes, integration is not all it's cracked up to be, and
process boundaries can add stability and flexibility as well...

time for the finishing move of this sermon: the "see what we already
have, it's great and there's no cause for panic because we can do stuff
the other tag teams can't" piledriver: don't make assumptions, and don't
throw the baby out with the bathwater.

here's to jack[0-9]* !


best,


jörn




--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio)
Tonmeister VDT

http://stackingdwarves.net

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and pro-audio

Ralf Mardorf
Hi Jörn :)

On Sat, 2012-01-07 at 01:58 +0100, Jörn Nettingsmeier wrote:

> On 12/26/2011 02:55 PM, Ralf Madorf wrote:
>
> > - would it be pro-audio to run 50 applications for one audio production?
>
> who knows?
>
> earlier today, i ran a session with two instances of an ambisonic
> decoder, two instances of a reverberator, an analyser, a convolver, two
> external signal processors, a jack-enabled video viewer, a midi bridge,
> a daw, and two jack recording tools, in a jack session with over 1000
> connected ports to the master bus alone. all those tools were
> mission-critical.

That are 13 apps. The number of the connections are unimportant, resp.
IMO Ardour, Qtractor, Qjackctl does show them clearer than e.g. patchage
does. If they should fail regarding to some connections, there's still
jack_snapshot.

> i like to think it was a professional production. at least if
> "professional" == "making a substantial contribution to paying the rent".
>
> morale: i don't know, you don't know.

At least you did a pro-audio production using just 13 apps ;).

> what makes jack great is it makes no assumptions on what people might
> end up doing with it, it just provides clean plumbing, as best as we know.
>
> i want a jack that scales to high heaven, can pipe stuff over the
> network if necessary, and doesn't get in the way. i want to use the
> greatest tools written by great programmers, despite the fact they can't
> agree on basic architectural issues, and whose stuff will never be "just
> plugins" for one another because they would be all in each other's hair
> all the time about the interface design. harnessing all this mutually
> exclusive creativity is a tremendously powerful thing.

Did you use a session handler for the production you mentioned?

> jack connects all those diverse tools and programming paradigms - it
> creates a workflow (often kludgy, but still) from tools whose designs
> are diametrical and whose programmers have perfectly disjunct opinions.
> that's the biggest praise i have for any plumbing tool. it's inspired,
> and tremendously powerful. with a bow to dennis ritchie, i'd like to
> call it "unixy" :-D
>
> i'm watching the future of jack with keen interest (not the least
> because my livelihood has come to depend on it). but i'm sort of relaxed
> about the schisms we seem to have, because the basic thing is there: the
> jack api is dead easy to implement for a client, and its restrictions
> are beneficial to code quality (because they clean up and simplify,
> rather than add complications).

Full ACK.

> only today, i had two very contrasting experiences, once of ardour3 and
> xjadeo on jack (which just did the job, for pretty much any content i
> threw at them) [snip]

All-in-one: http://rg42.org/wiki/a3vtl

Ciao,

Ralf


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and pro-audio

Florian Paul Schmidt-2
On 01/07/2012 11:41 AM, Ralf Madorf wrote:

> Hi Jörn :)
>
> On Sat, 2012-01-07 at 01:58 +0100, Jörn Nettingsmeier wrote:
>> On 12/26/2011 02:55 PM, Ralf Madorf wrote:
>>
>>> - would it be pro-audio to run 50 applications for one audio production?
>>
>> who knows?
>>
>> earlier today, i ran a session with two instances of an ambisonic
>> decoder, two instances of a reverberator, an analyser, a convolver, two
>> external signal processors, a jack-enabled video viewer, a midi bridge,
>> a daw, and two jack recording tools, in a jack session with over 1000
>> connected ports to the master bus alone. all those tools were
>> mission-critical.
>
> That are 13 apps. The number of the connections are unimportant, resp.
> IMO Ardour, Qtractor, Qjackctl does show them clearer than e.g. patchage
> does. If they should fail regarding to some connections, there's still
> jack_snapshot.

BTW: someone else hacked aj_snapshot which is a definite improvement
over my little jack_snapshot...

Flo
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and pro-audio

Ralf Mardorf
In reply to this post by Ralf Mardorf
PS:
> On Sat, 2012-01-07 at 01:58 +0100, Jörn Nettingsmeier wrote:
> > what makes jack great is it makes no assumptions on what people might
> > end up doing with it, it just provides clean plumbing, as best as we know.

So I guess you won't that Jack starts to make assumptions too ;)?

As I mentioned before, IMO it would be a bad design if Jack should
reject auto-connections. The app should have a switch to turn this off.
If you have several instances for the same task, it only will cause
trouble.

Again, imagine a microphone including an on/off switch. No sound! Is it
muted by the mixning console or is is muted by the microphone switch 50m
away from you, on the stage?

A client isn't able to connect! Is it because auto-connect is turned off
by the app? Is it because auto-reject-auto-connect is enabled by Jack?

I'm not against modular setups, I'm using setups similar to your
example. I'm against useless functionality that just will cause issues.

2 Cents,

Ralf

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: Jack and pro-audio

Ralf Mardorf
In reply to this post by Florian Paul Schmidt-2
OT:
On Sat, 2012-01-07 at 11:56 +0100, Florian Paul Schmidt wrote:
> BTW: someone else hacked aj_snapshot which is a definite improvement
> over my little jack_snapshot...

Thanks for the reminder Flo :).

IIRC the options differ minimal from jack_snapshot, so to be backward
compatible to old scripts, it's not possible just to add a link named
jack_snapshot to aj-snapshot. Anyway, I agree that aj-snapshot is an
advantage.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org