Home News Store Community Docs
Menu

Midihub Pipes Suggestions

split this topic #2

A post was split to a new topic: [Feature Request] Changing presets using a MIDI controller

0 Likes
split this topic #3

A post was split to a new topic: [Pipe Request] Squarp Pyramid MIDI Effects

0 Likes
split this topic #4

A post was split to a new topic: [Pipe Request] MIDI Dispatcher

0 Likes
#5

Hey, registered your suggestions to the MH Roadmap.

  • 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.

  • 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.

  • Variable mapping - could you elaborate a bit how this would work?

  • 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.

  • 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?

0 Likes
#6

unfortunately, quantize is used for both time quantization and pitch/scale. (e.g. in eurorack, cv pitch is often put thru a ‘quantizer’) - equally unfortunately is the term ‘scaler’ is used to mean to apply a scale (quantize) and to do z = mx+y :frowning:

so id say you can chose either and its fine.
perhaps scaler for pitch, and quantizer for grid/time.

1 Like
#7

Hey,

I started testing the Midihub and wanted to chime in :
+ 1 for Velocity to CC !!
+ 1 for Note to CC, like a “keyboard tracking” CC, or to turn a melodic sequencer into a parameter sequencer !
Coming from modular, if any Midi message can modulate any parameter, that would be cool ! Of course, aftertouch, velocity, note number and so on are nice musical tools for expressivity so… the more the merrier !

  • A new pipe that I havent read about is a Clock generator. I don’t know if the Midihub has the ability to generate Midi message (instead of routing/modifying them)…

  • In the same idea, midi LFO (of CC or pitchbend maybe) or midi sequencer (in the sens of “writeable LFO” more than a note sequencer, but both are good :stuck_out_tongue: ) could be really interesting - but it’s probably CPU intensive I guess…

  • And a last one ( that would be extremely useful - for me at least) is Midi RoundRobin’ . Having the ability to route midi info back and forth (or “cycle” ) between two or more midi channel turns any “2 mono synth” into a polysynth - or 2 poly into crazy timbre poly. Or… there are things to be done, and not many option available in the market… (that I know of)

There were a lot of good stuff in the MidiPal from Mutable instruments, probably better explained in their manual than I could do here : https://mutable-instruments.net/archive/midipal/manual/
P.S. the idea is not to copy this device, but there is inspiration to be found in the “app” as they were called! It goes beyond the “midi routing duties” but still…

Thanks for the hard work!
Cheers

Maxime

0 Likes
#8
  • 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).

2 Likes
#9

The microtonal scales sound very interesting, at the moment it’s beyond my theoretical understanding, so it would be very helpful if you could advise us on how it’s best to be implemented from the user perspective, so we can get this right.

0 Likes
#10

I’ll look into it and report back. Happy you find it interesting :blush:

1 Like
#11

There is standard pitch system in Cent. One equal tempered semitone is devided into 100 Cents. They while devide the pitch difference in even parts.

To gain controll this deep would be awesome and make the MIDIhub the only piece on the market with this feature (… as far as I know…) and make many, many musicians and composers in the experimental or especially in the field of Neue Musik or electronic music very, very happy. And don’t forget about all the not equal tempered scales around the world and the people want to play them with MIDI controlled gear…

1 Like
#12

I’ve made some progress on microtuning. I’ll report back soon :slight_smile:
In the meantime @Giedrius please take a look at the only competition around:
https://hpi.zentral.zone/tbx2

and please check this page out : https://hpi.zentral.zone/filetypes
It contains all the different types of files that we could use. Scala is the most important one, as a lot of people use the program to create microtunings.

2 Likes
#13

Is there any chance the CC remapping can be pushed a bit earlier? Honestly, out of all the suggestions I’ve made, I think this is one can be filed under vital. I can imagine a lot of people complaining that this is not an option in the device if it’s release without it. A typical use of devices like the MIDI Solutions boxes is to handle CC message issues and if you are to compete with that a remapping option is necessary. That’s my 2 cents of course, but I’m positive I’m not alone on this.

1 Like
#14

There’s been definitely a lot of great suggestions from you guys! Some of them will definitely make it into the product before the public release, it does take time to implement everything that was suggested. :slight_smile:

Right now we’re working on making the current pipe parameters controllable via MIDI messages, we missed release on previous week, but hopefully this week we’ll make it, so stay tuned! :slight_smile:

4 Likes
#15

+1 on this. found another ‘use case’ for it :slight_smile:

the squarp pyramid can send out a metronome beats on sent as note on/off on a midi channel
it sends the first beat of the bar with velocity 127, and others as 100, but same note value.
Id actually like to remap this to two different notes

(ideally, Id like to set it up so that they go to vey specific notes, for a sampler .e.g 100 C3 127 D3)

1 Like
pinned #16
0 Likes
#17

Would be nice to have the option to sync the LFO rate / resolution to midi clock / notes.

1 Like
#18

The LFO can already be synced to clock, and retriggered on individual notes or chords. :slight_smile:

0 Likes
#19

Oh great stuff. I had a look at the editor and could only see an option in Hz. How would one set the rate in beats?

0 Likes
#20

It has to be placed to the right of an input, in that case it shows additional options, that depend on incoming data to be available.

1 Like
#21

Great stuff, thanks. I see that now.

When I was exploring I’d put the LFO first in the pipe so I didn’t see the other options. Thanks for clarifying :slight_smile:

1 Like