JACK as a Plugin

is this release available in the plugging manager?

1 Like

https://vcvrack.com/plugins.html#jack still at 0.6.6

1 Like

after the last upgrade I m having a big amount of mS in the auxiliary jack modules, see the picture bellow :

I highly recommend using the 8-ins or 8-outs when you don’t need some of the ports. Both of these screenshots have 16 out ports that copy zeroes from JACK and then don’t end up getting used. (There might be an optimization possible by checking if the ports are connected and skipping this copy.)

thanks

the firts one is the 0.6.6, and the second is 0.6.7 , from one version to other this has an increase of 10 times of the consumption

however it look very high compared with the past version even for the even in the 8 Rack, it is using much more than the incubus

1 Like

An issue where 8-OUTs were causing conflicts with 8-IN and the default 4/4 module was fixed and is in a pre-release state. Secondly, going forward the modules will test to ensure port names are valid when creating the module. This fixes two things:

  1. Duplicating a module will no longer show port names that cannot be used. The duplicated module will instead show a new set of ports with scrambled names as though you created it from scratch.
  2. Renaming a port no longer results in it “disappearing” when typing. We detect that the name you are typing is not valid and instead refuse to update it, so it will still appear in the patch bay by its old name.

I suppose this also means those using a tool to append two racks will also no longer be able to have conflicting port names–the appended modules will detect the conflict and re-randomize their names.

1 Like

Poking around with the latency detection side of JACK. Thinking of two methods here:

  1. Keep filling up input/output buffers like we are (and as Audio does,) but try to report a full DSP cycle as latency and hope JACK works it out.
  2. Shoe in some thread magic so Rack is blocked until a JACK cycle, we can take the input / process it / output it and so we actually show up with “zero” latency.

May attempt the first and see how it goes since it requires the least effort.

Option 2 might be looked at if option one doesn’t work as well as hoped. Normally DSP code runs this way (where the interface drives the callbacks, which drives the modules/oscillators, not this weird world where Rack just runs as it feels like and then stalls itself when an output fills up a buffer) but emulating it would require doing a lot of multithreaded debugging to ensure ex. deleting the last JACK module doesn’t cause your instance to seize up.

1 Like

I’ve done up some slides for the current state of the JACK plugin and what I will probably end up doing with it:

slides.pdf (117.0 KB)

It’s not incredibly long, but the tl;dr is “probably a crowd fund to handle the upgrade.”

This would probably include externalities like a website/newsletter and dedicated e-mail inbox, since I see people haven’t been reporting certain issues or they are places I don’t go (Facebook.) Trying to maintain infrastructure code + multiple channels of social media + e-mail because its the LCD starts to get, well, job-like.

1 Like

hello Skylar

it mean that are you interested to continue developing the skjack?

man, based in the experience in this community and considering that probably skjack is used by 3 persons, you will fail with a crowdfunding initiative, I encourage you to sell it in the plugin manager for the maintenance

1 Like

question: the new rack license could allow you sell this plugin and keep it open source?

Commercial Open source exists, i don’t have examples in mind right now, but i already saw that on the internet.

  • Aseprite used to be GPL with commercial binaries.
  • Caddy uses this model as well (have to pay for licenses to use official pre-made binaries and support, but the code is Apache so if you bake it yourself it’s open season.)
  • Ardour “official” binaries used to be paywalled.
  • Tiled is also selling PWYW binaries through itch.io

I would rather not go that route if it can be avoided.

1 Like

yes I know it, my question is , it is compatible with the rack license exceptions ?

I think is fair pay for it

because and 50%i is for the graphics :grin: (joke)

Isn’t Andrew planning to remove jack output from the Audio device? Seems like it would be a bit unfair for linux users to be forced in to buying a plugin when (I assume) the equivalent function is free on other OSs.

Is this what you refer to?

I’ve since reversed this change since I’m not sure if SkJack will be available for v1. JACK will work as normal in VCV Core v1.

4 Likes

I think is complete fair , you should read the slides and take in consideration the time that skrylar invest to develop, maintain the plugin update with rack and jack, the bug fixed etc. and the jack transport , the jack session and midi is an important feature of jack , without it the jack connections with core audio is like alsa and pulse audio jack sink.

it is similar to jack, the price of Mainstage 3 is around 30 usd

I don’t argue about what’s fair or not, but I’ve read those slides and I haven’t found those analysis and strategies proposals particularly convincing, even if I empathize with the author. Investing time on an open source project, not ready to be trusted for live use, led by a single other person, is known to be risky. A safe positive outcome can’t be assumed.

I appreciate enourmously open source developers’ work. I’d buy you all people a drink. A big problem is that I don’t do online micropayments or support crowdfunded projects. Maybe most other people do; maybe not…