Gilesjuk Posted April 6, 2012 Report Share Posted April 6, 2012 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? Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 6, 2012 Author Report Share Posted April 6, 2012 (edited) 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 :) Edited April 6, 2012 by Gilesjuk Quote Link to comment Share on other sites More sharing options...
m00dawg Posted April 6, 2012 Report Share Posted April 6, 2012 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 :/ Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 6, 2012 Author Report Share Posted April 6, 2012 (edited) 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. Edited April 6, 2012 by Gilesjuk Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 6, 2012 Author Report Share Posted April 6, 2012 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? Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 6, 2012 Author Report Share Posted April 6, 2012 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? Quote Link to comment Share on other sites More sharing options...
TK. Posted April 6, 2012 Report Share Posted April 6, 2012 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 <<" In order to support bidirectional communication with the new I had to change the handling on "RAM buffer" transfers: they don't change the patch and bank number anymore. 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. Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 6, 2012 Author Report Share Posted April 6, 2012 (edited) 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. Edited April 6, 2012 by Gilesjuk Quote Link to comment Share on other sites More sharing options...
TK. Posted April 6, 2012 Report Share Posted April 6, 2012 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. Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 6, 2012 Author Report Share Posted April 6, 2012 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. Quote Link to comment Share on other sites More sharing options...
TK. Posted April 6, 2012 Report Share Posted April 6, 2012 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. Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 6, 2012 Author Report Share Posted April 6, 2012 (edited) 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. Edited April 6, 2012 by Gilesjuk Quote Link to comment Share on other sites More sharing options...
TK. Posted April 6, 2012 Report Share Posted April 6, 2012 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. Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 6, 2012 Author Report Share Posted April 6, 2012 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 Quote Link to comment Share on other sites More sharing options...
TK. Posted April 6, 2012 Report Share Posted April 6, 2012 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. Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 6, 2012 Author Report Share Posted April 6, 2012 (edited) 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. Edited April 6, 2012 by Gilesjuk Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 7, 2012 Author Report Share Posted April 7, 2012 (edited) Tested sysex on my M-Audio 8x8 MIDI interface, same result. Possibly two dud/incompatible MIDI interfaces? they seemed fine before. Edited April 7, 2012 by Gilesjuk Quote Link to comment Share on other sites More sharing options...
TK. Posted April 9, 2012 Report Share Posted April 9, 2012 This bug was easy to reproduce and it's fixed in V2.040 :) Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Gilesjuk Posted April 9, 2012 Author Report Share Posted April 9, 2012 Great. Works a treat. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.