> I'm curious about why the author's using Jack1 rather than Jack2. Is Jack2 not available for guix? Jack1 has a bunch of limitations compared to jack2 and hasn't been in active development for a while apart from bugfixes.
I write in a rambling little post I made last year about my Linux audio mastering workflow [0],
>> We will be using jack2 because using jack1 in 2019 is stupid! The multi-threading, MIDI, and other various features of jack2 are deal-breakers, not nice-to-haves.
In my experience, the need for jack2 is amplified even further when you want to work with modern plugins like the ones you mention at KVR.
> Being able to arbitrarily patch the inputs and outputs to any other input and output between jack aware software is honestly one of the coolest things i've seen.
Indeed! When I was a studying audio engineering at university this was a huge revelation and few of the professors & professionals I was surrounded by had any idea this functionality was out there. The fact that it was FOSS blew their minds.
If you want to go even further down the modularity rabbit hole, check out non-daw [1].
* dbus integration
* multi-core parallelism
* click-free port connect/disconnect
But: the first only matters on systems with PulseAudio installed (or where you insist on being able to use dbus to control JACK). The second only matters if you have actual parallel signal flows, which many people do not. The third is only possible if you run JACK2 in non-sync mode, which adds an extra cycle of latency.
JACK1's continuing benefits over JACK2:
* integration of a2jmidid so no need to use separate tools to make MIDI devices visible
* integration of zita-a2j making it easy to use multiple audio devices from a single JACK instance
I believe that Filipe, the current maintainer of both JACK versions, plans to unify these features.
I don't have much of an opinion. Precisely how PipeWire might affect (or not affect) the direct use of the existing implementations of the JACK API (JACK1 and JACK2) isn't of a lot of interest to me. But I trust Filipe to know what to do.
I've used non, I like it and I like the idea, I wasn't really a fan of the ui though. I used non-sequencer for a bit but ended up switching to muse and rosegarden before Ardour got midi. I find it almost a bit too modular. I do like the idea of having ardour as an end point for various things.
I tend to sequence and record audio into ardour then do some processing and mixing there.
Then I'll mixdown in ardour then patch that track through jamin into a new ardour track for mastering.
I find that setup still gives me flexibility while having a sort of centralized 'master console' or something.
jamin ... i hate to be a nag, but pleasepleaseplease stop using this software. Conceptually it's a cool application, but the DSP artifacts it generates are just awful.
There are plugins you can use within Ardour that will do a much better job than jamin.
Could you point me to some? I started using jamin when it was pretty much the only mastering available, if there's something better now I'd like to check them out.
Thank you. As awesome as the Harrison stuff all is, I make music for fun, so it's a bit out of my price range. I've been really liking the LSP plugins though, i'll have to check those out.
I write in a rambling little post I made last year about my Linux audio mastering workflow [0],
>> We will be using jack2 because using jack1 in 2019 is stupid! The multi-threading, MIDI, and other various features of jack2 are deal-breakers, not nice-to-haves.
In my experience, the need for jack2 is amplified even further when you want to work with modern plugins like the ones you mention at KVR.
> Being able to arbitrarily patch the inputs and outputs to any other input and output between jack aware software is honestly one of the coolest things i've seen.
Indeed! When I was a studying audio engineering at university this was a huge revelation and few of the professors & professionals I was surrounded by had any idea this functionality was out there. The fact that it was FOSS blew their minds.
If you want to go even further down the modularity rabbit hole, check out non-daw [1].
[0] https://grathwohl.me/2019/05/05/linuxmasteringflow-1.html
[1] https://non.tuxfamily.org/