When building the MPG-200 for the JX-3P, I discovered that the busy line is hardwired via a pullup resistor to +5V, in effect tying it to logic high.
Because of this, I decided to ignore it altogether. But when trying to get the MPG-200 to work with the MKS-30, I discovered that this synth actually DO control the line.
So what actually happens when the busy line is pulled low?
As expected, the PG-200 does not transmit anything while the line is low. Still, I was curious what happened afterwards, when the line was released again - did the PG-200 just ignore whatever had happened during busy, did it queue up events or did it send the new stable status?
Well, a bit of both really. It keeps the last state from before it was blocked. Then, once busy is cleared, it sends first the state it had before blocking, and then the state after blocking. This happens for both switches and potentiometers.
Sunday, November 18, 2018
Saturday, November 17, 2018
Fooled by running status. Again and again.
The midi protocol is not very complex. But one thing keeps making me trip: Running statuses. You can send a status byte, and as long as you don't send a new status byte you may keep sending data bytes for the same status. This is very convenient when sending for example filter sweeps etc.
In my work on the MPG-200 this has made me trip several times. Because:
The source for my midi data has mostly been my Moog Little Phatty. It sends running statuses of course. But when I reboot my mpg-200 without restarting the LP or playing a note, the LP don't send the status message again, and the MPG-200, having just booted, has no way of knowing what it is receiving as it has not seen any status message. It has fooled me more than once.
Today it happened again, but in a more subtle way. I have spent the last week trying to figure out a very strange bug I noticed after a large refactoring of the MPG-200 code: After changing the CC for the filter cutoff using sysex, things worked fine when sending the correct CC from my sysex/web midi based pg-200. But after rebooting nothing worked. Sending a sysex clear memory somehow reset things and the CC started working again.
I stripped down the program to the minimum and it still happened. I discovered though, that sending a midi note on had the same effect. Today I had time to think more thoroughly about it and came to the conclusion that it could not be the part of the program that treats the received bytes, it had to happen on reception. So I hooked up my logic probe to the midi rx line and watched what came into the MPG-200.
Guess what - after a restart, the web gui, knowing nothing about the restart, did not resend the status message. That explained almost everything, I had tripped in the running status issue again. But a little more research uncovered a few other interesting things:
Sending a midi note on from the LP actually reset the running status, so the status message was sent again. This surprised me, how does the web gui know that the LP has sent a midi on? I also tried to refresh the web gui to 'restart' the midi interface, but this did NOT work, it still did not send a new status message.
Then it dawned on me. I am using the LP as my midi interface. It is the LP that holds the state, NOT the web midi adapter! So even if the web midi did restart, the LP knew it was currently sending a particular CC, and so did not resent the status - and of course sending a note on merged into the same data stream and made the LP resent the CC status later.
Oh well, I am just glad I figured this out, even though it's a bit embarrassing.
In my work on the MPG-200 this has made me trip several times. Because:
The source for my midi data has mostly been my Moog Little Phatty. It sends running statuses of course. But when I reboot my mpg-200 without restarting the LP or playing a note, the LP don't send the status message again, and the MPG-200, having just booted, has no way of knowing what it is receiving as it has not seen any status message. It has fooled me more than once.
Today it happened again, but in a more subtle way. I have spent the last week trying to figure out a very strange bug I noticed after a large refactoring of the MPG-200 code: After changing the CC for the filter cutoff using sysex, things worked fine when sending the correct CC from my sysex/web midi based pg-200. But after rebooting nothing worked. Sending a sysex clear memory somehow reset things and the CC started working again.
I stripped down the program to the minimum and it still happened. I discovered though, that sending a midi note on had the same effect. Today I had time to think more thoroughly about it and came to the conclusion that it could not be the part of the program that treats the received bytes, it had to happen on reception. So I hooked up my logic probe to the midi rx line and watched what came into the MPG-200.
Guess what - after a restart, the web gui, knowing nothing about the restart, did not resend the status message. That explained almost everything, I had tripped in the running status issue again. But a little more research uncovered a few other interesting things:
Sending a midi note on from the LP actually reset the running status, so the status message was sent again. This surprised me, how does the web gui know that the LP has sent a midi on? I also tried to refresh the web gui to 'restart' the midi interface, but this did NOT work, it still did not send a new status message.
Then it dawned on me. I am using the LP as my midi interface. It is the LP that holds the state, NOT the web midi adapter! So even if the web midi did restart, the LP knew it was currently sending a particular CC, and so did not resent the status - and of course sending a note on merged into the same data stream and made the LP resent the CC status later.
Oh well, I am just glad I figured this out, even though it's a bit embarrassing.
Subscribe to:
Posts (Atom)