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 
1 Like
with the new version you need a transform node setup like this to translate Note On Velocity Into CC 71
2 Likes
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
Phil.
2 Likes
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.
Pipeline#1:
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.
Pipeline#2:
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.
3 Likes
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.
I also would like to request a real-time quantizer.
All the note-on messages have to be stored into a buffer, and be delayed, and played if their time in the chosen grid comes. The grid size could be definite as a divider of 1, 1/2, 1/4, 1/8, 1/16 or 1/32 of the current 4/4 bar measure and BPM speed. According to a start message, the algorithm has to count the clock messages (ticks) to achieve this task.
Should be not that complicated to implement this very soon, because I need it very much.
Thanks to the developers.
2 Likes
real time midi quantizer, this would be a top feature. I am not sure but, could this be an evolution of the existing arp pipe with new specific parameters (?). An example: https://www.youtube.com/watch?v=2rZZAZSouik
2 Likes
Yes, you are right. This feature has not to be neccessarily a completely new pipe.
It yould be implemented as the extension of three existing pipes:
- THE ARP
- THE DELAY
- THE REPEATER
Clocked, aligned to grid note values could include, everywhere where applicable, the “dotted note” option, in arp, clock, delay etc.
1 Like
Hi all, I know that Note to CC is already implemented in the form of Note On to CC, but I’d love to also see Note Value to CC so that I could use a melodic sequencer like the Torso T1 to sequence CC values.
Currently I’m using MIDI Translator Pro to handle this, but it’s not ideal as I have to individually map each incoming note to a specific CC value.
I wonder if it would be possible to automatically map a range of notes (e.g. C3 - C5) to the 0-127 CC range, i.e. each note in a two-octave range would represent 1/24th of 0-127, each note in a three-octave range would represent 1/36th of 0-127, and so on…