Hi all, I’m a new Midihub user, trying to wrap my head around it. Sorry if this topic has already been discussed, but I didn’t find a relevant thread.
I have a specific requirement for a current project: I need a 14 bit unipolar LFO. I want to use this with Meng Qi’s Wingie2 to control the “mix” parameter, which uses CC 11 (MSB) and CC 43 (LSB). Can someone point me in the right direction?
Regarding the LFO, it appears that the “CC LFO” generator is implicitly unipolar, since MIDI uses only positive numbers. Am I understanding this correctly?
I saw a post that @Giedrius made a couple of years ago with a “CC to NPRN” patch, but I don’t understand it yet, and so I don’t see how it could be adapted to modify LFO output.
CC is like measuring up the street in metres
RPN is like measuring in metres and centimetres
This means that you can send a coarse mix control to Wingie2, by sending a variable CC11 and a fixed CC43† (say = 64).
Maybe try this first: if it doesn’t sound “steppy” to you then 7-bit will do!
† it maybe that Wingie will only play ball with both CCs being sent each time. maybe not
Thanks. This matches my understanding of how 14-bit MIDI works. I just tried your suggestion using a Launch Control XL, with two knobs set the the MSB and LSB CCs respectively, and this does actually work. For what I’m trying to do, changing just the coarse control is probably sufficient. Thanks for the suggestion.
Yep, just connected an LFO to CC11 and it worked just fine. Since I’m just using it to slowly shift the mix between the input signal and the effected signal, using the coarse settings is enough to do the trick.
I still would like to be able to use 14-bit at some point. It would be great if NPRN support was baked into the firmware, or maybe just had some NRPN-aware pipes.
would be interesting to know if @Blokas has anything cooking on this.
Imagining a RPN LFO, One of the things is the Resolution property:
I guess the 128Hz max LFO res is there to prevent event logjams.
But at that max res, a “full-resolution-cycle” would take over two minutes!
I can’t go too much in depth right now but with rescale pipes you can send 2 different CC’s that increment at different values but controlled by one user input. It’s totally feasible to create an exact representation of a coarse and fine control tuned to however you want it to feel.
Quick out of my head sketch,
Pipeline 1
Transform pipe= “work with” CC (11), insert after, transform into CC 43 channel(X)> Virtual pipe // This should output CC 11 and 43 with CC 11’s value.
pipeline 2= virtual pipe>channel filter>rescale>ch remap>out to hardware
pipeline 3= virtual pipe>channel filter>rescale>out to hardware
Yeah, the tricky one though, Joey is to get the 43 to sync with the 11 so that it’s not only producing 4, 8,…128 values for each 11 but also going in the same direction (up or down) as the 11.
I did study that a few months back for a very smooth (unsteppy) ZOIA input, but my cold-ridden brain can’t retrieve more than this image right now…
auto-increase/decrease two interlinked CCs like this:
… and a memory that the end-need would have to be seriously important cos it entailed a lot of looping pipework for each control!
Hey, Dave, check this out if you haven’t done sthg like it yourself already: SlowMeanderingLFO_1.mhp (780 Bytes)
It’s a ‘work in progress’ that will one day come off the back burner and get onto patchstorage as a compendium of slow LFO techniques.
The main (possible) point of interest for you is the first 5/6 lines; very slow LFO’s by using dedicated slow Clocks withTempo Dividers and the LFO rate set at bars.
It will go as slow as 8bars/5bpm → >30mins per cycle!
the remainder of the patch ...
is using loopbacks to add strangeness like phase-modulation to the main LFO and other weirdness. Those can just be deleted to leave a more vanilla output.
If you want to get more wacky there’s a later version that uses Transform → Chance → Transform
to drop a certain mapped proportion of the Clocks to give even slower, randomly ‘stretched’ sine waves.
This ensures that two such modulations of different “corrupted” periods never quite re-align.
Thanks guys. Lots of inspiration here. @resonotter, I will check out your code. @JoeyButters, this makes me optimistic that what I ideally want is possible, but clearly it’s gonna take some work. I may tackle the problem when I get some time time get more deeply into pipes and pipelines. Longer term, I still think that Midihub would be improved by having native support for 14-bit.
I can imagine an approach where the coarse (or lead) LFO would trigger the fine (or follower) LFO at each point, but in this scenario the fine LFO would need to be something more like just the rising or falling portion of the waveform (eg upward or downward ramp in the triangle case). In other words, the fine LFO would do a complete rising or falling portion of a cycle for each point in the coarse LFO. I don’t know if this is currently possibly with Midihub.
@resonotter Hmm I see. For a more exacting control, transform pipes with work with range should suffice. Example range 1 through 4 equals 4, 5-8 equals 8. It will take quite a few pipes to map out all the values but that’s the super easy way.
The more complicated way would be using double loop backs and rescale pipes, which would reduce the pipes needed but much trickier to setup. I’ve done this in a few patches but not a big fan of it because it’s hard to keep track of what’s what, but it is way more efficient.
Edit: From the chart I see you would need one CC going in the opposite direction Am I right? If that’s the case it would simply be a matter of assigning values in the opposite direction so 1-4 would be transformed to value 60 etc etc.
With transform pipes you could theoretically create any type of corresponding scale that you can think of, linear or non linear.
where at resolution=0, it’s just a plain old CC (many Pitchbend wheels/strips are effectively resolution=0!)
whereas at resolution=2 there are 4 LSB values for each MSB value.
Trying to emulate this is decidedly tricky; the MSB is easy with just a Rescale but the LSB needs a pipe to have some idea of remainder/modulo. An easy notion but no pipe provides it (apart from Dispatcher to an extent!)
Now, given that most folk don’t have controllers that will output 14bits but there seem to be an increasing number of devices that use them, there may be a place for a pipe like this.
Of course, there’s a trade-off: the higher the resolution, the smaller the MSB range. But I would be surprised if many synths have properties where “steppiness” is off-putting at even 9-bit level (resolution=2).
And thus to have a (128/4 =) 32 MSB value range at that resolution could be quite acceptable and useful.
Going this way would then allow @DaveSeidel to run a standard LFO into the pipe, get RPN pairs out (and then Rescale the MSB or utilise a Min|Mid|Max property built into the pipe)
I’ll have to think on that, but it probably makes sense. However, I think this just makes a stronger argument for Midihub to provide a more “native” means to produce 14bit without having to jump through hoops. That said, I found that for my particular scenario it’s been sufficient to just use an LFO for the MSB and ignore the LSB, especially at a higher resolution. But I’m sure that in other scenarios, such as dealing with pitch, 14bit precision would make a big difference.
Ok I get it, it is more clear now. I see it’s a challenge but I have a few ways in my head already. One trick I 've used for some slightly similar hurdles is using the transform>harmonizer>transform to multiply a CC into multiple CC’s at exact values. I’m also thinking about a rescale pipeline that is mapped to the channel argument in a transform pipe. CC1 channel 1 could output MSB1 LSB0, then Channel 2 could output MSB0, LSB64 . The problem is the amount of pipes it would take for each value. Doing a full 128 is probably not practical without doing some rescaling and relooping.
Yep.
I don’t think the two things are exclusive.
The above would be a Modifier, yours a Generator (using the language of the Pipes panel)
(My table graphic was primarily to illustrate to Joey that to modify a sequence of incoming messages to an RPN output, you’d need to bear in mind the interlinking of the MSB/LSB)
I’d like to have both!
(As a technical thing I wonder whether or what property would be dropped in an RPN LFO to make it ‘fit’ the 11 bytes?
My guess is on most rates & resolutions, an RPN LFO would end up only giving a small subset of LSB values as a by-product of the 128hz resolution)
