I am new to Midihub but have a reasonably good understanding of programming in general, so the whole block matrix is not too intimidating. But there is a preset I’ve been trying to make, but just can’t figure out how to do.
I want to be able to receive a chord from an input, and then split that chord so that the lowest played note is sent to Output A, the full chord as played to Output B, and then the three highest notes through an arpeggiator pipe to Output C. But I cannot find the correct pipe to filter and prioritise single notes within a chord? I am sure I am missing something obvious here? Anyone with an idea how to achieve this?
The Dispatcher pipe seems to not be able to prioritise notes, just randomly split a chord onto different channels.
Yeah, I agree @Claire_Upz , interesting and something that would find a lot of takers.
Like you, i can’t think of a way of doing it at present. My hunch is Currently Not Possible as it goes beyond the single-event-in model and would therefore be departure from the current approach as it would entail making a real-time comparison of a collection of events.
Unless we’re wrong, @Jarly , maybe post it up as a feature request?
PS. Going on from Claire_Upz’s suggestion, Jarly, the only workaround I can offer is to have your lowest note being played say 2 octave too low so that it can be filtered then transposed to re-constitute your proper chord. Hardly natural, I know, but it would allow you to do what you want.
Thank you both for these thoughtful answers @resonotter and @Claire_Upz, it indeed seems more and more like a feature request and something that is not possible atm.
I envision a pipe with a three simple options: include or exclude, begin selection from low-high or high-low, and finally how many notes to select. I might be wrong, but should be fairly straightforward, as it’s just sorting the array of currently playing notes based on note number and applying the inclusion/exclusion filter from there.
As for the workaround of specifying ranges as you both suggested, while it is some kind of workaround, it also defeats the purpose of playing a single keyboard with two hands while splitting it into bass, chords and arpeggio.
Yep, if I imagine mocking up a simple solution using python.mido, for example, I’d want to specify a max msec/ppqn period that would define a “chord set” then apply the arithmetic & branching to various midi_outputs.
And there’s our departure from Midihub v1.x; we have a many-in/many-out scenario!
For now, Midihub is entirely one-in/many-out; no none-in/many-outs either!
My hunch is, the Blokas crew have already thought of this but are only going to bring out a suite of many-in/many-out pipes when they can get that extra functionality & generality without making Midihub a coders-only device!
Actually there are already pipes that work based on time passage and consider many previously played notes, like Sustain in its Chord mode, or produce events without prior input, like CC LFO or BPM.
The tricky bit with this ‘note priority’ pipe as others call it is to get it just right to meet everyone’s expectations. What I’ve found when discussing it is that people have slightly different vision of how it should behave in tricky scenarios. We might implement something eventually though.
It’s that generalised issue of combining (let alone comparing!) multiple events that sometimes crops up when I’m building patches (ie. when I start thinking in aX + bY terms). Sometimes I’ve been able to shoehorn the scenario into an LFO Passive Mod solution but I sorta yearn for a CC mixer!