auto-routing

[Pablo]

This kind ease of use that the OP suggests , is why plug-ins that integrate with the host DAW is the best method.

I agree. But

I find Jack counter productive

It can be counter productive not having more plugins but note that jack is more than just a "connection kit". It is a low latency audio system.

Even if all your favourite virtual intruments, audio FX, analysis tools.. could be integrated in a host DAW as plugins, jack would still be the "audio engine" (and the "connection kit" behind the scenes). The fact that you could still connect your DAW to other jack-aware programs would be a bonus.

[ToddMWorth]

Their is no point having several standalone programs, that one program can do far better .

That's not really correct, in fact the Unix Way states quite the opposite, for very good reason.

http://en.wikipedia.org/wiki/Unix_philo ... ry_of_Unix

For a classic example, you don't want to add a spell checker to your program - there are many text-handling programs, and having a separate, different spellchecker in every app would suck for usability and stability and diskspace and RAM consumption and CPU time etc etc.. What you want to do, is make a spellchecker which can communicate with other programs, and then make your program communicate with that.

JACK is not only used for connecting DAW apps to synths and fx. I use it for routing between different apps, for live treatment, livePA, routing around my house...all manner of things. We don't all make music the same way that you do, with plugins in a linear DAW. JACK is in essence the digital representation of the patchbay which is such a necessity in any sizable studio. Plugins are more like synth/effect boxes. They don't do the same job, so one cannot replace the other. In fact, they can complement each other, which is exactly the design you are having trouble with.

JACK, being a sound *server*, should correctly be separated from the host applications for architectural reasons. With respect to plugins, if you think about how a plugin works within a DAW, the plugin needs to communicate with the host, to send and receive audio, and to know what it needs to do with that audio. Within the DAW, that is done by using the plugin standard (eg VST) API.
A similar approach is to use the JACK API, you send the control signals (MIDI) to that, and it sends them (according to your routing) to an app which has code just like the plugin would. It's the same thing, but you're given access to the layer inbetween the host and the synth/fx. Sometimes it's useful, sometimes not.... but I like having the choice. Maybe I will use the MIDI CC which controls my delay time, to also control the cutoff Q, or something like that. I came from a modular hardware studio and these kinds of flexibilities are essential to the way I make music, and consequently are the reason I use linux and JACK.

You imply that the linux/JACK/etc framework is not straightforward, but I disagree. I think that the confusion you've shown demonstrates that the linux land is still a little bit new to you, and that you're not too deep into programming yet. We all go through it - I was a Microsoft guy from age 5, the MS Way was well integrated within me. You'll pick it up

Edit: oh yeh - and any JACK-aware app can be connected to any JACK-aware app, so all JACK-aware DAWs can already be plugins in other JACK-aware DAWs

[wolftune]

This is an entirely misguided argument, in my opinion.

Delete the entire why-don't-we-drop-JACK-and-just-have-great-monolithic-DAWs bit and replace it with this:

It would be nicer if everything was easy, intuitive, robust, worked perfectly, powerful for advanced users, and easy for beginners.

Seriously, you have no real complaint with JACK. Your entire complaint is about the rough edges and troubles with GNU/Linux and Free Software in general. That's a concern we all share. The JACK argument amounts to trying to scapegoat, to figure out if the reason we don't have everything we want is because of JACK. In principle, it's possible that JACK is to blame and makes the situation worse. On the other hand, it's possible that it would be far worse without JACK for various reasons.

The degree of simplification in your argument, however, shows that you don't understand truly why things are rough. You're hoping that if developers just copied the model of Apple, that somehow we'd just get a better system. But I find that very dubious. The essence of Apple is lock-in and control over users in a way that helps Apple have the best funding but is highly problematic. The essence of Free Software is ethically opposed to that but results in constant struggles to get funding, and it's a vicious cycle. Now, I'm working on a new system to get better funding, but that's another story…

The point is very simple: you would clearly not be complaining about JACK if the overall system was everything you wanted. I don't know the details, but I know enough to say that if we just dropped JACK, it would not solve the problems at all.

In summary: I agree with your complaints about the status quo. I also agree that there is room for improvement in JACK, it may or may not be the solution, and that it can be confusing. But your idea that without JACK and with some focus on Monolithic DAWs we would just solve our problems — that's unfortunately far off base. The reality? It's complicated…

[tatch]

This is an entirely misguided argument, in my opinion.

I agree with wolftune. I started this topic to brainstorm ideas that could improve JACK's usability, not to begin another pro-vs-anti-JACK war.

[TheSafePlaces]

tatch -
I use shell scripts to do the job. My general usage is qtractor or muse2, VMPK (these days; to test SFZs) and aboout thirty freaking devices in linuxsampler. Manually connecting in Catia in this case would be abysmally stupid, LADISH still doesn't support multi-client apps (so it won't connect more than one device), and I'm yet to understand NSM. So...
I type in a terminal (I don't know if this is how everyone uses Linux, but I always run everything off terminals) -
'qs', and the svn build of qsampler starts and loads my usual LSCP.
'lsacon 1 a', and all (the 'a' argument) audio connections of linuxsampler are connected to the system playback ports.
'qmcon 1 a', and all my qtractor MIDI connections are done.
'vmpklsm 1 x 1', and vmpk connects to Linuxsampler device X, and disconnects from any other devices.

(I've made the above scripts such that in the first argument, 1 means 'connect', and 0 means 'disconnect'. The second argument is for device number, 'a' meaning all. The third argument exists only in the 'vmpklsm' script, to enable 'exclusive connections' - if VMPK connects to, say, device 1, it will disconnect from all devices other than that one.)

Fast, and very very satisfying to watch in Catia as tonnes of connections connect speedily and automatically, one-by-one, like synchronized swimmers Connections managed, and I'm ready to work - all in under ten seconds.

One's usual connections can be managed quite quickly, saving loads of time and frustration, with a little one-time-investment in bash scripts. I'm told some programs will do the same job better (JACK Patchbay), but this current method is very comfortable for me, and it may even be better - I used to use JACK patchbay long back, and I don't ever remember it being as good or reliable.

To the small minority of JACK/modular system haters in Linux audio land...yes, you were saying?

[varpa]

Concerning scripting to make connections if you just need to restore some static setup you can make all the connections by any method and then use "aj-snapshot <filename>" to save current connections to file <filename>. Then later, you can restore the connections with "aj-snapshot -r <filename>". However, I think NSM is even better because you can use it to start all the applications you want to use and then use its "jackpatch" client to store all the Jack connections.

[tatch]

I type in a terminal (I don't know if this is how everyone uses Linux, but I always run everything off terminals) -
'qs', and the svn build of qsampler starts and loads my usual LSCP.
'lsacon 1 a', and all (the 'a' argument) audio connections of linuxsampler are connected to the system playback ports.
'qmcon 1 a', and all my qtractor MIDI connections are done.
'vmpklsm 1 x 1', and vmpk connects to Linuxsampler device X, and disconnects from any other devices.

(I've made the above scripts such that in the first argument, 1 means 'connect', and 0 means 'disconnect'. The second argument is for device number, 'a' meaning all. The third argument exists only in the 'vmpklsm' script, to enable 'exclusive connections' - if VMPK connects to, say, device 1, it will disconnect from all devices other than that one.)

Fast, and very very satisfying to watch in Catia as tonnes of connections connect speedily and automatically, one-by-one, like synchronized swimmers Connections managed, and I'm ready to work - all in under ten seconds.

this sounds like an interesting solution. Could you perhaps share the scripts that you wrote? I'm pretty comfortable with bash scripting but I haven't done much linux audio scripting.

[Alwaysanewb]

I really don't like the standalone daw setup. Windows and mac are good if you want the computer to make music for you. I just don't think those inviorments are very good for inspireing creativity. If you want to auto-tune and rythym correct your way to stardom they might be good OSes for you.

I like having the option of being able to route anything to pretty much anywhere you want. and If you don't like the way one program handles fx or recording or what ever you have options which is never bad.

For the electronic/synth based music if you think linux is bad try having to program your dx7 run that through midi to a sequencer program that doing the samething with your other synths and a drum machine. Then Having to learn how to run that all correct through your mixer and 8 track tape machine. Plus all that gear would cost a lot more money and it breaks so you have to pay for maintance. I know it seems like the same thing but using a gui, keyboard and mouse is a lot different than using a oldschool LED display, A bunch of poorly labled buttons, Horrible menus and sub menus, and they're all different from machine to machine. Then instead of jack you have midi cables and a mixer. The cables themselves cost more than my whole computer.

I record all live instruments. I like sequencing and samples for certain types of music so will probably use them for certain songs I'm planning at a later date.I'll also use some linux synths on songs I have written now. Even recording live instruments I can have everything up and routed in linux in under 5 seconds anytime I want to record that's pretty quick no matter what os your using.

I'll admit before kxstudio and claudia ect... Qjackct was a nightmare and getting things to work much less work together sucked really really really bad.
Right now linux audio is pretty much as straight forward as you can get.

The only thing I can really think of that would improve linux audio is if there was a way to orginize all the plug ins in a much better way. It's hard to sort through 500 plugins to find the ones that you think will suit the music your making. I know a lot of programs have favorite settings and people that use plugins everyday wouldn't have that problem. For me when I record I don't add plugins till the very last step of a progect and progects for me take a lot longer than most people a few days to years. So I don't have all the plugins memorized. I have enough outboard gear comps, reverbs, and my mixer as a decent eq. I see plugins as another tool in my arsinol. I think pluggins and outboard gear sound different too. I like both a lot. I think it would be really cool to be able to do some songs using computer fx just to get that sound.

There really isn't that many types of catagorys of fx. Reverb, comp, eq, and other. I know there are sub catogorys of these but the sub catoagorys don't really matter to people that aern't into the tec and just want to find a decent reverb or comp. I know a lot of you guys do synth/drum machine/sequencer based music and you have to understand that a lot of pluggins that sound great for that type of stuff don't sound as good on traditional guitar/drums/bass guitar bassed music so I really have to dig to find some stuff I can use.

Maybe carla has this all sorted out I don't know. From where I am looking though pluggins and fx are the only real hurdle linux audio has to jump. There are some good pluggins out there for us to use. Not enough but that doesn't really hinder the music or creativity behind it. It's just tough when I do want to use a pluggin I have to sort though 1000 of them that I have no idea what they do.

[TheSafePlaces]

this sounds like an interesting solution. Could you perhaps share the scripts that you wrote? I'm pretty comfortable with bash scripting but I haven't done much linux audio scripting.

In the meantime, I checked out aj-snapshot. It is AMAZING. I use my bash scripts very rarely now that I use aj-snapshot (only when setting up the connections for the latter, and even then very rarely; I mainly use scripts to launch programs where I need long CLI arguments and/or specific files to load by default on a daily basis, like xjadeo.). It's a CLI app, but using it is simplicity itself. Apart from the commands varpa mentioned -
aj-snapshot -x will remove all connections,
aj-snapshot -r <filename> -x will remove all connections and load the specified connection snapshot (usual snapshot load appends connections)
There are other options too, but I haven't looked into them so far (use the evergreen --help).
aj-snapshot daemon mode ( -r -d <filename> ) deserves special mention - you set it to load a snapshot in daemon mode and you will never need to touch connections until you need to switch workflows. Very handy. Although keep in mind that daemon mode causes massive skips in Ardour - Paul told me to contact the aj-snapshot author ( lievenmoors, and he doesn't come on IRC very often :| Perhaps I should file a bug report on the SF page.)

Caveat - the issue is that aj-snapshot works best when you have any amount of specific workflows - i.e. you like to establish workflows and not change them, say, every two minutes. Use-cases where lots of setup changes are anticipated can ameliorate their situation by opening all application that can possibly be required, have as many instances as one may anticipate, and use multiple connection-snapshots - but this is a hack, and a limited and resource-wasting one at that. The real solution would be some kind of a patchbay designed for very fast patching, perhaps in conjunction with some kind of a smart, user-configurable auto-patching daemon.

aj-snapshot, is, however, central to my work. My notebook's RAM is on the low side (3 gigs), so I can only load one section of the orchestra (strings/woodwinds/brass/percussion/keyboard instruments) at a time. My set of snapshots are made to deal with one section at a time. Loading the 'strings' snapshot, for instance, will connect Laborejo's violin, viola, cello and contrabass MIDI tracks to the respective Linuxsampler channels, connect Linuxsampler to the Calf reverb in Carla (going to system playback) and to the respective instrument audio tracks in Ardour. Sequencing, bouncing to Ardour, reverb for me to hear, everything covered. If I don't need to be using Ardour, I can choose not to launch it, start the other apps and use the same snapshot file - it will say 'all alsa and jack connections could not be restored!', but the rest will work. Hey presto, many scenarios solved with just one snapshot file - my entire setup covered with about seven. Needless to say, my sincere thanks to varpa for the info.

Speaking of CLI things, people who shy away from CLI (not pointing fingers at anyone, generally speaking), and session management - I don't know how many people use the CLI, but for those who don't - I'd say there's much benefit of using it, even for GUI apps. It forms a sort of session management -
you can start things quickly (keyboard, with a little experience and practice, is faster than the mouse; although for really big modular setups perhaps a real SM is faster),
you can check the status of running programs (duh),
you can kill programs quickly,
you can restart them quickly (again, faster to press Up and Enter than to reach for a mouse),
(setting the terminal to a shortcut (mine is Alt+`) quickens the process even more,)
you can group things and create order by using tabbed terminals. (I will always have two terminals, one for non-music and the other for music - and the order of tabs in the music one is always Laborejo, Carla, qsampler, Ardour3, xjadeo, and aj-snapshot.)

[AnthonyCFox]

Shell scripts were my solution too; before I discovered Non Session Manager.

[Thad E Ginathom]

Concerning scripting to make connections if you just need to restore some static setup you can make all the connections by any method and then use "aj-snapshot <filename>" to save current connections to file <filename>. Then later, you can restore the connections with "aj-snapshot -r <filename>".

Thank you!

There may be better and or more complex options, but starting the applications I need in a script and then calling aj-snapshot to restore the connections is all I need --- and I never would have known about it.

[tatch]

I'm revisiting this topic because I still haven't found a satisfactory solution to my problem. I don't really want to use qjackctl since I've been used to using cadence but cadence doesn't have a patchbay like qjackctl does.

at this point I can work with the signal flow being something like this (eventually I want it to be more complex though): instrument (a carla-rack with output_1 and output_2) -> instrument_sc (sc3 plugin with Left input and Right input) -> Non-Mixer/instrument. I just tried using regular expressions in the patchbay by connecting \w+ to \w+_sc which almost works; the problem is that the regex connects all of the ports that fit any arbitrary word together. For example, if I have bass and bass_sc it will connect fine, but if I introduce pad and pad_sc the both the bass and the pad will connect to both _sc's at the same time. Is there a regex that will let me specify that the ports that are connecting have to be identical (but artibrary) strings?

If I can get this to work it'll be alright for a bit, but ultimately I think I might try to write my own auto-routing app in C++ which I have vague experience in (i'd rather use python but it doesn't look like pyjack has that sort of functionality yet). I've been trying to figure out how to get a list/vector/array/whatever of all existing jack clients but I can't figure out how from the APIs. How do you do that?