Reliable interval output after Dispatcher pipe

Hi Midihub newbie here. Such a incredible device this little box is. Kudos to the devs. I’m trying to build the seemingly ever elusive strum. My attempt is to simply use

Pipe line 1-Dispatcher to split chord notes to different channels- ch filter 1- output
Pipe line 2-Dispatcher- ch filter 2- ch remap 1- delay 100 percent wet- output
and on and on

I can manage to make this work consistently when I know exactly how many notes are in the chord but if there are more or less notes, then the outputs are not consistent.

The output that I need is 1st note is always CH1. 2nd note is always CH2 regardless of how many notes were in the input chord. I am thinking there’s maybe a way to multiply the variable chord so that every Dispatcher always receives 16 notes thus filling all the channels and no cycling. I haven’t yet thought about how I would discard the extra notes though.

Any suggestions appreciated, Thanks.

If I’m able to make this work the strum possibilities are endless as one can have different note intervals in a strum at varying delay rates, lengths, velocities and or probabilities, all mapped to a midi controller OH MY!!. I drool every time I think about it, but I am not yet over this particular hurdle.

Any suggestions appreciated, Thanks.

Hey @JoeyButters, pretty ambitious stuff for someone who describes themselves as a newbie!

I don’t know if what you’re wanting is possible at present. Without seeing your current development patch (upload it - it might get someone thinking…), my best guess at achieving what I think you want is rather clunky and would involve a some controller telling Midihub how many notes are in the next chord before you play it. Not very ‘natural’!

PS. thx for the like on Fluid Tempo Changes; I’ll post up my first ‘proof of concept’ soon (for what it’s worth!)

1 Like

Alright, getting more familiar with the Dispatcher pipe, I realized turning it off and then on will start the cycle from the beginning. If I can somehow turn it off and on again, after sending the output, then the intervals would always be sent to the same channel regardless of how many notes are input.

(Side note feature request= option to turn off the cycling aspect of the Dispatcher pipeline)

My current idea is to have a pipeline that converts note ons and note offs to a cc, then map that cc to the Dispatchers bypass in each pipeline. Is this possible through internal pipelines or would I need to do a physical loopback?

Is there a page/window in the editor for editing cc mappings?

Not sure I’m getting my head around this, but do you need to turn off/on after each individual note or after the batch?

General rule is if you’re ever needing to do anything to change an event before it maps (eg. Transform to a CC/ Rescale to represent the range of modulation you want) you will (currently) need to use a physical loopback.

This is linked to your last question; mappings are (currently) always set up by a MIDI learn approach (so if you need to physical loopback, you will need to set (or reset) mappings by temporarily hooking up direct line in to set them via an external controller before reverting to the loopback to update the mappings by processed events returning to the physical loop in).

If you look at the patches posted today in PC to CC question, the loopback there is used to allow settings to be changed after the current event has passed through.
In the patch referred to here – Saw Returns to First Value on One-Shot! – I was using a loopback to process a mapping value created at the end of a One-Shot LFO cycle. This sort of idea could be used to bring a time element into your switching.

I must say, this notion of using mappings to switch off pipes sounds interesting for your aims. At this stage in the evening, I’m not seeing immediately what would switch them back on again…

My aim is to reset the Dispatcher either before the chord or after the chord. In the first incoming chord, the notes intervals are always the same channel because it hasn’t cycled down a channel yet. Resetting bypass before the next batch of notes hits the Dispatcher ensures that the lowest note is always CH1 and next higher is CH2. In this manner, it doesn’t matter how many notes hits the Dispatcher because after the reset, the lowest note is always in CH1. So from there, I can split the chord notes out to individual delays, etc.

I am 98 percent there. It works perfectly except only with a external mapping. I accidently hit a note while setting the mapping and was pleasantly surprised when the bypass went on then off as I let the note go. From initial testing, the note(note on) will go through before the bypass is engaged and then will turn off when the note(note off) is released.

My only hiccup now is I want to make a seperate (silent)pipeline that will transform all incoming notes into C-1 or a CC# and then send that through the Dispatcher pipelines to toggle the bypass. I have it going through the outputs of the dispatcher pipelines( I can see the note or CC in output) but the Dispatcher bypass is not responding directly to the CC number mapped. So Im wondering if the editor mappings are tied to device ids as opposed to just raw note or CC#?

I just uploaded the current state of the patch. It only works for triads in this state as I don’t want to duplicate the full 16 channels until I can lockdown the mapping for the bypass.

The transpose pipeline is just there to correct an issue I had with MPC pads midi out getting canceled by the same input coming back in on another track, so I have to transpose notes to get midi to the sound generator

Triad Strum.mhp (634 Bytes)

Haven’t spent very long looking at your patch, but here’s a couple of observations


  • MIDI D-out looks like it’s the only physical out, but
  • Dispatcher in line3 looks like it’s mapped to D-in using events created and sent out of D-out, so
  • seems like you either have a MIDI splitter or you don’t have a physical loopback (ie a cable going from D to D)


  • you could use a single (mapped) Dispatcher in line3, then
  • pick up the output in several similar virtual pipelines, each of which filters all but one channel, then does it own magic
  • then bring them all together for a final Channel Remap (if that’s what you’re after)

This has the advantage just having one mapping to maintain and hives off the different aspects quite nicely. (the final Channel Remap also allows you to generate new stuff from 1 of the ‘channel virtuals’ which can go to a different channel or device)

The main reason for posting is next…

OK this is what kept me from sleeping:
Your discovery of the effect of turning the Bypass On & Off is, to me, a bit of a revelation.
Think of combining it with this:
NoteOn_CC_trig_LFO 05.08.42
Here we see 3 notes where the

  • NoteOn creates a CC which
  • triggers 2 One-Shot LFOs (Saw Down, 180° offset)
  • where one has double the period of the other

Note how the 2nd and 3rd notes re-trigger the LFO before they complete their cycles.

And there, with some sneaky use of Transforms for the last few CC values (say 7–>0), is your

  1. “I’ve finished playing my final note of this chord, now Bypass the Dispatcher” (the short LFO) and
  2. “We’ve waited a bit longer, now let’s turn the Dispatcher back on ready for the next chord”

Setting it up will take a little care and it’s not foolproof, but I think that might give you what you want.

PS. This pic shows why you don’t want to use Notes to directly trigger the LFOs
NoteOnOff_trig_LFO 05.09.57

(though you could filter out the Note-offs in a separate pipeline)


Two issues that I can think as of now:

  • Need to set the LFO rates up for a certain style of playing, with the shorter Dispatcher-Off one obviously set to be a longer than the time you press Note_on for all the keys, but
  • Dispatcher, when left on, is clever enough to keep track and send the Note_offs to the correct channels. Turning Off & On disrupts though, so
  • decisions need to made about your playing-style, LFO rates, use of multiple Sustains, or all three!

I am using a physical loopback in sorts. But the loopback is from track 1 to track 2 in my MPC, so not for doing any midihub extra processing except transpose.

I was playing around with your awesome LFO suggestion but then I had a EUREKA moment!!!

Unfortunately, just mapping notes to the bypass did not work as I had thought because it does indeed turn off the pipe before the notes passed and were not split to each channel. I decided to see what the Dispatcher behaved like if I note mapped to CH1, or CH2 or CH3 of the Dispatcher individually with all other 15 Channels pre-activated.

Low and behold, turning on at least 1 channel will also reset the Dispatcher’s cycle!!!

If I have channel 3 deactivated, with all other channels activated, a mapped note on will activate channel 3, Dispatcher will split notes, then on note off, Ch 3 will deactivate and the Dispatcher’s cycle will reset (or when first activated, I can’t tell).

It works like 98 percent of the time. Sometimes after rapid playing only 1 note will sound but will be fine on the next press. I’m not sure if that’s a delay pipe, sustain issue or what not.

I’ve feel like I 've stumbled onto the holy grail because I surmise that this will help steer a lot of other posters inquiry about splitting and polyphony.

The very last hurdle is mapping though. The only way I can currently successfully map is mapping notes from hardware to midihub, which I means Ill need to map every note on the keyboard for all 16 Dispatchers. That seems like a lot of data and I would think, likely cause problems. I want to transform all incoming notes into a C-0 note that I mapped to the Dispatchers through hardware but I’m guessing that mapping is tied to a device id because sending C-0 through the pipeline doesn’t trigger the mapping. I wondering if having a pipeline that takes “D input” transforms all notes then sends out of “C output” to “C input” would suffice to trigger the mapping.

I thought about using only one dispatcher but the virtual ports are limited. It’s not enough for 16 channels and I want to reserve as many as I can for post processing effects. Its unlikely I’ll ever send a 16 note Chord but if I do I want it to work lol. I’m actually thinking about reserving 4 channels and turning them into a bass note/s or a high octave for chord flavoring, but that’s a few steps into the future.

Arghhh! Sooo close. I mapped all keyboard notes to 1 Dispatcher channel then duplicated the pipeline with mappings. After 4 duplications I get a mappings are full message. I thought/hoped mappings were unlimited. Up to 4 note chords it works flawlessly and theoretically it would work with 16.

I’m thinking about a way to use one Dispatcher without using up all the virtual ports. I’m sure sending the dispatcher through a loopback and then making separate pipelines/ channel filters for each note would give me all 16 channels to work with, but I’m trying to avoid loopbacks for now.

I really need to wrap my head around what is actually being mapped. Is it (A) message from (A) port or is it (A) message from (A) device. Loopback is the very last resort, as I’d like to keep other physical ports available and I wonder what additional latency it would add.

Edit: I was thinking as I was typing this and trying to parse some info Resonotter said earlier about using one dispatcher. It just hit me that there is no reason to use multiple dispatchers as I can filter the channels After they go through a virtual port. I think this is the finish line!!!

Uploading a mostly working version. I am so mega impressed by Midihub. With the right set up this thing could blow the Karma engine out of the water as an strum/arp. If you could map parameters internally, there is nothing that could touch this as a creative design tool. Maybe it can map internally already. I’m just getting to know what it can do. I am dreaming of doing pitch bend/modulation articulations and bass slides. SO many possibilities!!!

Ultimately for the finished strum preset I want random/modulated, but limited, time delays to each note. I also want to add some humanization to the velocities. I’m worried I may not have enough pipes when it is said and done. Also I need to map parameters to a controller. With limited mappings I’m going to have think conservatively about what’s ultimately most important to be able to use in real time.

The sustain pipes have been somewhat problematic though. I’m occasionally missing note messages , so the next single note/first note of chord may not play until you press it twice. Without sustain it works flawlessly every press. Still experimenting there. I do find it adds variation to a chord progression when some notes are sounding so that could be useful, but first and foremost I’m looking for flawless control.

Mega Strum.mhp (2.6 KB)

Hey @JoeyButters, can you upload a .mid file of a short bit of playing, so I can see how you’re playing (speed, gate, etc - include the bpm pls!)?
Ideally both the raw and “post-Midihub” versions if that’s possible but either would help me what you’re trying to get flawless.

PS. It’s 6am here so I only glanced at your recent. Will get my head around it in a few hours.
(I like the sound of the switching a single channel though; good finding!)

But, if you keep your processing of extra channels to given virtuals, you effectively won’t be using them as far as any external is concerned. (I have one patch that uses 14-16 for mapping control, but none of it gets outside the box)

Karma=Korg Karma from 2000?

PS. the way you’re going you will need a 2nd Midihub!

Korg Karma yes. It’s also on the newer Kronos as well. Likely the most complicated arp in all history of existence that no human will ever master .

As far as playing style. So my particular use case is with the pad perform progression mode in the newer MPCs. You can have tens of thousands progression presets that assign a note or/and chords to each one of 16 pads then send out midi. The problem though, is it just plays the chord notes lifelessly, on the same tick, at the same velocity. So I’ve been literally searching for years to make it useful. Ipad apps and vsts are okish but I wanted a rock solid hardware solution, without hiccups and bugs and cables, latency etc etc… This is why I’m so excited about this box because once the midihub is programmed I can map parameters then control the strum/arps in real time straight from the MPC.

There’s been this long running hilarious kerfuffle about the Akai MPC not being able to do Flamenco. Now with the midihub it sure as heck can lol !!

Here are some midi files. Just a chord progression, then with strum, strum arp then strum tweaking real time.

Base.mid (353 Bytes)
Strum on.mid (429 Bytes)
Strum plus arp.mid (811 Bytes)
Strum adjust.mid (402 Bytes)


Thanks for the files, Joey.
Seeing how the base notes are played fitted quite well with how I started to think about the LFO idea since my first suggestion (of 2 LFOS with different periods).
this is the Loopback part: MegaStrumLFODispatchLoop.mhp (460 Bytes)
this is the whole patch which I’ve tested briefly: MegaStrumLFODispatch.mhp (1.6 KB)
(The old bits have only been adapted slightly - note the CH Remaps have been replaced by a single one on the out. Oh. and the Dispatcher Mapping is able to be simpler under this approach. Oh, and line6 shouldn’t be there!)

The key to seeing that it might work is noting that initial gate length is not that important to you and that the gaps between chords is constant.
Accordingly, I set my LFO to run over a 1/4 note with a Dispatch-Off Map being sent in the last 16th and the Dispatch-Back-On in the last 1/32.
To help ensure notes had ended before these kicked in, I shortened your base notes slightly.

Here’s the Base (below) and the Straight Dispatch (w/o Channel Remap) above:

Note the Channel Colours show channels are behaving despite different size chords

And Here’s the Strum version:

(The only surprise here to me was the double note in the Channel 2. I note this is the only Delay with a Dry/Wet < 100%. SO I guess that’s the original being cut off by the repeat. I live & learn.)

Two things before I sign off for a couple of hours:

  1. the Work with Value in Range Low|High has a critical relation to the Resolution and Rate of the LFO. These in turn may have a bearing of the system resetting itself properly before the next chord.
  2. If it was possible within your setup to have a button/ control to set the note Length then it’s feasible to forget about your note-offs and set up a Note Length pipe mapped to the same control as the LFO Rate with the Note Length Gate set at say 70%

PS> I made up a schematic to help make sense of the Loopback to myself (easy to get lost). If you pick this up before my return, let me know if that would be of use


Thanks @resonotter for all the assistance and feedback. It’s been a huge help!

I’ve been testing out the LFO for a few hours. It’s hard to get the right response to give consistent results when playing faster or slower. At a steady consistent input interval it works great. The actual playing pace would be more improvisational though and often chord inputs could be back to back. I’m definitely going to adapt this pipeline to a modulation/pitch bend pipeline where a steady pacing is likely to be preferable.

I’ll likely stick with a note on for now to ch1 as this has seemed to be the most rock solid never fail part of the part of the patch. Loopback looks like a much more elegant solution for creating the mapping . Your LFO map pipeline also sparked a few creative ideas on how to drop notes out of a strum, playing it backwards or the one that makes my brain tingle the most, playing the strum forward then playing it backwards. More wonderful tinkering ahead!

1 Like

Yeah, I think the best the LFO loopback can do consistently is to have the rate set to something short like 1/16T which should allow a variable pace of play, as long as you can accept either

  1. short, stabby chords as input or
  2. having the note length set by Midihub so you don’t have to worry about the Dispatcher closing down before the Note Offs arrive.

Sounds very intriguing*.
On a more mundane level, my mind was wandering to thinking about using the loopback (or successive C_out-C_in loops – makes it easier to keep track of your anti-feedback filters) to introduce modulations to the individual delays based on

  • pitch/velocity of notes (mad fun also to be had with setting off Harmonizer>Arp>Chance>Scale Remap flurries using notes from say 1,2,3 based on the velocity of note 4)
  • or in response to say an expression pedal.

. * feel free to msg me any examples of Work in Progress. Cheers!