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)
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.
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
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.
nice work! is there a Windows build out yet?
Looks nice.
I’m not aware of one yet.
Yes Jack is on windows! I would love a Windows build …
I tried to compiled using my windows virtual machine until I realize I don’t know how to use the windows terminal…
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 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.
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.
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.
Putting -Isrc
in FLAGS
of the Makefile gets around this.
haha!
look so great!
SkJACK is now headed in the direction of the Plugin Manager.