Ok, what I’ve seen so far: the note stack for osc1
is located at 0x15c-0x15f:
0150: 00 00 00 00 00 00 00 00 1E 00 00 00 1E 00 00 00
The first position of the stack contains “1E”, which means,
that note 1E = C-2 is played
Unfortunately the logfile doesn’t show a Note Off… ok,
so let’s assume that at this time the MIDI transfer
was already stucked. Let’s search for more informations…
The MIDI In Buffer is located at 0x500-0x53f
0500: 00 00 7E 40 00 0D 02 00 00 00 00 06 00 00 00 00
0510: 00 00 F7 2F 35 B0 2F 35 B0 2F 35 B0 2F 35 B0 2F
0520: 35 B0 2F 35 B0 2F 35 B0 2F 34 B0 2F 34 B0 2F 34
0530: 80 24 00 90 1E 7F B0 2F 34 B0 2F 34 B0 2F 34 F0
The last received events before the SysEx Request (which
begins at 0x53f) are: 80 24 00 90 1E 7F B0 2F 34 B0 2F 34 B0 2F 34
80 24 00: thats a note-off message for F#2
90 1E 7F: thats a note-on message for C-2
B0 2F 34: thats CC#47, Dec-Value 52
B0 2F 34: thats CC#47, Dec-Value 52
B0 2F 34: thats CC#47, Dec-Value 52
F0 …: SysEx message (RAM read) begins here
CC#47 (Resonance parameter) is a 4bit SID register,
it’s located at 0x117, bit 4-7:
0110: 00 08 00 00 F0 03 06 61 1F 0A 00 BC 9D 00 01 02
bit 4-7 of 0x117 is: 6
The 4-bit value of the received CC#52 is: 52 >> 3 = 6
In other words: the last MIDI events which were
received by the MBSID are stored correctly. There is
an active C-2 note, can you confirm this?
Ok, lets search for the logfile entry where F#2/C-2 was
sent, and thereafter 3 times a CC#47 with value 52:
Hm… and here I have a problem: the last combination
I found was:
497465 2 – 128 42 0 1 F# 2 Note Off
497466 2 – 144 36 127 1 C 2 Note On
497468 2 – 176 47 110 1 — Control Change
497474 2 – 176 47 110 1 — Control Cha
CC#47 is 110, and not 52
So, I’m missing something in the logfile. Maybe this was
also lost… (there is a character limit in the forum)
but now you should know, which informations are interesting
for me: the events at exactly the point where the note gets stucked
However, another point: During the analysis I remembered that
a friend has a similar problem with his M-Audio Delta1010
Soundcard/MIDI Interface. Once a lot of MIDI traffic is sent
out, the interface stucks and he had to reboot his PC.
I don’t want to say that you’ve exactly the same problem
(because of two things: you don’t need to reboot your PC,
and you are still able to send SysEx data)… but driver bugs
are things which have to be considered.
Therefore not only an updated logfile (which shows the
interesting moment) could be useful, but also the results
of a loopback test.
You can do this in the following way: after the SID stucked,
enable the MIDI merger via MIOS-Studio (select the
MIOS_MIDI_MergerSet command and send WREG=0x01". Thereafter
send some notes to the core module and check if they are
received back. Do the same test after power-on of the
module (doublechecking)
If you don’t receive any MIDI data back from the core
module when MIDI merger is enabled, you know that your
MIDI interface doesn’t send any CC/Note values anymore
Another point: it could be, that sending a SysEx message
“resets” your MIDI interface. In this case following
additional tests would be interesting:
- enable MIDI merger via MIOS-Studio, thereafter try to
get the MBSID stucking again, thereafter check if
MBSID still returns the sent events (if not, you are
very sure that Notes/CCs are not sent by the MIDI
interface anymore)
- once MBSID doesn’t react anymore, send a SysEx message
(e.g. MIDI Merger enable, or RAM read), and thereafter
send a Note-Off event of the note which got stuck. If
this works, then you know that a SysEx message resets
your MIDI interface… in this case I would say, that it
is definitely a bug in the driver of your interface
Any new inputs?
Best Regards, Thorsten.