So I had this big idea for a script that sends program changes and modulates MIDI CC for the smarter members of my pedalboard, and this is its teensy little shadow. The sketches are still in my notebook, and the code is buried somewhere in my brain, but in the interest of incremental delivery I’m shipping it.
For now it will send program changes on demand and a single CC param can be connected to a single LFO. Changes can be made in realtime. The controls are minimal. It now sends and receives MIDI start and stop signals, however this feature may prove buggy under more robust testing than the author [me] was able to perform. It only includes two example device configs.
But if you have a Hedra or a Microcosm you’re set!
Add your own configs to code/geppetto/lib/devices, and be sure to back them up. Why not open a PR while you’re at it.
I have a bunch of code optimization to do. As more of it is refactored to classes, multiple devices and more robust per-device control mappings will be possible. Or this is all there will be. Maybe it’s enough.
Maybe everything is enough as it is. Or not. Send bugs and wants my way should they arise.
Requirements
MIDI
Documentation
K1 and E1 are unused for now. Navigate between inputs with E2, and select values with E3. K3 starts the LFO. K2 stops it. It’s clocked to the system. When the program change selector is active, K3 sends the program change command (as opposed to starting the LFO). Selecting a new device to control will stop the LFO and clear the control and program fields. Everything else can be edited while modulating. Keep in mind that some CC numbers do stuff like enable preset recording and whatnot, so exercise caution .
Updates
v0.1.1 Adds support for outgoing and incoming midi ‘start’ and ‘stop’ events [alpha]
This is great - I’ve been thinking about exactly this sort of utility, but have barely any coding skills at present. Nice one.
I also coincidentally connected a Waldorf Rocket to a Norns Shield for the first time today, so I’ve been working on a config for that, which is interesting to explore.
Nice!! I`m adapting it to control Nemesys delay and Strtmon Bigsky.
Wolud be great having more LFOs available, are you planing on some new features?
Thanks!
Roadmap is such that multiple devices can be instantiated, each with its own LFO against which multiple CC addresses can be modulated. Additionally, more fine grained control of the LFO, such as beats and free clocking. The original intent was to be able to plot CC along the breadth of a given LFO. That bit seems like the biggest stretch at present.
this sounds awesome I’m going to see about using norns <> continuumini with this!
if you end up adding the ability to trigger things like notes or buttons/toggles it would be pretty interesting.
I’m thinking of using the same LFO for the momentary/toggle behavior but you would essentially have a set of thresholds/comparators that you could define their spread along the LFO as well as density. The spread would define how many of the thresholds are being used so something like 0 - 8 and then the density would be able how tightly grouped together the trigger zones are from even spread apart to all kind of packed together in the middle.
There was an old M4L device that did this and I forgot the name of it but it was so much fun to use as a manual control for things like drums but I bet sequencing parameters on/off with this would be pretty fun too.
The idea of using your main modulation LFO here for both things could be a neat way of intermingling modulation. However a second LFO to drive this would also be welcome.
just thinking out loud regardless this is rad! thanks for all your work here.
Yep, there’s already a stub for start and stop, but I was waffling on details and decided to pull it from mvp requirements. I think I’ll have some time this week to tinker. Start and stop independent of other considerations is a light enough lift to ship in an evening, but I’m eager to get multiple device and lfo instantiation settled. I may just move lfo controls to params and allow cc addresses to be pinned to them arbitrarily in the device config rather than given lfos being properties of the devices themselves. I worry that something is lost in playability with that design choice, though—in contrast to the ballooning scope of more granular control of multiple lfos within the app surface.
shipped two-way midi start and stop this morning. if you run into any issues please let me know or raise an issue on gh. next up is multiple devices/lfos.
.