JACK as a Plugin

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)

Sure.

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

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.

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!!!)

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.
1 Like

nice work! is there a Windows build out yet?

:smile: Looks nice.

I’m not aware of one yet.

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

1 Like

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.

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

1 Like

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.)

2 Likes

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.

3 Likes

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.

1 Like

I checked out the new commit and yes, man, the shim snippet let us gracely bypass the libdl dependency to use Windows native API.

To compile, I only had to edit it like this:

#ifndef ARCH_WIN
#include <dlfcn.h>
#else
#include <windows.h>
#define dlopen(x, y) LoadLibraryA(x)
#define dlsym(x, y) GetProcAddress((HMODULE)x, y)
#define dlclose(x) FreeLibrary((HMODULE)x)
#endif

Also, I had to copy the jack headers from the skjack-vcv repo (“src/jack” folder) into my MinGW include folder (the jack inner includes are specified as system headers).

I already verified that on my DAW my first build test failed and the plugin could not load, missing a compliant link with libdl (the one living and linked in my development machine). So I was considering to try with static linking. But now it looks like the conditional defines just do the trick with no extra effort!

Here a screen with the internals dependency calls after the plugin loads:

I’d say that the plugin could now be really tested by some Windows+Jack adopters! Here the new Windows build, that should work on common Windows systems with a Jack working instance installed and running.

@Soothsayer Windows build · Issue #2 · Skrylar/skjack-vcv · GitHub

1 Like

Putting -Isrc in FLAGS of the Makefile gets around this.

Screenshot%20from%202019-02-03%2005-37-16

Pre-release has finally gotten the beauty pass that I promised @David :wink:

5 Likes

haha!
look so great!

2 Likes

SkJACK is now headed in the direction of the Plugin Manager. :tada:

9 Likes