Midihub Pipes Suggestions

I am open to both, so a toggle would be best IMO.

As long as the UI allows to set arbitrary list of numbers as the output chord. I imagine two columns in the properties pane: incoming note, output note(s). Maybe that toggle switch too.

The only other desired feature would be to allow input as note number and/or note string (“c#4”). Same for displaying the data, but you have this in place for other pipes already.

What UI do you have in mind?

Hi all, just setting up my new Midihub for the first time, excited to see what I can do with it.

Apologies if I’m not using the votes for features correctly, not quite sure how to vote for a specific feature request in a post that has several suggestions… (if I’ve missed something please let me know :slight_smile:

As has been mentioned above a couple of times:
Velocity to CC please.
I was a little disappointed to not see that in the possible transformations, it seems like a pretty fundamentally useful one to me!

Also a suggestion - in my initial setups, I’m doing quite a lot of channel filtering. Say I want a pipe to only operate on events that are on channel 16 (for example). Rather than having to make a channel filter that discards 1-15, it would be convenient if I could just say ‘select channel 16’ - it would do the same thing, but be faster and more intuitive to work with, imho.

Anyway - thanks for a great tool that I’m looking forward to diving into…


This feature is there!


For that, just use a Channel Range Filter and set the range to ‘16’, untick the ‘Drop In Range’ argument, so it only keeps messages in Ch. 16.

1 Like

Haha thanks so much for pointing out my error - great news. I misunderstood the documents and didn’t try it yet - THANKS and sorry to bother you!

For that, just use a Channel Range Filter and set the range to ‘16’, untick the ‘Drop In Range’ argument, so it only keeps messages in Ch. 16

Great, thanks so much, again sorry to bother you with simple questions!

While we’re at it, @Giedrius is there a way to have an external string of messages define the notes being allowed through the filter?

I’m thinking of the very practical, very musical example:

Plug a keyboard on one input of the Midihub, plug a sequencer on a second input of the Midihub, play a chord on the keyboard. The notes on the chord define the “scale” which the notes of the sequencer play in, by essentially quantizing incoming notes to the chord notes.

It’s not exactly filtering, and it’s equally musical to @Adomas’s suggestion, so I’m wondering if there’s a way of doing this already or if we need a new pipe for this.

Your thoughts?

PS: if we need a new pipe, there should be a toggle option for whether the incoming chord toggles the scaling or if it only happens while notes are held.

Hi, I’m also a new user, and I can’t find any way to transform note velocity into cc messages either!
I just updated to the latest editor and firmware released yesterday. I did manage to program some other cool stuff today though, like mapping a certain cc# to program change, and selecting and triggering different sample slices with midi notes to my octatrack. Powerful stuff, but this one velocity thing has me puzzled.
Here is a screenshot of the setup for the transport tool:

cheers, Oskar

Like a logic “AND” gate for midi note numbers?

I like the idea, but I think it’s different use case, than note to chord mapping

You could use a sustain pipe, but a toggle would be user-friendlier

I don’t understand that. The screenshot i posted answers that i would think!?

Oh sorry if I was unclear. Yes your screenshot makes it perfectly clear where to find it. But my problem is that I don’t have Note velocity as a choosable option within the transform pipe, and that’s what I tried to show i my own screen shot!
Here it is again:

i just noticed it disappeared in the latest version of Midihub editor. I used 1.11.2 until now.

See the explanation for Velocity to CC here: [Download] Midihub Editor 1.11.3 & Firmware 1.11.5 :slight_smile:

1 Like

with the new version you need a transform node setup like this to translate Note On Velocity Into CC 71


Not exactly AND, more like quantization based on the incoming manual chord. I get why you’re thinking Boolean though, but it should quantize the incoming notes based on the chord, not allow them only when they fall on the chord (which would be the AND scenario).

And yes, very different to your chord suggestion, but hey, think about it. You can use one keyboard for both: plug your keyboard, set it so that each note plays a chord, then have the outputs of the chord go back in another pipe, define the scale, and then the incoming sequence gets quantized based on these chords. So … one note scaling!

1 Like

I would definitely like to see functionality like this, where the notes present in one midi pipe would set the note pallette (chord, or mode) for the notes being processed in another pipe. If the defining pipe is processing a keyboard, then you’re effectively playing the notes that the rest of the system can use. There’s also the possibility that these notes can emerge from some generative mechanism and evolve over time for generative chord progressions … yeah, this sounds like an exciting idea to me :slight_smile:


A request for the variable like that is my main feature request now.
The use case for me is descibed below. I would need only one variable inside the Transform pipe.
The case is to trig CC values to record them. Until the notes I play give me the values I want, the Midihub is doing great.

I use a lower part of the keyboard (notes 00-63) to play and record the notes and add and record the values for CC10 (00-63) before each Note ON message with Transform pipe (note number = CC value). The values are next rescaled. Easy.

But I also want to use the higher part of the keyboard (that gives me values 64-87, for the notes and other CC values) and trig CC10 (again, before Note ON) with the last value set in pipeline#1. To record it.

Example: I play note#12, it is transformed to CC10=12 first. Then I want to add CC10=12 while playing notes#64-87.

I don’t know how it could be implemented. One variable (per preset) in the Transform pipe please.

Let me know if I miss a workaround. Thanks.

Edits: spelling, grammar.


It would be great to be able to work with more than 1 variable. What I am trying to do right now is some sort of on/off foot switch with only simple 4-button one which only sends PC events. With variables and some conditional type pipe (which does not exist yet either) I could persist the state for each of the pedal buttons and then be able to convert the press of the pedal button either to CC messages with value of 1 or 0 based on stored state.

1 Like

Proposal: A pipe that can delay the timing of program change (or really, any type of) messages.

Motivation: I have noticed that my Elektron boxes sends out program change messages sometime before a new pattern is started. When using this with other grooveboxes, there’s no problem since they all wait with implementing the pattern change until the last pattern has been completed. However, my PEAK responds to these pattern changes with patch changes that takes place before the pattern actually is over, meaning that the last couple of notes that are played on the PEAK belongs to the new patch.

1 Like

I’ve found myself wanting something similar. I often have a pipe full of sustained notes being distributed all over the place, but with a need to trigger their execution on the occurance of some other event like a note or a beat boundary. Whilst you can approximate this with delays if you know for sure when that event is going to occur relative to the time of origin of the note you’re hoping to trigger, that’s often not the case.
Maybe the solution to both would be a pipe element that captures a list of source events (Notes, ccs, PCs) in one variable, and then triggers their execution on the arival of a second defined event
In theory, this would allow notes from one channel to be triggered on the arrival of notes from another channel, or PCs to be issued at the next beat boundary, or any combination of source and trigger.
Maybe the best analogy would be the operation of a ‘gate’ in the modular world. :slight_smile: