Random Distribution of Notes to Pipes?

Hello all, so far I’ve been absolutely loving my MidiHub, I generally use it to introduce some randomness to my sequences. I can’t seem to piece my current idea together using existing pipes so I thought I’d ask. All in all, I envision setting up various pipe-chains that affect the sequence in certain ways (beat repeat / ratchet, arpeggiate, octavator, etc…). What would be awesome is a way to send (randomly selected) notes from an incoming data to one these pipe chains.

To be more specific, each pipe chain can start with a Virtual Port. So really all we need is something that can distribute note events to various virtual ports.

Any idea if (a) this is possible using existing pipes today or (b) it would be possible to prioritize this against existing feature requests?

(which has me thinking: is MidiHub open source? As a software developer, I’d very much be open to contributing features such as these)

1 Like

Hey, you can use the Dispatcher pipe to spread notes across 16 channels, and then send those channels out to different virtual buses. Some randomness could be achieved by placing Chance pipes. The dispatcher would work deterministically though, and would allow up to 16 notes through at a time.

A new “Random Output” could help increase the note limit and help with more random port selection.

Midihub is not open source, but we might include an SDK for the next iteration of the device. :slight_smile:


Request. Blokas! I got my midihub last week. I enjoy it, but it feels like it has to develop faster. I expected it to be able to randomize and alternate EVERY part of midi message. Logic gates and conditional triggers would also fit into the picture perfectly. Strangely, it is not implemented, but should be.

@eiccolor Would you give a couple of simple examples of this?

  1. Channel number randomization/LFO for Note On/Off types of messages is a simple specific example, I guess. It would be helpful to have a mapable choice between round robin, LFO and randomness for the channel number.
  2. LFO trigger that runs a cycle only IF two other LFO’s on other CC parameters hit >100 value. (More about conditionals then “mangling every part of a midi message”).

Maybe you can provide an obvious solution for implementing this, as you have more experience with the product.


Channel number randomization/LFO for Note On/Off types of messages is a simple specific example

Sorry, I don’t get this.

partial guess

Channel number randomization for Note On/Off.
I have a vague memory of Giedrius responding to a request for enhancements to Dispatcher.
This is where this would fit IMO.
We’ll have to wait/see whether he’s tackled this in eagerly awaited 1.14

don’t get this bit.
like a cycle through note channel remap according to what value an LFO has just produced?
If so like below but easier.

LFO trigger that runs a cycle only IF two other LFO’s on other CC parameters hit >100 value.

That’s interesting to think about how to achieve with current firmware†…

…but I take your point about wanting it to be easier to achieve via a logical AND pipe.

Have you given any thinking as to how such a pipe would look – in terms of what it’s property panel would look like?

Off the top of my head I’m picturing

  1. an “Input1” set of properties, a similar “Input2” set
  2. then an “Output” set of properties (same).
  3. Obviously a Operation property (AND|OR|XOR etc) would make the pipe more flexible

I ask cos I’ve not seen G pick up much on this sort of idea but, as a fellow enthusiast, it’s the kind of abstraction I’d like to ‘sell’ him on!

Maybe you can provide an [obvious] solution

† If you really wanna do this now, my hunch would be :

  • Transform (using Value.. Low|High) to create a “LFO1 > 100” condition
  • Rescale it via the 2nd LFO (emulates a multiply operation)
  • similar Transform to create a “both LFOs > 100” outcome
  • use result mapped to Trigger of One-Shot LFO3

This currently needs physical-loopback but I’m pretty confident G is going to make this easier
(you’ve seen that post )

1 Like

this popped back into my head @eiccolor with the extra thought:

“what happens when the next messages from the 2 x LFOs also satisfy the condition?”

So I guess the spec becomes

“LFO runs one shot on first occasion WHEN two given LFO’s hit >100 value”

then ‘re-arm’ condition when cycle complete?
Or only ‘re-arm’ when condition reset to FALSE by subsequent messages?

Rather more complex in both workaround and dedicated Binary Logic Pipe scenarios…