It would be desirable if the Jack backend would (try to) autoconnect to playback_1, playback_2 of system
mxa
All 9 comments
I'm not a JACK user so I don't know what this means.
Can you please fill out the feature request issue template with a proposed design, possible implementation, motivation, etc?
AndrewBelt
on 1 Jul 2020
A .gif says more than many words:
Comparing the behavior of Pure Data with Rack's you can see that it is already automatically connected to the system in and out. I don't know about the underlying mechanics of this, most probably @pauldavisthefirst can say more.
mxa
on 1 Jul 2020
I am no longer involved with JACK, but I do use both Rack and JACK all the time, so let me try to flesh this out a little.
Right now. the Rack JACK support in the "Audio" module creates ports for audio input and output. The number is configurable (great).
But ... Rack does not connect these ports to anything, so there's no audio I/O without the user taking some extra steps to connect them to something.
There isn't a direct analogy to this when comparing with ASIO, CoreAudio or ALSA, but imagine somehow that you create the internal "audioengine" within Rack, but never actually open a particular hardware device. It's not a good analogy.
Now, a couple more comments.
First is: although the lack of auto-connect is a bit irritating, it is relatively easily solved by using QJackCtl to control JACK, and setting up a patch bay within it that takes care of the auto-connect (this is what I do, after finally getting tired of the need to manually connect things).
Second: what's more annoying than the lack of auto-connect (which in some contexts is actually a benefit) is the fact that the module doesn't retain the connections as part of its state. So if you're using JACK and have taken some steps to connect Rack to some suitable input/output sources, this is not remembered as part of the module state and thus the patch also. This is quite irritating.
Thirdly, I haven't tried it yet, but there is a 3rd party module for JACK support that I think gets all of this right. It's a bit less useful to use however, particularly if you want to share patches with other uses who do not use JACK.
pauldavisthefirst
on 2 Jul 2020
This PR disabled autoconnecting with RtAudio's JACK backend. https://github.com/VCVRack/Rack/pull/740
In order to revert this change, I need to see all arguments for and against the change.
AndrewBelt
on 2 Jul 2020
Thirdly, I haven't tried it yet, but there is a 3rd party module for JACK support that I think gets all of this right. It's a bit less useful to use however, particularly if you want to share patches with other uses who do not use JACK.
I recon this is said module? https://library.vcvrack.com/SkJack/JackAudio
mxa
on 2 Jul 2020
pro-autoconnect:
1) audio I/O just works, like it does for any of the native audio backends (CoreAudio/ALSA/windows-mumble)
2) right thing for almost all users
anti-autoconnect:
1) how to know where connect to (system:playback_1..N is a good guess but not always correct)
2) wrong thing to do in every case, and could cause problems depending on the analog connections
Personally, I'd say that auto-connect wins by a small amount, but there have certainly been complaints over the years within the JACK user community regarding software that auto-connected when it should not have.
The idea solution is to ONLY auto-connect based on saved state. Everybody wins then.
pauldavisthefirst
on 2 Jul 2020
If Rack's JACK audio driver autoconnects, is there a chance that the connection it creates crashes Rack?
AndrewBelt
on 18 Jul 2020
The lack of autoconnect would be even more easier solved if VCVRack would have Non/New-Session-Manager support (NSM). That would be nice. Then the session manager takes care of the connecting the ports of your whole session and VCVRack shouldn't autoconnect in that case.
https://laborejo.org/agordejo/
https://github.com/linuxaudio/new-session-manager
https://non.tuxfamily.org/wiki/Non%20Session%20Manager
http://non.tuxfamily.org/nsm/API.html
grammoboy2
on 20 Dec 2020
grammoboy2
on 20 Dec 2020
Related issues
polyclash
路
3Comments
antoniotuzzi
路
5Comments
synthi
路
4Comments
AndrewBelt
路
4Comments
AndrewBelt
路
5Comments
Most helpful comment
I am no longer involved with JACK, but I do use both Rack and JACK all the time, so let me try to flesh this out a little.
Right now. the Rack JACK support in the "Audio" module creates ports for audio input and output. The number is configurable (great).
But ... Rack does not connect these ports to anything, so there's no audio I/O without the user taking some extra steps to connect them to something.
There isn't a direct analogy to this when comparing with ASIO, CoreAudio or ALSA, but imagine somehow that you create the internal "audioengine" within Rack, but never actually open a particular hardware device. It's not a good analogy.
Now, a couple more comments.
First is: although the lack of auto-connect is a bit irritating, it is relatively easily solved by using QJackCtl to control JACK, and setting up a patch bay within it that takes care of the auto-connect (this is what I do, after finally getting tired of the need to manually connect things).
Second: what's more annoying than the lack of auto-connect (which in some contexts is actually a benefit) is the fact that the module doesn't retain the connections as part of its state. So if you're using JACK and have taken some steps to connect Rack to some suitable input/output sources, this is not remembered as part of the module state and thus the patch also. This is quite irritating.
Thirdly, I haven't tried it yet, but there is a 3rd party module for JACK support that I think gets all of this right. It's a bit less useful to use however, particularly if you want to share patches with other uses who do not use JACK.