I´ve got a problem with a dispatcher pipe: This one should cycle through channels but it stays on incoming channel 1.
Can anybody explain this behaviour?
There are two issues in your line, Eddy
- You need to set your velocity to a non-zero value for dispatcher to see it as a Note_on
- Transform → Note On & Off doesn’t actually create a note on then a note off.
This means you need another way to get the Note_off.
Here are two: racecube_dispatcher_options.mhp
PS. This was done in 1.14.4; not sure if this will load gracefully in earlier version.
btw, I note the retirement of the fly…I miss it.
1 Like
For general interest:
I went to create a 1.13.4 version for those who are waiting for the general 1.14 release before upgrading. (or if @racecube was on 1.14.2 and didn’t want to switch)
Then I decided to make a patch demonstrating 4 different ways of generating Note On & Note Off from a Program Change.
this is the Description
PC ⇒ Note On & Off Dispatcher Demo
This demonstrator compares different ways of generating Note On & Note Off from a Program Change.
Each is then run through a Dispatcher to separate channels:
- 2 Transforms, On just before Off ⇒ Ch2-5
- Transform→Note On, short Length ⇒ Ch6-9
- Transform→Note On&Off, velocity N/A ⇒ Ch10-12
- Transform→Note On&Off, velocity=Arg2 ⇒ Ch13-16
altogether one might expect notes on Ch2-15…
…but only two of the methods work!Monitoring each Dispatcher shows what actually happens.
The 4th Dispatcher is deliberately disabled.
It should be re-enabled and watched for more than 4 notes…Monitoring
FROM Bis available to see combined outputs(the A→B line is just to show the original PC in the Monitoring at
FROM B)
Here’s the patch
NoteOnOff_dispatcher_demo.mhp (2.0 KB)
If you’re reading this and not really familiar with Transform and Dispatcher, give it a try!
(It’s “Auto-Run”, using a slow LFO to generate the PCs, so it doesn’t need any input devices–just Open the patch when connected to Midihub, select a pipe and watch the Monitor!
[No need to Store the patch as a preset ~ it’s only a demo] )
PS @Giedrius I’ve long assumed that the way Midihub handles a Note On with zero velocity is a deliberate choice to assist users with certain synths. Is this so?
2 Likes
Midihub allows producing a Note On message with 0 velocity, but every pipe dealing with Notes assumes that a Note On with 0 velocity is actually a Note Off with 0 velocity.
1 Like
So enacting Transform chain CC → Note On → CC can reproduce the original CC stream…
… but not if you stick a Filter “all except Note On” in between!
1 Like
Yes, Filter Pipe would drop the Note On with 0 velocity.
1 Like
nice work, you really got some skills to learn from 
Unfortunatelly at all 4 pipes there is no input and no output on the dispatcher pipes, it stops behind every transform (which all gives there Notes (on and like transformed offs but all on channel 1, which is not involved on the 4 examples): So the result at the bottom is the same as on the top right behind the LFO.
I am on Raspberry 1.14.1 in editor and on firmware (@Giedrius that sometimes shuts down when I edit ports (or simply channels in transform pipes) and then after restart comes back with the edits - change of Preset was always ok)
I have a Windows 1.14.4 without Midihub which I thaught as offline working, but the LFO does nothing so I can´t verify if the issue is here as well. I don´t want to change to another beta on my RPi, last time it was to frustrating 
Do you mean it’s not sending messages out of Midihub?
If so, No: I’m just trying to demonstrate what works (and doesn’t!) in Midihub.
(the combined stream would be a lot of outgoing messages unless most of the TO-B pipes are disabled)
Once you’ve watched the Monitor at various places and understood the difference, use the pipeline you want to build a working patch.
I have a Windows 1.14.4 without Midihub which I thought as offline working
No.
The Editor can now be used to set up mappings offline for the first time. You still need a Midihub connected to see what’s going on with messages.
Fortunately, my second patch NoteOnOff_dispatcher_demo.mhp is written in 1.13.4 so it will load in whatever firmware your MH is running (my guess is FW 1.14.2 if you’ve connected to your Windows machine. Giedrius tells us this is working fine on Win).
So load that patch when Midihub is connected to Windows and take a look
Thx for clearing up. I wanted to give it a try so I plugged MH to windows but it want connect without updating firmware 
So I wanted to update but windows says: Firmware download failed with error 9
S I did it on my Pi: Failed to connect after restart Code 266
So I pressed ok and I could reconnect (happy) but: Now the editor is incompatible again…updated this -involuntary 
- and all presets lost!!
I had a backup, one week old but ok I am back to business with the loss of some work.
(B.t.w. I´ve just bought a RPi 4 to get my Pisound finally working, so there is a good chance that I will have a lot more questions in the near future 
oweia)
Whenever an automatic firmware update is started, the Editor saves the memory contents backups at these locations, depending on the OS:
- Linux:
~/.local/share/Blokas/Midihub Editor/ - macOS:
~/Library/Application\ Support/Blokas/midihub-editor/(Paste this into Finder → Go → Go to Folder) - Windows:
%LOCALAPPDATA%\Blokas\Midihub Editor/(Paste this into Start → Run)
You can try importing the contents by going to Device → Import Everything… and picking one of the .mhd files.
Not to worry
@Giedrius or someone with Windows will advise on this; Midihub stores all the presets in an .mhd file before it starts an update.
On Mac it’s ~/Library/Application Support/Blokas/Midihub Editor/ so pretty sure you’ll find it with a search for .mhd
Once you do, you can reload your presets with Device → Import Everything
So Eddy, aside from your incompatibility issues, did you get the patch going and see where to go next?
PS. Although I miss the fly, I appreciated finding out about Transwaves today
Far away from that - I will look for the backups (thx for that) cause my transform pipes seem to be corrupted again.
Sorry to hear that, man.
document it for G and he’ll help you sort it out no doubt
1 Like
this is what came up from 2021, Eddy
C:\Users\<your_user>\AppData\Local\Blokas\Midihub Editor
(from here)
Sorry hadn’t spottted G had given all this info!
I played the backup back to the MH and: My transform pipes are corrupted 
Midihub Backup 2024.01.13 21.12.33.mhd (15.7 KB)
Previous version was 1.14.1
(I am running my VNC on a WIN 10 notebook with an empty backup battery, so the clock is most of the time unsynchronized - maybe thats the problem?)
Try this:
Midihub Backup 2024.01.13 21.12.33_fixed_up.mhd (15.7 KB)
Let me know if this works as expected.
1 Like
Sorry for late reply: This one works like expected!
…I wonder how you did this or what went wrong on my side
There was an issue in one of the early 1.14 minor updates that would incorrectly produce the preset files, marking them to be an older version than they actually were, therefore importing them would mangle up the Transform pipes. So what I did was some binary adjustments to the .mhd file to touch it up to the latest standards. 
This issue will be avoided by the majority of users who will naturally skip the interim 1.14 minor build that had this formatting issue.
Your feedback was really helpful in tracking this problem down.
1 Like