Sequential Switch: so a clock or other event could, either sync’d or unsync’d, switch between various pipes. The goal would be to be able to have one midi stream, say a melody line, swtich between various processing pipes - one might harmonize, the other randomize, another might add delay to one of the previous, etc. It would be great to be able to do this with or without sync, but also under cc control, which pipe gets chosen. Great product!
1 Like
This box is a lot of fun, easy to use and has a lot of potential, glad that i stumbled upon it!
I am not sure how much computing power or buffer the hub has but if this is the place to post requests, I have a few.
This is something that would be more than welcome, I actually assumed it was possible until i found this community page 
-The internal LFO’s can be set to modulate parameters within other pipes in the patch.
-Scale presets selectable via CC
The randomization obviously is great but it could be so much better if there would be be be a midi looper pipe implemented.
Trigger the looper module externally with a controller to start recording and it’s synced to the clock, divisions and length can be set by an external controller.
So once want some predictability just hit the looper and your randomized bassline for example turns into steady loop.
-Midi looper
-Step sequencer
Even if these things are possible only on an updated HW version I would buy one instantly.
1 Like
to modulate other parameters within the patch
1 Like
Oh, via Mappings?
1 Like
The Delay pipe can be used as a MIDI looper if feedback is 100%, using infinite repetitions, and keeping it in sync for every 1 - 4 bars. Map the overdub param to enable/disable writing to the delay memory. There’s a limit of 32 notes in a Delay loop at a time.
3 Likes
oh nice! thank you
1 Like
But to be like an actual looper, it must begin “recording” the notes at pedal down [assigned cc], and begin playback immediately at pedal up. Is this possible?
Thanks, Peter
2 Likes
You need two signal path for this :
- First signal is a pass thru = MIDI IN A → MIDI OUT A
- Second signal is the looper = MIDI IN A (use a cc to bypass the input) → Delay (time is the length of your loop Feedback 100% is your recording ON (if you use less than 100% you get a nice fade out parameter)) → MIDI OUT A
Your « pedal UP » CC engage the second path (enable MIDI IN A) at disengage it at « pedal DOWN »
Warning that this is a prefixed length looper.
An actual looper is a little bit more complicated since the repetition time is set by the timing between the record start and the record stop. And since nobody can hit a switch with a precision of few ms you also need a time quantification of you start stop messages on the midi clock.
1 Like
Thank you for your response!
Actually, I am not interested in Midi clock. no quantization necessary.
…Just a looper that begins when I press the pedal and stops recording and starts playing back when I press another pedal. then stops when I hit the second pedal again… Just like a hardware looper.
is that possible?
Peter
1 Like
Not really for now.
You can only have fixed length looper.
You start the recording, and it record X seconds depending on how you set it up, the overbub until you stop recording.
If you don’t have clock involved at some point, fixed length looper are not really usable 
But if you are looking to make friptronics kind of loops with lots of accident, you can try it 
I need to be able to type in the value of CC messages not just the CC message ID, the Korg Electribe 2 doesn’t work the same as other groove boxes and I can’t get midi hub to transform my messages correctly because of Korgs choice to put a lot of cc to a pad via SYSEX.
Chiming in 2 years later to say “yes, please” to notes!
I understand the limitations of the unit itself are probably the main reason this hasn’t been implemented, and offer a possible solution, albeit not the most intuitive. You could add an annotation feature to the midihub editor that doesn’t actually pass the notes to the midihub. The notes would be stored in the editor file only. You wouldn’t be able to see them when Loading from the midihub, but every patch I put onto the hub I save and title first, so I could just load my saved file to see the notes.
Perhaps not the most elegant solution, but it preserves the current functioning of the midihub itself, and I would welcome the slightly awkward workflow for the ability to annotate patches ASAP.
This is a really tiny one, but would reduce the number of duplicated pipes I’d need to run by A LOT!
CC Remap (and potentially other remaps, haven’t looked) - Allow CCs outside of defined remap range to pass through instead of being dropped.
Reason -
I am currently doing a big CC remap that allows me to automate multiple channels worth of CCs on a single midi sequencer track. (If anyone wants to know the gear, It’s the Hapax doing the automation, and the SP-404MKII receiving the CCs - Specifically, the SP-404mkII has 5 FX busses, and they have the same CCs on 5 different channels (but the hapax can only send CCs on one channel per track - so giving up 5 tracks is a bit much)
Example:
Receive CCs 16-19 & 80-83 and send to channel 1. Receove CCs 20-23 & 84-87 to be remapped to CCs 16-19 & 80-83. 8 more CCs in 2 ranges of 4 for each of the 3 remaining channels (ch 3,4,5)
The thing is the CC filter pipe already handles the multiple ranges, it’s just the CC remap that gets in the way.
Currently I have to do:
First pipe is already the correct CC and Channel 1, need to allow one instance of clock/transport through
In A - Filter only CC messages allowed + Clock + Start/stop | Filter CC 16-19, 80-83 | Out A
Next 2 lines are required for Bus effect 2 on channel 2.
In A - Filter only CC messages allowed | Filter CC 20-23,84-87 | Channel remap 1 to 2 | CC Remap 20-23>>16-19 | Out A
In A - Filter only CC messages allowed | Filter CC 20-23,84-87 | Channel remap 1 to 2 | CC Remap 84-87>>80-83 | Out A
Then need 6 more pipes of filters for the other 8 CCs on the other 3 FX buses
Ideally, if the CC remap allowed passthrough of non-range CCs, I would just do:
First line is the same for the first channel and clock/start stop.
In A - Filter only CC messages allowed + Clock + Start/stop | Filter CC 16-19, 80-83 | Out A
Second line is for bus effect 2 on channel 2
In A - Filter CC 20-23, 84-87 | Channel remap 1 to 2 | CC Remap 20-23>>16-19 | CC Remap 84-87>>80-83 | Out A
Then 3 more pipes like the one above for the other 3 bus FX
hey @ratrace2space
I can see where you’re going with your request;
personally I like the difference between Rescale’s clamping and Remap’s discarding and use it a lot. So if a non-blocking Remap were available as well the current version then I’m with you.
(I guess an checkbox would be the way; with the FW update making the default Discard Outside Range ticked)
In the meantime, when I’ve had similar problems I’ve used Transforms as an intermediary to avoid multiple pipelines.
(would you post the mhp? I wouldn’t be sure about how useful that would be without reconstructing your patch…)
Hey @ratrace2space, just looked back at this:
if your pattern is
- Ch2 line(s) → CC -4
- Ch3 line(s) → CC -8
- Ch4 line(s) → CC -12
- etc…
…can’t you just have one line per ch?
So eg
- CCRangeFilter allow 20-23,84-87
- CCRemap [20,87] → [16,83]
- ChRemap 1 → 2
Sorry if I’ve missed something
PS still think the Remap “allow through” option has legs tho…