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