JACK as a Plugin


(Skrylar) #21

Pushed 0.6.2 tonight. Should fix some crashes related to adding and removing JACK Audio modules, and also makes them cooperate with one another.

Previously:

  • Multiple modules added more ports to JACK, but they did not all send audio in the same batches. This meant that if you piped a song from VLC -> Rack -> System and used two modules for left and right channels, you could hear an obvious but small delay.

Now:

  • The same VLC -> Rack -> System test doesn’t have a delay. All JACK Audio modules send in the same sample batches as each other. You can also watch on the power meter how all modules except for one’s processing bar shoots down, as only “one” of the modules now stalls Rack.

(Nik Jewell) #22

Mac build uploaded as GitHub issue (slight problem also with graphics - Mac Jack port addresses too long for display).

Mac build also in my collection of non Plugin Manager Mac builds here:

https://drive.google.com/drive/folders/1esuoDkA-8Uw081_zznPXZxw7AnOAtzqx?usp=sharing


(Lars Bjerregaard) #23

Very cool Nik! Are you making any effort to keep them updated?


(Nik Jewell) #24

As and when I see there is something new but you will probably tell me something is out of date :wink:


(Skrylar) #26

Trying to decide how to handle going forward with the module design. The aesthetics of the module is apparently highly important to some users, so it’s something we have to address eventually.

svg

The left side is what we have now (all ports have individual names) and the right side is more like the original audio module. Naming the ports in batches frees up space for either more plugs or more LEDs/switches.


(Skrylar) #27

0.6.4 is now out and brings fixes for these issues; text shouldn’t overflow by default and the resampler now correctly matches Rack->JACK audio.


(David Rodriguez) #28

I like the first option , since is pretty nice give names like “drumkit_L” , “drumkity_R”, “bass_L”, “bass_R” ,etc than just “A”, “B”, “C”…

can I make a try to design the components?
(if I fail you can always use the fundamental components)


(Skrylar) #29

Sure.


(David Rodriguez) #30

what do you think opf this? too dark?

I can make a light version too

I suggest try with another logo since the jack logo is copyrighted

edited: I opened a issue about this topic on github https://github.com/Skrylar/skjack-vcv/issues/10


(Skrylar) #31

I like it.

  • Have a concern about what extent gradients work with nanoVG. My re-creation of the JACK logo looks like it has one, but the colors don’t match what’s in inkscape. So I’ve erred on the side of not using them (which does make things look a little worse.)
  • Output ports should be more obvious IMO. Most of the VCV modules have some kind of accent paint to highlight the difference (in 0.6.4, it’s now a darker variant of blurple and has the word “OUT” on it.)

recorder

I can check around to see what the licensing is on the logo. QJackCtl for instance uses a variant of the big TRS plug.


(David Rodriguez) #32

I got it

no worries, I tested that effects before on the vult modules , all them work

I’m going to make the changes you mention about the outputs and inputs, present a light option, polish the details and upload the components separately,

it’s ok if I licensed the components as Creative Commons BY (could be creative common zero if you wish)

that brown module is needing components too? (is that a jack transport? that would be awesome!!!)


(Skrylar) #33

Nice :wink:

Any CC should be fine. JACK’s client is itself LGPL and the SkJack adapter code is BSD, so everything is pretty liberal.

It’s an 8-track recorder. No frills, just plug+arm+smash rec and it dumps to a wav file probably in the home directory. There’s no code written for it yet; I just did up the design work thinking about doing it, because simply dumping samples to a sound file is easy and it bothers me that the only modules that do this right now are closed source.

I have a thread here asking what people want out of their transports; there’s a few interfaces for them and they all have similar problems to solve that applies to us having a JACK transport module too.

  • Hooking up the reset/start/stop triggers and rolling gate probably would take only a day of poking around, but you’d have to plug it in to a clock module within Rack to do anything with that. (Better than nothing?)
  • JACK defers to another process (the timebase master) to actually manage bars/BPM. I’m assuming (without having experimented too in depth yet) that this means a process just declares itself the time keeper and then posts whatever the current bar/beat is, which we then just poll and toss out a trigger when it changes.
  • Absolute time doesn’t make a whole lot of sense and I don’t think modular workflows really support it. I can do up a simple standard here and say something like “1V/hr” since its unlikely you will have more than ten hours of patterns programmed in at a time.

(Soothsayers) #35

nice work! is there a Windows build out yet?


(Skrylar) #37

:smile: Looks nice.

I’m not aware of one yet.


(Soothsayers) #38

Yes Jack is on windows! I would love a Windows build … :wink:


(David Rodriguez) #39

I tried to compiled using my windows virtual machine until I realize I don’t know how to use the windows terminal…

I will try later following the @modlfo (vult) tutorial.


(Nik Jewell) #40

@David If you do try don’t forget that you will need to install the Jack source too.


(Skrylar) #41

i could probably fix this by embedding the headers in the repo. They are LGPL, so we are allowed to do it, and the module doesn’t link with JACK at compile time (so you don’t need the .so/.a/.dylib/.dlls to do a build.)


(Daniele Zerbini) #42

Hi @Skrylar, I managed to build with the MinGW toolchain on my Windows x64 8.1 development machine, and made a quick test. It was a little tricky, but basically I had to install (via pacman) the dlfnc package (to wrap the dl* calls for Windows) and it was not a default thing in my msys2 environment. Then I collected the Jack headers, as you already guessed, and added a linker flag to the libd shared dynamic library to resolve references at link time.
Also, I had to change the target in the client::link() call, pointing the libjack64.dll library in lieu of the libjack.dll version. The library lives in the Windows folder, as per the default installation of the Jack Connection Kit on my machine.
With this setup I manage to load and connect things, upon Jack server launch.
Otherwise, I usually have a silent crash on exit, if I load and connect the Core Audio module.
That’s all, here I simply post a screenshot of the working thing.

For the binaries, I just uploaded the dist zipfile (SkJack-0.6.4-win.zip) here on my Google drive.
EDIT: this build is obsolete. For a new Windows build, see further below in the discussion.

Being this a free build-and-test code experiment, I prefer not to post issues or comments on Github at the moment. But let me know if your next finalization steps need some further testing and I’ll try to put some time in it.
Best with your work.


(Skrylar) #43

As of 763b9468bf525c34:

These are now in-repo. I don’t think there are config settings to deal with, so it should be fine.

I’ve patched it so the party hat suffix on windows is 64.dll, so it will search for libjack64.dll on builds where ARCH_WIN is set. (Windows also only gets one attempt at finding the library.)

I put a (currently not tested) shim in; if it detects a windows build, we just #define the dlsym and dlopen calls to be their equivalents under the Microsoft APIs. This should remove the need to install any new packages or add link arguments.