Testing 07b with MIDI on two real machines: I think there is a bug with Ctrl+F3 when in Internal mode. I expect it to go to listen mode and don't start playback. But it goes to broadcast mode and starts playback. Bug doesn't happen in external mode, but there I have to set C the have the song play continously to imitate what I want to achieve in internal mode.
I've added 0.7c , in Internal mode this makes broadcasting and listening set to Constant mode automatically.
The other bug with listening mode going to broadcast mode I couldn't replicate in the emulator except with the cartridge switched off, so I've added a 'midi debug' mode you can toggle with CTRL + D. This will show the current midi buffer (where the author credits were) and also the current midi listen value from the cartridge, this is next to the 'Midi' title text in the Settings window. If this value isn't showing $ff with real cartridges that might be where the problem is, as that's what I'm checking for the 'idle' value.
CTRL+D shows an endless amount of changing random values where $ff is not present. SIDKick Teensy with the included MIDI-Interface allows me to disable/ignore MIDI-In-Events for those demos (somebody did a demo called Instinct ;-)) that only use MIDI-Out. If I disable MIDI-In, then I always get $ff.
Comparing with version 0.6b it seems that 0.7b/c has a different approach to MIDI-In handling. 0.6b works fine. Could it be that 0.7x is reading values without waiting for IRQ to happen?
Side note: Ctrl+F7 stops track but leaves last notes audible (fading out depending on ADSR). Shift+F7 additionally silences the track.
Thanks for the update. It's interesting the hardware produces random values on the bus. The way 0.7 works is like this:
On the main thread it's polling the listen register and checking if it's an $ff, if not it adds the value to the midi buffer. (a ring buffer, this got added once it had to start listening for midi input instead of just one-byte system commands.)
In Internal mode, when set to listen it reads through the midi buffer looking for either $f8 for a sync or $fc to switch over to being a broadcast machine when the other machine has stopped. Stopping or restarting the song clears the midi buffer out.
0.6 stored the latest midi value in a single byte and then compared that directly. (not checking for idle) So I'll get it back to that sort of setup but still using the midi buffer. I can make it simulate what the hardware is doing while I'm testing this and have a more realistic environment.
In external mode ctrl+f7will be leaving the notes trailing at the moment, if it's happening with internal mode though that's definitely a bug. :)
I've added a 'debug test' upload. This uses the 0.6 code for internal midi instead of the 0.7 stuff which isn't working. If this works I'll add it into the next 0.7d upload. In the midi debug screen only the value in the Settings window should be changing as it's directly getting the data from the listen register.
Good news! :-) I tested with internal mode on my usual setup and it works fine for me. I did a round robin of 4 to 5 songs going from one machine to the other and only using Ctrl+F7, load next song, Ctrl+F3 and the transfer from broadcast to listen to broadcast worked fine! I did not yet test external mode at all although I have some hardware for doing that in future. So from my perspective it is working as expected now in internal mode.
Having said that, my only MIDI interface in my collection is the one I am using (SIDKick Teensy with MIDI expansion). I have a Messiah but don't see it fitting in at the moment as a MIDI interface. So other MIDI interfaces may behave like the emulation you are focussed on, who knows? Or to turn it around: If SIDLab needs a hardware MIDI cartridge that always provides valid values when read - it would not be too hard to create a new MIDI cartridge that satisfies the special needs of SIDLab I guess.
To prove my writing I will try to attach a few screenshots.
