The only way I currently know to modulate the depth of a CC LFO is by physically wiring an output into an input and “mapping” the value I want to modulate to the newly wired loop.
As this takes an input and output out of the equation, it would be nice to be able to “map” parameters to midi coming from a virtual port.
Yeah, that’s a good idea, we plan to add a sort of virtual loopback output pipe, as well as manual mapping parameter editor, so you don’t have to rely on MIDI learn for this use case, in a future version.
Good evening,
I’m wondering if there is any talk of development in regards to these features. I just got a MIDIhub and I’d love to use a 16n MIDI controller to control the Depth of some LFO generators but the 16n really only outputs 0 to 127 and when Midi Learn is applied to the Depth, the LFO very easily clips. I’m assuming it’s expecting 0 to 64 for input but for my purposes I’d love to actually scale the 0 to 127 down to like, 0 to 12 and then apply that to the Depth.
Update: I just tried using a CC Scale pipe after the LFO and using MIDI to control the Max CC value but even that encounters the same issue because the CC coming in is still 0 to 127, where as I’d like to scale the incoming MIDI and then pass the result to the mapped parameter.
Thanks,
Erik
You sure its mapped to the right channel? Im not sure how you have things set up but if you map a control straight to an argument, it will always be 0 to max. So if you want to scale that control, first you have to have a seperate pipeline doing a scaling then route that using a physical loopback. Then your mapped argument will respect your scaled range.
Yeah, that’s what I realized after stumbling onto another person using a physical loopback to modulate CC LFO’s from other CC LFO’s. In either case, it’s unfortunate that you’ll be losing two physical ports (the out and the in for the loopback) and Midi Learn isn’t a great experience. I’d prefer to be able to just tell the mapping explicitly_what_ channel and what CC value instead of using MIDI Learn, honestly.
In the case of the person who had the LFO’s modulating LFO’s, being mindful of disabling LFO’s being output to the loopback so the Learn doesn’t pick the wrong CC isn’t a great experience.
Edit: this is the other post I’m referring to.
It would be better but it is what is. Once you come to grips with losing 1 in 1 out it’s not really a big deal. Plug it in and you never have to touch it again. Mapping to loopback port is dead easy.
Don’t try to use the external control to map loopbacks, it is a bit wonky. Use a pipeline consisting of an lfo followed by a transform followed by your loopback port. Whenever you want to map something just set the cc in the lfo, or if you want to map notes or change channel set it in the transform and ez peezy. Bypass the LFO pipeline when you are done mapping. I use this exclusively to map loop backs and I have the arguments in the transform pipe mapped so i can adjust it quickly with a controller then map. It works great when doing a lot of complicated mapping.
Like Joey says, it is where we are right now.
The Blokas team have been aware of the need for and advantage of an enhanced mapping situation for some time. Having pondered on it for a while now, I suspect there are a range of complexities it opens up which they are determined to get right before they commit to what will be a big jump forward. (I won’t go into these now…)
In the meantime, you’ll need to decide for yourself; loopbacks open up a range of new capabilties for some, but for others they are a hack too far.
Made my decision when I twigged that a loopback allowed me to have amp & phase-modulated LFOs… (watch that sine wave wobble!)… where I could reduce the ‘modulation’ down to nothing if I chose by mapping the mappers.
(Personally, I’ll probably end up employing a Raspberry Pi to provide power, connect USB-only devices, and give me a loopback, solving the I/O issue)
btw @JoeyButters, nice call using LFOs to set loopback mappings. Should go in a Tips&Tricks Section
+1
this would be a game changer. checking in every once in while just for progress in this area.
seems half-baked without it. considering we have virtual pipes, self-patching is a weird waste of ports.
not that midihub isn’t a power horse already… so thanks blokas for the amazing work! 