Hello,
Quite an urgent call for help!
After almost 3 years, I’m re-using a midi hub preset that used to work back in the days. Now, there seem to be some troubles with my sustain into arpeggiator pipe. Maybe the issue might be caused by the firmware updates I did through the years.
There are two MIDI pipes that are routed to a virtual output and another pipe with that same virtual output routed to a physical MIDI output.
PIPE 2 = Midi Input A: note data coming from Nord Stage, some filtering, going to Virtual B
PIPE 3 = Midi Input B: clock / Start Stop data coming from ERM Midi Clock, filtering, going to Virtual B
PIPE 4 = Virtual B to sustain into the Arpeggiator to Midi Output B, which is a MB33 synth
Some parameters are controlled by a midi controller:
- Sustain ON/OFF
- ARP bypass; Time Division; Note Lenght; Type; Octave Range;…
The problem now is that I often get notes that got stuck / keep memorized when I play new chord notes on my Nord. I think especially after I change presets on my Nord.
Switching Sustain and ARP Bypass on and off again, doesn’t help. Some old notes keep on getting memorized and are mixed up with the new chord notes that I play (while new notes are changed properly every time I play a new chord).
This is very annoying, as there seems to be no good way to solve this wile in a performance. When I send a MIDI panic message from my Nord, nothing happens. The only thing that seems to work, is to launch a new preset on the Midihub and then go back to the original preset again.
Somebody that has an idea how to solve this?
Is there a way to re-load old firmware of about 3 years ago?
Thanks very much!
Hey, Luk
Are you able to post
- a screenshot of the preset
- the preset itself
(I recall you don’t get these permissions on your first post; might be available on reply)
Puzzled by your description:
Where is Arp getting clock messages from?
This not mentioned as coming from Nord and the lack of Filter at end Pipe 2 suggests you’re not avoiding Clock conflict in Pipe 3.
Hi thanks for help me solve this!
I’m really sorry, I was a little wrong about the routing. I’ll change it in the original post and I’ll put the pipe numbers according to the preset I’m sharing down below.
PIPE 2 = Midi Input A: note data coming from Nord Stage, some filtering, going to Virtual B
PIPE 3 = Midi Input B: clock / Start Stop data coming from ERM Midi Clock, filtering, going to Virtual B
PIPE 4 = Virtual B to sustain into the Arpeggiator to Midi Output B, which is a MB33 synth
Some of the parameters are Midi controlled by a FaderFox UC-4
Thanks!
Midihub 2023.09.02 00.05.21 (Preset 1).mhp (1.4 KB)
1 Like
Thank-you for the preset, @Luk_Vermeir
I set it up to be sufficiently like yours to be able to test
- Notes → mA
- Clock → mB
- mapCC → mD
(mapping the Arp Properties and Sustain On)
I can’t reproduce your glitches, I’m afraid: mine behaves exactly as expected; sustaining all notes while Sustain is on then dropping all “expired” notes when this is switched off.
No hung notes.
I did wonder cos I remember this similar bug report last year was fixed by firmware 1.13.2 which I assume you must be running.
Yes, the description of that problem looks very similar to my problem, except in my case sustain / arp come after the virtual port and not before.
The firmware of my Midihub was updated to the latest available.
yeah, I sorta hoped I could replicate yours.
I don’t know enough to know whether re-flashing the firmware might help.
short of that I guess, it’s a matter of routing your pre (input & mapping messages) and post (Arp out) to be recorded simultaneously into DAW so that the precise sequence of events leading to hung notes can be replicated by others.
in meantime, route the FaderFox to an All Notes Off (eg. Out Pipe Bypass) addition as a temporary fudge?
Thanks for the idea for a temporary work-around.
Didn’t know the ‘bypass’ was an actually ‘all notes off’ message. I thought it was just a temporary ‘mute’ function or something like that, so when the bypass is released the notes would still be there. So all notes are actually completely cut off / erased by activating the bypass?
I remember I have already the arp bypass controlled by the UC4 (because the ARP doesn’t always have to run). I’ll try to have the UC4 also bypass the virtual output B (first element of pipe 4?) that is feeding the sustain / arp chain. Or I might also bypass the sustain element of pipe 4.
I’ll give it a try, thanks!