Hey guys, here’s the update which adds MIDI Mapping to pipe arguments!
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!
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.
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)
Editor
View->Show Tab Bar option on Mac should be gone this time. @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
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
(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
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.
exactly…
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?!
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
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.
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.
Yesterday, I inadvertently created a midi loop with clock messages - that seems to crash the Midihub
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
( it wasn’t clear in my case, as it was created due to the fact clock messages are channeless )
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)
