[Download] Midihub 1.03 Update

Hey guys, here’s the update which adds MIDI Mapping to pipe arguments! :slight_smile:

It is still an early iteration of the functionality and it will get improved over time, but we think it’s at a good stage to show it to you guys and hear your opinion and feedback on its usability, what’s missing and how you’d like to be able to use it, so we can know where to focus next! :slight_smile:

1.03 Editor downloads

1.03 Firmware

To update the Midihub firmware, switch it on while holding down The Button. In the firmware upgrade mode, all the LEDs should be lit up. Then connect to it with the editor, go to Device->Flash Firmware, pick the downloaded bfw file and hit OK.

* All stored presets will be removed during the firmware upgrade process * - you’ll have to back it up manually by loading each preset and saving them to disk with different names, a ‘data dump’ function to automate this, and to automatically do that during firmware update is planned to be done before the public release.

1.03 Changelog

Midihub Roadmap


  • MIDI Mapping of pipe parameters.
  • Fixed an issue where data could go through in a pipeline when there’s no Output port at the end to the symetrically matching output of what the input was.
  • All pipes now have a ‘bypass’ argument (only editable via MIDI mapped controls at the moment). If ‘Bypass’ is set to yes, the pipe is skipped without any processing. If the Input pipe is bypassed, entire pipeline is switched off. If an output pipe is bypassed, the data is not sent to the output port, however, the processing of the data still happens until it reaches the output. (So it’s more efficient to bypass inputs)


  • View->Show Tab Bar option on Mac should be gone this time. :slight_smile: @thetechnobear
  • Properties panel added, which lists all of the selected pipe’s arguments and allows mapping / unmapping MIDI messages to the arguments. (Filter pipe arguments are not mappable, but its ‘Bypass’ is)
    • The values still have to be edited via right click or double click on the pipe icons, future versions will have editing implemented via the Properties panel and the dialogs will be removed.

been using this since release, and seems to be all good

the ‘show tab bar’ has indeed gone :slight_smile:

I like the new property panel… will make much more sense when parameters are editable.

midi mapping seems to work ok, though with current modifiers not found a use for it yet :slight_smile:
(this is also partially as everthing goes from the MH into my pyramid which also can do similar things)

only one small issue, that id not noticed before…

when I power on my synth (virus TI) it seems to send some message (cc? pgm chg?) that means the first preset does not appear to work - powering off the MH, or switching parts on the virus seems to clear it (!)
the MH shows preset 1 as still active, just not forwarding data… changing presets does not appear to fix it.

I know its all a bit vague, but its tricky to see whats doing on, I guess I need to somehow put some kind of midi monitor in between the virus and the MH - but that means probably reconfiguring a pisound (or something) as a midi logger - so non-trivial :frowning:

1 Like

Virus TI (off at this time) DIN5 output is hooked up to one of Midihub’s (on at this time) MIDI IN, Virus TI is switched on, and that causes the very first preset on Midihub to stop working? In case the Virus TI is already on before making the MIDI connection, this issue does not occur?

One idea that comes to mind is an unfinished sysex message (0xf0 received, but 0xf7 is still being waited for) - in case the inputs are getting merged to a single output, it may block the output until sysex message is cleared.

In case the source of the sysex message starts sending non sysex and something else then sync clock message, it should snap Midihub out of the sysex state, but maybe there’s a bug in there somewhere, I will check it out a bit later.

1 Like

so I turn on the MH, the leds flash as if preset is working (i.e midi coming from virus, and out to sequencer), then its stops,
and even the led for the midi din input does not flash
then power cycling the midi hub fixes

ok, I think it is likely something to do with sysex.

Ive noticed if I put the TI in single midi mode, and power it on, theres no issues
only its coming up in multi or sequencer mode.
(this is probably why I didn’t notice before, as ive recently changed to using seq mode a lot)

ive also seen the same thing happens if I switch mode AND this will also sometimes clear the issue.
as you say, almost as if there is something ‘unfinished’.

I think your right, I think the midi spec allows for a sysex to be terminated by another midi message , and perhaps the virus is relying on this?!

1 Like

It’d be great to catch the MIDI messages that are output by Virus TI during those key moments. I think it should not require any additional software on whatever Pisound setup you currently have, to get Pisound to log and forward back MIDI, it may be enough to do:

aconnect 20:0 20:0 # Assuming this is the Pisound's client number
amidi -p hw:1,0 -a -c -r dump.bin 

yeah, it was a matter of breaking everything out, finding cables, and hooking it all up :wink:
anyway , this is what i get on the pisound

we@norns:~ $ amidi -p hw:1,0 -a -c -r dump.bin 


a quick dump:

we@norns:~ $ amidi -p hw:1,0 --dump

B0 0B 51
B0 0B 7F
F0 00 20 33 01 00 73 00 10 00 F7
E0 00 40
B0 7B 00
B1 7B 00
B2 7B 00
B3 7B 00
B4 7B 00
B5 7B 00
B6 7B 00
B7 7B 00
B8 7B 00
B9 7B 00
BA 7B 00
BB 7B 00
BC 7B 00
BD 7B 00
BE 7B 00
BF 7B 00
B0 7B 00
B1 7B 00
B2 7B 00
B3 7B 00
B4 7B 00
B5 7B 00
B6 7B 00
B7 7B 00
B8 7B 00
B9 7B 00
BA 7B 00
BB 7B 00
BC 7B 00
BD 7B 00
BE 7B 00
BF 7B 00

if i do the same thing, connected to my mac with an audio interface midi connection I can see:

859581592604623	From MIDI	Control	1	11	81
859581593604623	From MIDI	Control	1	11	127
859581594588814	From MIDI	SysEx		Access 11 bytes	F0 00 20 33 01 00 73 00 10 00 F7
859581597811535	From MIDI	Pitch Wheel	1	0
859581708330039	From MIDI	SysEx		2 bytes	F0 F7
859581708705039	From MIDI	Invalid		3 bytes
859582134977301	From MIDI	Control	1	123	0
859582135825144	From MIDI	Control	2	123	0
859582136825144	From MIDI	Control	3	123	0
859582137923840	From MIDI	Control	4	123	0
859582138717247	From MIDI	Control	5	123	0
859582139717247	From MIDI	Control	6	123	0
859582140479212	From MIDI	Control	7	123	0
859582141504640	From MIDI	Control	8	123	0
859582142504640	From MIDI	Control	9	123	0
859582143480809	From MIDI	Control	10	123	0
859582144355809	From MIDI	Control	11	123	0
859582145359816	From MIDI	Control	12	123	0
859582146251165	From MIDI	Control	13	123	0
859582147251165	From MIDI	Control	14	123	0
859582148245606	From MIDI	Control	15	123	0
859582149391285	From MIDI	Control	16	123	0
859582150016285	From MIDI	Control	1	123	0
859582151017613	From MIDI	Control	2	123	0
859582151892613	From MIDI	Control	3	123	0
859582152894818	From MIDI	Control	4	123	0
859582153892075	From MIDI	Control	5	123	0
859582154767075	From MIDI	Control	6	123	0
859582155764963	From MIDI	Control	7	123	0
859582156514742	From MIDI	Control	8	123	0
859582157514742	From MIDI	Control	9	123	0
859582158514364	From MIDI	Control	10	123	0
859582159389364	From MIDI	Control	11	123	0
859582160412241	From MIDI	Control	12	123	0
859582161366741	From MIDI	Control	13	123	0
859582162241741	From MIDI	Control	14	123	0
859582163265119	From MIDI	Control	15	123	0
859582164014453	From MIDI	Control	16	123	0

interestingly the 3 ‘invalid bytes’ are :
F4 00 F7

this in the midi spec is listed as ‘undefined (reserved)’
not sure if its a bug, or they are using it as some kind of control messages to switch modes.
(in fairness, the access has with the virus being multitimbral with hundreds of parameters, has had to ‘push’ the midi spec in places, to enable them to allow all modes/controls to be accessible in their VST)

anyway, id guess its either those bytes, or perhaps the previous sysex with no content thats tripping it up.

1 Like

Yeah, looks like the invalid sysex message is very likely at fault here. Thank you very much for providing the data, I will integrate this into our internal test cases and fix the issue in the next release. :slight_smile:

1 Like

Yesterday, I inadvertently created a midi loop with clock messages - that seems to crash the Midihub :slight_smile:

I wonder if it would be possible for some kind of primitive midi loop detection in midi hub?
Could be a handy feature , if it showed the connections involved :slight_smile:

( it wasn’t clear in my case, as it was created due to the fact clock messages are channeless :slight_smile: )

Hey, which route did the loop happen? Via MIDI, USB or Virtual pipes?

I’ll see what can be done about this.

good question, im not exactly sure… as I just put a filter on all inputs except the clock master (DIN A)

whats odd its i couldn’t actually see an obvious reason for the loop…
(hence my ‘blanket fix’)

basically I had
DIN A (pyramid, clock master) -> DIN B,C,D, USB A-A

but on input the only active device was the virus on DIN B, this would route back to DIN A (pyramid)
BUT the virus was set to external clock, so i don’t think it would rebroadcast it.
even if it did, then it would go back to DIN A (Pyramid) , no where else, but that was set to ignore incoming clock…

the only other thing was USB which was connected to the computer, but no daw running, so that would not loop.

its odd, but definitely felt like a loop, since it would work for a second or two, then would stop, i guess as the feedback when awry.

(this is the setup, and the filters were all added to fix this issue, they were not there before)