Emu XL-7 & MP-7 User's Group

--- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@...> wrote:
>
> Thanks for posting the XL-7's sysex output. I explain it in the folder where you posted the output. Basically it is a whole bunch of "cancel" messages--I suspect issued from the sysex being too fast.

I rather think it's something else, for instance like you say below that there are references to non-existent resources in the files.

The reason is that the first 37 or so patches generate the sysex response, but no Sysex: too fast messages, and are stored in the receiving bank (albeit with the Instrument numbers set to 000:None). The 38th patch sent then generates a Sysex: too fast message, but does not elicit sysex the message, and is not stored in the bank either. So my thought is that something in patch number 38 (give or take one) causes the XL-7 to get confused, so confused that it says Sysex: too slow for all further patch dumps until rebooted.

> I redid the banks, setting the arp pointers to User arp patterns. On my XL-1, the presets no longer pointed to 000:None.
> 
> I'd be curious to know if these versions also get rid of the sysex too fast problem.

They seem to work now! I downloaded banks 0 and 1 to my XL-7 without any problems (no Sysex: too slow messages or any sysex emitted from the XL-7). I haven't listened to all the patches, but I tried a handful in bank 0 and they all sounded reasonable. 000^0: arp: Guitartar is silent though, but it does point to a non-existent (or empty) user arp pattern so that most likely explains it.

My guess is that at least the XL-7 got confused when it received a patch with an invalid arp pattern reference, basically storing it as well as it could anyway but complaining about it (via the sysex 'cancel' messages). When storing it would appear that it set the Instrument number to 0 to avoid possible conflicts, even if it was not actually the instrument allocation that was the problem?

One could imagine that the differences between the software in the XL-1 and XL-7 might account for the difference in behavior when receiving the patches.

> For some reason 082^3 arp:LowPercRoll points to a non-installed arp pattern and causes a lock up. I am not sure why that didn't get pointed to a User arp pattern. 

I have not tried this patch so I don't know if it would be a problem in my case.

Anyway, thanks a million for redoing the conversion, it'll be nice to try out this new set of patches!

/Ricard