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

--- In xl7@yahoogroups.com, "Royce" <rpcfender@...> wrote:

> > In principle you are right. The flash chip in the XL-7 is an Intel E28F640, which has a minimum specified erase cycle count of 100,000. Note, it's not the average, it's the minimum write cycle count. And that is intended to hold over the entire operating environment range of the chip; it is most likely not operating at its extremes in the XL-7 (for instance, the chip is specified up to at least 70°C, but it never gets that warm inside the XL-7).
> 
> You are right. Sorry about my mistake. I was also unaware that high temperature would reduce the write cycles.

I would rather express it this way: At lower then maximum temperatures one can expect a higher number of write cycles than it says in the specification.

> But for a sound designer, if you twisted a knob on an editor and the editor put out all the values in between then we can talk of hundreds or even thousands a day to a single location.
> 
> Jan's editor did this originally and I believe he paid the price with his machine dieing. 
> He has, of course fixed his great Prodatum editor so that is uses the RAM buffer.

I've heard of a similar problem with a car radio where the volume setting was written to the EEPROM (similar technology as flash) every time the volume was changed. Needless to say, after a couple of years the flash wore out and the unit died.

There could principally be a similar bug in the XL-7, i.e. a location in the flash being rewritten each time a patch is stored in any location. If this really were the case, it would be the total number of writes to any patch number that would be a factor, not just the number of writes to a specific patch. It's easy to miss during software development, and hard to test as you really have to perform lots of patch writes before the problem manifests itself. We have to hope the software engineers at E-Mu knew what they were doing...

> Did you buy the unit new?

No I didn't, so I don't know its previous history. It doesn't seem that worn though so I don't think it's seen a lot of use.

> > So while possible, I'd rule that out. The fact that writing the sysex bank fails even with very long delays (one second per sysex block), and the fact that after having happened once it starts to happen even for the first sysex block received until the system is rebooted, points to something in the software in the XL-7 that can't handle the sysex data. Indeed, the patches that are in fact received aren't playable anyway, and I know that the original author of the files didn't have the possibility to test them, so it seems likely there is an incompatibility in the patch file somehow.
> > 
> 
> Quite right. A factory reset might fix this.

I wrote in another response in this thread that I tried sending a patch dump that had originated on the machine itself, which went without a hitch at least with a sysex packet delay of 30 milliseconds in the dump program. So the fact that a known good dump works fine when sending it to the XL-7, but the dumps from the archives don't, indicate that there is something amiss with the latter - or that I'm doing something wrong with them. They do seem to contain patch data, as the XL-7 stores the first 37 of them, however, the Instrument settings seem wrong, mostly being set to CMPSR sample None, so they are silent when attempting to play them.

/Ricard