- CC remapping can be done, maybe the āNote Remapā should be generalized or duplicated for more MIDI message types, as a lot of them follow similar structure.
I agree. I donāt see why having two different Pipes helps. A general Remap pipe seems like the way to go. Remapping CC messages is one of the things that are obviously missing in this version.
- Velocity mapping - good idea, this could also be a general āType Transformā kind of pipe which would allow converting Note messages to CC messages, and back, and to other compatible 3 byte MIDI messages.
Again, this seems to fall under the remapping area. If you think this requires its own Pipe, by all means, go for it. Ideally a remapping Pipe would include options to Attenuate/Expand/Revert the range, or generally to control the range of values that gets remapped. Since velocity can be reused in a zillion ways, maybe a dedicated Pipe is what youāre looking for. In any case, please consider this.
- Variable mapping - could you elaborate a bit how this would work?
MIDISolutions Event Processors allow for Variables. This way, if something cannot be mapped to something (like Velocity cannot in the EP series), you can grab that data and make it into a variable, and then grab that variable and use it for something else, like mapping.
Since you seems positive to the idea of allowing CC control over Midihub parameters, the idea of a Variable seems pretty decent. ie
Velocity > Variable X
Variable X > Midihub Parameter A
Variable X > Midihub Parameter B
Variable X > CC#
It would be handy in the occasions when there is no dedicated remapping Pipe.
- Delay event - makes sense, weāll have to see how we could get it implemented, this effect relies on time information for every MIDI event to be tracked by Midihub which it currently does not do, so it requires some work to implement.
I assumed that would be the case. But itās rather useful to be able to delay events by a specified time. This can be practical: sometimes you want a specific event to be delayed in comparison to another event. Like a tranposition NoteOn should hit before the actual NoteOn goes out. This could also be musical: depending on how you make the Pipe, this could be used to turn chords into strummed notes. Especially if you allow CC control of the delay times, this could get pretty funky.
- Rescale (Note + Pitch bend) - For me quantize means snapping the note events to a grid defined by the song tempo (implementation would also be subject to similar time keeping work as for Delay effect), so a different effect from pitch snapping.Could you describe how microtune rescale parameters should look like? Also whatād be the maximum note number per octave?
In terms of semantics: quantize can be any type of information being forced to a grid. That usually applies both to time-grids or note-grids. In this occasion, yes, scaling might be a better term. Letās keep Quantize for time purposes.
The idea is to tie NoteOn information with a specific Pitch Bend message in order to force a specific note into a microtonal scale. Microtonal buffs usually prefer scales that can do more than 12 notes in an octave, but that is entirely up to you. A first version could go for 12 notes. A second version could go for more, or even using Scala files to create scales (itās an Open Source program if Iām not mistaken). If this is of interest Iād be happy to look into a UI for this, which parameters it should have and so on. Some ideas could be grabbed from Scala, uTune module and the only other MIDI device that I know that can do such stuff (no longer available IIRC).
) could be really interesting - but itās probably CPU intensive I guessā¦
