I have set microtone channels to 2 … 9. It worked well, until it somehow degenerated to 5, 6, 8, 9 only, if I remember well. That sequence repeated until I powered off/on Midihub. After that, the channels were again 2 … 9. It is not the matter of a different preset, because I have only one preset with microtones and I have chosen it again after rebooting.
I updated Midihub few weeks ago. The option of unconditional pitch bend resend is on.
Hey, could you post your preset here (or PM it to me)?
It’d be great if you find a way to reproduce the issue.
The setup worked as intended, then it was left for some time untouched, everything on. After that break I pressed some keys and found out that now several notes persist as if there were some missing NOTE OFF events. So I tried to check, on which channels the notes persist, but I did not found it out. Instead, I noticed that this time only the aforementioned channels are used, but at least MIDI OFF were correctly transmitted again. Then I reset the MIDI player to silence it. It did not help with the problem. Power cycling Midihub did.
So far, this did not reappear but I did not play a lot. I attach the preset.
preset.mhp (179 Bytes)
Interesting, the Dispatcher pipe only works based on the MIDI events that pass through it, so the time break shouldn’t affect the operation.
So you mean after the break, at first it was all silent (all notes were off), then you played a couple of notes, but they didn’t get turned off after releasing the respective keys?
What could help getting it unstuck without restarting is to play more notes at a time than there are selected channels to use. In that case, the Dispatcher would drop the very oldest note played, and replace it with a new note. Alternatively, switching presets to some other preset and back should help as well.
I would guess so, but depending on the language you use, the Dispatcher’s channel array might have gotten corrupted.
Exactly like that. The following notes finished properly.
Yes, unless the missing note off events happened because the Dispatcher has “forgotten” four of its eight channels in the meantime, together with the note-ending events it should send here. Or, it has sent them elsewhere (to the four channels left?).
I played a number of different notes using the 4 channels left. It seems probable to me that the Dispatcher would need to drop any notes stuck there or otherwise they would change their pitch because of the new pitch bend events. I do not recall the latter, though. I would thus suppose that the stuck notes were somewhere on the four channels which were no more used. I have no proof of it, though.
Problems seem to appear once every few days. Mostly just an occasional NOTE OFF event lost. I do not recall a missing NOTE ON.
I would suggest to test Midihub with tools like Valgrind. Alternatively, my unit may have some hardware problem, but I find it unlikely that it would cause bugs like the described confusion of channels.
By the way, now I also use Dispatch by note number in series with Microtone.
It’d be great if you could share the input MIDI file with which the issue occurred at least once, then we could try and reproduce the issue. (as well as your latest preset iteration)
This issue might be very sensitive to the timing of the notes themselves, so it can depend a lot on the input.
There are no MIDI files, there is not even a computer involved. It is what I play. It goes out to Midihub and then back into the same synthesizer.
A good way of testing the problem (and testing Midihub in general) might be a testing setup with a computer-generated, random stream of events (tenths of events per second) or taken from a database of many MIDI files, or both at once. It would go through a number of Midihub inputs at once, then tested with a Midihub-independent code. Seems quite simple in case of blocks like Microtone or Dispatch. You might then leave this running for weeks, looking for outliers. Optionally, Midihub’s code linked with Walgrind or the like.
You could record what you’re playing into a MIDI clip for reproduction later, at the same time keeping the original processing.
Some of Midihub’s functionality is getting tested under randomized conditions, but tests like that for Micro Scale pipe or dispatcher might not be ideal, as you need known good reference data, or some alternative implementation with which to compare the results.
Are you still using 8 polyphony channels? How close to the limit are you playing?
With Midihub, I can indeed record the stream to PC.
I use a dispatcher / 2x microtone pipe which, depending on the range of keys, produces notes in channels 2-9 or 10-16. I would guess that I am rarely close to the polyphony limit, typically up to 4 in each range.
As of randomized tests, even a simple NOTE ON/OFF count per channel would do to find out this problem. The generated random stream would assure that a note lasts up to few seconds. A trivial Midihub-independent filter would verify if it is the case. The channel confusion bug would be detected immediately in this way.