I tried to compiled using my windows virtual machine until I realize I don’t know how to use the windows terminal…
@David If you do try don’t forget that you will need to install the Jack source too.
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.)
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
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.
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
dlopen calls to be their equivalents under the Microsoft APIs. This should remove the need to install any new packages or add link arguments.
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.
FLAGS of the Makefile gets around this.
look so great!
SkJACK is now headed in the direction of the Plugin Manager.
The 8-OUT is now in pre-release. Now your 8-channel mixers have an easier time making it to Ardour
-out suffixes are now in prerelease. This means you can name both your input and output
valley reverb and your JACK patch bay will have a
valley reverb-in and
valley reverb-out, just like Ardour or non mixer would do.
Could be possible add a mute button to each of the channels?
It could, but isn’t this what your mixer is for?
let me expand a little more about my workflow, usually I only mix the drumkits inside the VCV rack, I use renoise (or another DAW) as sequencer, clock and mixer, in the pipeline I could use some external effects like CALF or some vsts through Carla but most frequently the native effects of renoise (compresors, eq, or whatever) even when I own the Vst host of vcv rack because I feel the performance of the vst is better through other ways
however it workflow use multiples desktops (usually one DAW or software per desktop ) and is a little tricky go to other desk to mute channels or get “Solo” for and come back to the vcv rack, and go to the DAW and so and so…
BTW I think a Jack mixer to vcv rack is the next logical step , we (the jack users) happily pay for that.
This is what comes to mind when talking about mute switches:
Mutes from Fundamental wired in to the interface, and an outdated Jack output.)
I’m not sure what JACK has to do with this. It sounds like what you want is a mixing console with two-way sync (probably via OSC+UDP or MIDI CCs) between desktops.
a mixer like “VCV Console” except, the send channels can be connected with external apps via jack or perhaps a hybrid between NON mixer and VCV Console is coming to my mind, about the osc or midi, the midi learn is coming in the next version…
I complete forget Mutes, that is exactly what I mean, thanks!
I’ll put it on the “someday” list, although in the interim you can wire an mscHack mixer’s aux lines: