Would anyone know if there’s a port or if Skrylar is going to get his plugins into V2? I really need these plugins for my workflow, and would love them to be in Rack 2.
I bought Rack 2 just to support the project, but ideally would love these plugins again.
I went to that github link and looked in the “issues” database. It looks like no one has asked there if they will be updated. Might be worth a try?
The readme doesn’t sound too encouraging:
This plugin aims to bring first class support for the JACK Audio Connection Kit to VCV Rack.
It has not been profitable to work on, so it is maintained or developed on a whim.
What is the advantage in the use of skryjack?, it t is a clone of the audio module, an now you can add as many audio modules you want,. We need a jack module that support jack features , not only I/O (opinion)
Afaik the audio module can only open a “device” and thus it’s quite inconvenient to open more audio ports than your device supports.
Using Skrylar Jack modules you can open as many i/o as you want. Only have 2 channel audio interface but want to record 64 channels VCV in your DAW? → no problem.
I’ve been thinking about looking at updating these modules as imo these are invaluable in a JACK audio environment as it allows for much better integration over the standard audio-i/o modules.
I don’t think it’s a mere clone. In Rack v1 I was able to create much larger patches without glitches by replacing the Audio-8 module with Skrylar’s Jack 4x4. Alas, Skrylar’s included Jack API is out of date, and I’m already experiencing problems with patch sizes with the new official Audio-8 module. So it would be nice to have the Skrylar Jack plugin back in action on v2, but the work will require someone with up-to-date knowledge of Jack.
Perhaps not relevant for you but if you use pipewire you can load multiple Audio-16s by choosing alsa and you get all those channels which show up on the jack graph in qjackctl and can be routed to as if it were a Jack client.
For one Pipewire is nowhere near ready for “pro audio” usage. Also I don’t see how this solves anything. With the Alsa option it still needs to select a device, no?
Well, as I said, it may not be relevant for you. I use pipewire and don’t have any problems with it.
Yes you have to select a device but you can do that with multiple audio device modules. Using Jack option doesn’t let you even choose a device if it doesn’t have the number of in/outs.
This is exactly why the Skrylar modules are superior, since you can just add i/o ad-hoc without any issues. They also share the connections to JACK so are more efficient.
I will see if I have time to update these modules as they are indispensable for using Rack on top of JACK (and pipewire, if you will).
That’s exactly what I’m saying I can currently do, I don’t think duplicating a module is an issue. I know that not everyone is using pipewire though and I guess this method won’t work if you are not using it.
I use it on my laptop, but it will take a looooong time for me to use it in my studio. Most definitely I prefer to have a dedicated, low-latency and tuned, JACK server using a dedicated audio device.
Skrylar JACK Plugins give by far the most flexibility in such an environment. Also the device naming is much more deterministic in such patches, which means that your entire routing session can actually be reproduced, which somehow I think won’t be the case in the work-around you describe.
I hope you are going to make a new plugin based on the Skylar one, if that one has indeed been abandoned?
have you try this in the v2?
also you can use more than one audio (hardware) device I have not try it on linux yet , but I bet work perfect, please give a try and let us know…
that was the dev said if I can remember correctly…
however my point is skyjack is not a bad plugging but is incomplete and not necesary (of course it is just an opinion)
we should desing a better jack pluging as comunity and make it happen
Sorry I do not see how that is at all relevant?
JACK is not a hardware device. We are talking about creating software ports which has nothing to do with hardware. Having to choose a “device” when you want to create software ports is inherently the wrong approach all-together (which makes the RtAudio based modules really annoying to use).
Btw I now have the Skrylar JACK Plugins working in Rack2, however the state saving (jack port names) needs a big overhaul as they still use the old toJson()/fromJson() methods and I honestly have no idea where to start with this.
Will need to get some more experience with Rack module code to better understand what is needed to refactor this.
Anyway, they do work so this is very much doable 
I not said that
Without Skrylar JACK plugins, how can I route more outputs with JACK to show up in the Audio modules? By that, I mean the virtual routing counterpart in JACK to use more channels in my DAW, with a 2 channel audio interface.
I route each signal chain to a DAW channel which allows me to fully take advantage of how I want everything to sound through line level in the DAW. Mastering it in a sense that, if say a bass drum, or snare needs a bit more reverb, I’ll add it in the DAW and it will be individually biased. Which I don’t want in my signal chain as it’s not part of the instrument characterization. With doing this, I don’t use a mixer in VCV Rack because each signal chain is already getting mixed in the DAW. Which in turn levels, automation, panning, and everything else gets influenced in the DAW rather than Rack itself.
Well its only taken another 2 years, but I finally got around to porting and updating the plugin. The routing between programs workflow I personally use simply isn’t stable with the rtaudio implementation.
