Hi all,
I’ve just built up a sammichSID I bought on here but it is ignoring the presets sysex file when sent to it.
MIDI in is working and I can dump out a patch and send one fine.
Looking at the sysex header the device IDs are different in the presets file and in the sysex dumped out by the Sammich.
Presets:
f0 00 00 7e 4b 00
Sammich:
f0 00 00 7e 4b 08
Is this deliberate? or has sammichSID always been incompatible with MIDIBox SID’s patches?
I’ve uploaded the non-sammich hex, transferred the presets and gone back to the sammich hex file. So I have the presets now, well most of them 
I don’t know offhand why you’re running into that problem, but I used the sammichSID firmware and had no issues uploading the initial patches, or any other patches for that matter. I haven’t updated the firmware in a while though, but I would be surprised if the latest firmware would have that restriction. I’m not sure what the problem is though 
Maybe it is related to the PIC header ID?
I think there’s a MIDI ID in there somewhere?
It is strange that by loading another version of MIDIBox SID made the ID change though.
Not sure if I was seeing things, but the ID seems ok now:
f0 00 00 7e 4b 00 02
But I’m still confused as to why it won’t receive?
Something odd with the latest sammichSID hex. I’ve gone back a release (RC38) and all is well. Looks like a quirk in the latest version?
I’m currently not at home and therefore can’t try this.
Could somebody please install V2.039 on his sammichSID and confirm that he sees the same misbehavior?
From your description:
Presets:
f0 00 00 7e 4b 00
Sammich:
f0 00 00 7e 4b 08
Was “08” really the ID, or is this a typo and you mean the SysEx type, e.g. after “f0 00 00 7e 4b 00 02 >> 08 <<”
http://discourse.midibox.org/t/topic/16398
This is the only (intended) change in the SysEx handling.
If you confirm that really the ID was wrong during the first tries of v2.039, I can check the related sources.
Best Regards, Thorsten.
Was “08” really the ID, or is this a typo and you mean the SysEx type, e.g. after “f0 00 00 7e 4b 00 02 >> 08 <<”
Hi TK. Yes, I got the wrong position in the hex.
What seems to happen with the latest code is the device seems slow for a while during and after the sysex dump. But then goes back to normal.
I’ve dumped an individual patch with R38 and R39, diffed them and there’s no difference. Receiving single patches works fine.
Alright!
Which tool are you using for the SysEx dump, and if it isn’t a MBSID V2 librarian (like the java based editor): which delay is inserted between the individual patches? (should be configurable, I think it was at least 750 mS, otherwise it won’t work reliable)
Best Regards, Thorsten.
Alright!
Which tool are you using for the SysEx dump, and if it isn’t a MBSID V2 librarian (like the java based editor): which delay is inserted between the individual patches? (should be configurable, I think it was at least 750 mS, otherwise it won’t work reliable)
Best Regards, Thorsten.
I’m using the SysEx tool built into MIOS Studio. I had the delay set to 250 but upping it to 750 hasn’t helped.
Strange… because it would be a possible explanation.
Background: writing into the external EEPROM (BankStick) takes some time, and if a new patch is received when the write operation still hasn’t been finished, a MIDI IN buffer overflow can happen.
Therefore the delay is required between each patch.
If you are trying to write the patch again, regardless of the firmware version, it will mostly consume much less time, because before the write operation MIOS will check the current content (of a 64 byte block) and then decide if the write operation could be skipped.
It would be interesting to know, if you are now able to upload the presets with v2.039 (the patch write should now be much faster, as the EEPROM already contains the expected content).
I’ve to check if 750 mS is still sufficient.
Sidenote: the Java based SysEx editor works bidirectionally, therefore no delay has to be specified which makes the process much faster. But the editor doesn’t work under MacOS anymore, and the Ctrlr based patch manager isn’t ready yet. If you are working under Windows, it would be a good alternative solution to ensure consistent patch uploads of course.
Best Regards, Thorsten.
Sadly v2.039 still won’t receive even if the patches are already present. Increasing the delay further still makes no difference. There’s just no indication on the screen that anything is taking place. Almost like it is being ignored.
Does sammichSID send back an error code? (-> see MIDI IN window of MIOS Studio, assumed that you’ve a bidirectional IN/OUT connection - check this by pressing the “Query” button)
Best Regards, Thorsten.
It keeps writing this out:
[693025.521] f0 00 00 7e 4b 00 0e 01 f7
[693027.022] f0 00 00 7e 4b 00 0e 01 f7
[693028.524] f0 00 00 7e 4b 00 0e 01 f7
[693030.024] f0 00 00 7e 4b 00 0e 01 f7
Which is this?
01 == received less bytes then expected
Ok, I will check it next week.
It would be helpful to know if somebody else who owns a sammichSID notices the same issue with v2.039?
Best Regards, Thorsten.
I get the same behaviour on my MB-6582. So it’s either some issue with my MIDI interface with the latest code or something in the latest code.
Hopefully someone will confirm either way. It is a cheapo interface, but it has worked perfectly well up until now, I just use it outside of my studio room.
Tested sysex on my M-Audio 8x8 MIDI interface, same result.
Possibly two dud/incompatible MIDI interfaces? they seemed fine before.
This bug was easy to reproduce and it’s fixed in V2.040
Best Regards, Thorsten.
Great. Works a treat.