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

I'm trying to download the P2500-patches-for-Composer banks from the group files area to my XL-7. However, I keep getting 'Error! Code = 000 Sysex: too fast' on the XL-7. Ok, fair enough, so I set my MIDI dump program to add a delay each time it sends an EOX (F7h). But even with a delay of one second for each EOX I still get the dreaded message on the XL-7. It seems to happen directly after the first sysex block in the file, and that sysex block at least is not big, something like 20 or 30 bytes at the most, leading me to believe the problem is actually something else.

Is there another setting I''m missing on the XL-7 ? I've set the device id to 0.

I've tried sending files from two different sources, MIDI-OX one my old Windows98 machine, as well as a command line midi dump program on my MIDI laptop. Same result.

It seems that there's either an error in the files, or I'm doing something very wrong. If I reboot the XL-7, it appears to load the patches up until patch 37 (I'm downloading bank 0), then the 'Sysex: too fast' message appears. Apparently this makes the XL-7 confused, because afterwards all patch downloads are met with the 'Sysex: too fast' message.

Furthermore, the patches don't seem to be correct in that the Sample number is set to 0 = NONE for at least the few that I've tried. 

Strange, I've got a Composer ROM in my XL-7 which I extracted from a P2000, so it should be the correct ROM for these patches. Or have I misunderstood what the patch files are for?

Factory reset the unit first then try to load the file.
Try another sysex file.

If it stops in the same place or the factory reset takes a long time then you may have a flash memory problem.
The unit writes to flash and waits for the chip to return from the write process before writing another byte. 
Faulty flash may be increasing the write time.

Flash memory is good because it doesn't need a lithium battery to store the information, but it wears out.

The early flash only had about 100,000 writes on average. 
I'm not sure what the P2k uses but the 100k is an average so there will be some chips that bomb out sooner.

You have to be carefully about the sysex in the P2k as it can write directly to the flash RAM and if you are happily changing stuff all the time eventually it will fail.

There is an edit buffer in the P2k that is RAM, not flash, that you can write to as many times as you like. Unfortunately I can't find a buffer for the Arpeggiator so when you are changing the User Arps with, say, Prodatum you are writing to the flash. 

If anyone knows the address of the Arp buffer please let me know.

All the best
Royce

--- In xl7@yahoogroups.com, "Ricard" <ricard2010@...> wrote:
>
> 
> It seems that there's either an error in the files, or I'm doing something very wrong. If I reboot the XL-7, it appears to load the patches up until patch 37 (I'm downloading bank 0), then the 'Sysex: too fast' message appears. Apparently this makes the XL-7 confused, because afterwards all patch downloads are met with the 'Sysex: too fast' message.
> 
> Furthermore, the patches don't seem to be correct in that the Sample number is set to 0 = NONE for at least the few that I've tried. 
> 
> Strange, I've got a Composer ROM in my XL-7 which I extracted from a P2000, so it should be the correct ROM for these patches. Or have I misunderstood what the patch files are for?
>

Is the flash replaceable

--- In xl7@yahoogroups.com, Matt <somatt@...> wrote:

> > If it stops in the same place or the factory reset takes a long time then
> > you may have a flash memory problem.
> > The unit writes to flash and waits for the chip to return from the write
> > process before writing another byte.
> > Faulty flash may be increasing the write time.

> > The early flash only had about 100,000 writes on average.
> > I'm not sure what the P2k uses but the 100k is an average so there will be
> > some chips that bomb out sooner.

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).

Doing the math that means that over a period of 10 years you could write to the same location in memory almost 30 times per day. Even with daily use it is unlikely that someone would manage that. It's not just 30 write operations per day, it's 30 writes to the same patch location every day for 10 years.

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.

> > You have to be carefully about the sysex in the P2k as it can write
> > directly to the flash RAM and if you are happily changing stuff all the
> > time eventually it will fail.

I don't know how my XL-7 was used before I bought it, but I rarely dump sysex to it. It is a valid point though for someone using a software editor.

/Ricard

--- In xl7@yahoogroups.com, Matt <somatt@...> wrote:
>
> Is the flash replaceable

Yes, but it is soldered in place (56 pin TSOP package) so it requires surface mount soldering skills to replace it. Besides, I'm not sure that the machine would operate properly with an empty flash; I think the operating system is stored there too. One could check with EPR Electronics if it would be worth replacing the flash, they have a lot of experience with these machines.

/Ricard

--- In xl7@yahoogroups.com, Bruno <brunorc@...> wrote:
>
> Hi Richard,
> 
> 
> I think you can experiment with MIDI -> Sysex Packet Delay setting:
> 
> "On playback from the sequencer, the SysEx data will be fed more slowly
> into XL-7 so that the its input buffer does not overflow, causing an
> error." (page 168, Rev. G of XL-7 manual).

I thought the sysex packet delay setting on the XL-7 is involved when the XL-7 is transmitting data to a sequencer, not receiving?

/Ricard

Hi Ricard

> > > The early flash only had about 100,000 writes on average.
> > > I'm not sure what the P2k uses but the 100k is an average so there will be
> > > some chips that bomb out sooner.
> 
> 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.

 
> Doing the math that means that over a period of 10 years you could write to the same location in memory almost 30 times per day. Even with daily use it is unlikely that someone would manage that. It's not just 30 write operations per day, it's 30 writes to the same patch location every day for 10 years.

Absolutely, this is how I would normally think of flash. 
Sending a new patch or a bank 30 times or more a day, every day is silly.

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.

Did you buy the unit new?

> 
> 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.

Royce

�

Hi Ricard

> > > The early flash only had about 100,000 writes on average.
> > > I'm not sure what the P2k uses but the 100k is an average so there will be
> > > some chips that bomb out sooner.
>
> 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.

> Doing the math that means that over a period of 10 years you could write to the same location in memory almost 30 times per day. Even with daily use it is unlikely that someone would manage that. It's not just 30 write operations per day, it's 30 writes to the same patch location every day for 10 years.

Absolutely, this is how I would normally think of flash.
Sending a new patch or a bank 30 times or more a day, every day is silly.

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.

Did you buy the unit new?

>
> 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.

Royce

�

eBay, less than $10usd.

Sent from my iPad

On Mar 8, 2013, at 8:09 PM, "Royce" <rpcfender@...> wrote:

�

Hi Ricard

> > > The early flash only had about 100,000 writes on average.
> > > I'm not sure what the P2k uses but the 100k is an average so there will be
> > > some chips that bomb out sooner.
>
> 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.

> Doing the math that means that over a period of 10 years you could write to the same location in memory almost 30 times per day. Even with daily use it is unlikely that someone would manage that. It's not just 30 write operations per day, it's 30 writes to the same patch location every day for 10 years.

Absolutely, this is how I would normally think of flash.
Sending a new patch or a bank 30 times or more a day, every day is silly.

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.

Did you buy the unit new?

>
> 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.

Royce

Thanks for the pointer to p. 168 of the XL-7 Manual. This parameter only affects sysex out. (See paragraph 1 below.)

I believe the manual is talking about recording and playing back sysex in a sequence (I.e., with the clock running and measures ticking by), not using a sysex bank capturing feature built into a sequencer. If you slow it down on the way to the sequencer, instead of taking 4 measures to do a dump, it might take 12 measures. In that way, playing it back would be slower. At least, that's what I think paragraph 2 is talking about. 

If I am right, you could try slowing down the clock/tempo of the sending sequencer.

You may know that several of the conversion banks (e.g., P2000 presets for the P2500 ROM) were distributed by Sean@E-mu as *.mid files.  I think that supports my interpretation.

Hope this helps.

Steve


 

=====================================================================
The MIDI SysEx Packet Delay command lets you specify the amount of
delay between MIDI SysEx packets going out of XL-7 so that your computer
sequencer can record this large chunk of data over a longer period of time.

On playback from the sequencer, the SysEx data will be fed more slowly
into XL-7 so that the its input buffer does not overflow, causing an error.

Many sequencers allow you to "Time Stamp" SysEx data as it is recorded.
This is the preferred mode for recording SysEx data

--- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@...> wrote:
>
> Thanks for the pointer to p. 168 of the XL-7 Manual. This parameter only affects sysex out.

> I believe the manual is talking about recording and playing back sysex in a sequence (I.e., with the clock running and measures ticking by), not using a sysex bank capturing feature built into a sequencer. If you slow it down on the way to the sequencer, instead of taking 4 measures to do a dump, it might take 12 measures. In that way, playing it back would be slower. At least, that's what I think paragraph 2 is talking about. 

I agree. I think that's what they mean too.

> If I am right, you could try slowing down the clock/tempo of the sending sequencer.

I'm using a sysex dump program, so there's no tempo adjustment, however I can specify a delay between each sysex packet. Even with a delay of 1 second between them, I still get Sysex: too fast.

I also tested with a known good patch dump from my machine. I didn't test all possible values, but specifying a sysex delay of 0 in the dump program caused a Sysex: too slow message, specifying a delay of 30 milliseconds caused it to work fine (I also verified that the patches in fact were written to memory). So it appears the XL-7 is ok, and there is something amiss with the data in the converted P2500 files.

> You may know that several of the conversion banks (e.g., P2000 presets for the P2500 ROM) were distributed by Sean@E-mu as *.mid files.  I think that supports my interpretation.

Yes, I saw those, however, the ones I was interested in (i.e. P2500 presets for the P2000 ROM) where apparently converted by someone on this list, and saved as .syx files. Looking at them in an editor confirms this - they are not MIDI (.mid) files, they are raw sysex data.

Another odd thing with these files, apart from the Sysex: too fast message is that during the dump I can see the MIDI out led on the XL-7 flash occasionally. So something in the files is causing the XL-7 to transmit data. It doesn't do that with the patch dumps I have that originated from the machine itself, so there's another difference there. I don't if it is significant though.

/Ricard

--- 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

I am wondering if the outgoing midi out led is a sysex error message. Can you capture it?

Where are the P2500 --> P2K ROM files?  I will take a look to see if there are any obvious errors in the data.

Steve

--- In xl7@yahoogroups.com, "Ricard" <ricard2010@...> wrote:
>
> 
> 
> --- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@> wrote:
> >
> > Thanks for the pointer to p. 168 of the XL-7 Manual. This parameter only affects sysex out.
> 
> > I believe the manual is talking about recording and playing back sysex in a sequence (I.e., with the clock running and measures ticking by), not using a sysex bank capturing feature built into a sequencer. If you slow it down on the way to the sequencer, instead of taking 4 measures to do a dump, it might take 12 measures. In that way, playing it back would be slower. At least, that's what I think paragraph 2 is talking about. 
> 
> I agree. I think that's what they mean too.
> 
> > If I am right, you could try slowing down the clock/tempo of the sending sequencer.
> 
> I'm using a sysex dump program, so there's no tempo adjustment, however I can specify a delay between each sysex packet. Even with a delay of 1 second between them, I still get Sysex: too fast.
> 
> I also tested with a known good patch dump from my machine. I didn't test all possible values, but specifying a sysex delay of 0 in the dump program caused a Sysex: too slow message, specifying a delay of 30 milliseconds caused it to work fine (I also verified that the patches in fact were written to memory). So it appears the XL-7 is ok, and there is something amiss with the data in the converted P2500 files.
> 
> > You may know that several of the conversion banks (e.g., P2000 presets for the P2500 ROM) were distributed by Sean@E-mu as *.mid files.  I think that supports my interpretation.
> 
> Yes, I saw those, however, the ones I was interested in (i.e. P2500 presets for the P2000 ROM) where apparently converted by someone on this list, and saved as .syx files. Looking at them in an editor confirms this - they are not MIDI (.mid) files, they are raw sysex data.
> 
> Another odd thing with these files, apart from the Sysex: too fast message is that during the dump I can see the MIDI out led on the XL-7 flash occasionally. So something in the files is causing the XL-7 to transmit data. It doesn't do that with the patch dumps I have that originated from the machine itself, so there's another difference there. I don't if it is significant though.
> 
> /Ricard
>

I see that I posted a set in 2010. Is that the set you are having problems with? Based on the readme file, I see that I simply changed the ROM ID to point to the P2K Composer ROM--including non-existant arp patterns. Maybe that's causing the sysex-too-fast error. Let me know if those are the files causing a problem for you and I will delete those and try a different conversion.

Steve

--- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@...> wrote:
>
> I am wondering if the outgoing midi out led is a sysex error message. Can you capture it?
> 
> Where are the P2500 --> P2K ROM files?  I will take a look to see if there are any obvious errors in the data.
> 
> Steve
>

My worn unit px7 has not manifested any problems but my unworn units have been problematic. Wear indicates performing well repeatedly.

--- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@...> wrote:
>
> I am wondering if the outgoing midi out led is a sysex error message. Can you capture it?

Yes, I probably could, by sending the dump from one computer and capturing the MIDI output on another, if nothing else. I'll see when I can get around to doing it. It doesn't seem to be sent for each received patch, more like every fourth or something of that order.

I wasn't aware that there were error messages sent via sysex; some sysex protocols use an ACK/NAK scheme but then the whole protocol usually involves a two-way handshake all the way.

> Where are the P2500 --> P2K ROM files?  I will take a look to see if there are any obvious errors in the data.

They're in the Files section, under Command Station Data -> P2500 Presets for CMPSR ROM .

/Ricard

--- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@...> wrote:
>
> I see that I posted a set in 2010. Is that the set you are having problems with? Based on the readme file, I see that I simply changed the ROM ID to point to the P2K Composer ROM--including non-existant arp patterns. Maybe that's causing the sysex-too-fast error. Let me know if those are the files causing a problem for you and I will delete those and try a different conversion.

Yes, that's the set. Although at the time it seemed that at least someone on the list tested it with success, which is why I think it's strange that I can't get it to work now.

As I mentioned, it's not just the Sysex: too fast that's the problem; when transferring the file with Bank 0 in it, my XL-7 stores up to patch 37, the patch names are there, etc, but looking at the Instrument assignments, they point to Instrument 0 of the CMPRS ROM which is None (I don't know if that's a true sample, or just a placeholder for "be quiet"). At least one of the Instruments seemed to point to another ROM I have in the machine (the XL-7 I believe) which I thought was strange. All the patches that the machine managed to download were silent, although I have not tried to determine if it's solely because of the Instrument assignments or there's something else in the patch that causes it to not play (i.e. volume set too low, no key range mapped, or whatever).

My spontaneous guess is that the ROM assignments in the files are wrong, so for each patch downloaded the XL-7 tries to locate it within the sample sets it actually has, which it fails to do, hence the incorrect assignments and ultimate error (because of some bug causing during the search process). I don't know enough about the XL-7 to know if this is even a reasonable thought though.

Is there anywhere one can see the ROM ID in the menus on the XL-7, or do you have to look in the sysex files for that? I was thinking that perhaps there are different versions of the Composer ROM with different ROM ID's. Normally one wouldn't notice the difference as the patches on the ROM always refer to the actual ROM in question.

/Ricard

/Ricard

--- In xl7@yahoogroups.com, Matt <somatt@...> wrote:
>
> My worn unit px7 has not manifested any problems but my unworn units have
> been problematic. Wear indicates performing well repeatedly.

In what way have they been problematic? I'm not sure what you mean by "Wear indicates performing well repeatedly."

My XL-7 is actually a PX-7 in disguise. My original XL-7 mainboard exhibited a problem whereby one would get clicks in the audio out when the machine was running warm (i.e. in my studio in the heat of summer). It turned out I could get a (used) PX-7 for the same amount it would have got me to get a replacement mainboard shipped from EPR electronics, so I did that and swapped the lower half of the PX-7 with my XL-7 and put both the XL-7 and PX-7 ROMs in the unit. I now have a spare unit which can be handy if some front panel item or the power supply fails. The only downside of all this is that the XL-7 now says "PX-7" in the display upon starting up. Not a big issue. Would be easy to fix with appropriate software, apparently, but only service facilities such as EPR can do this, on-site, which would mean I'd have to ship the board to EPR and back again...

(Yes, I could have moved everything to the PX-7 instead, but I like the XL-7 front panel graphics and color scheme better, and besides, the XL-7 parameter wheel had a better feel to it, being more worn (easier to turn)).

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.

Also, check out the "about these files" text file for an explanation of the 2010 banks and the 2013 banks.

As I wrote, I did not experience the sysex too fast problem loading the banks into an XL-1 fitted with the CMPSR ROM.  I did confirm that the ROM Instruments seemed to all be set to 000:None. I suspect that's because the ROM ID for the arp pattern in the 2010 files was pointed to non-existent resources (no arp patterns on the CMPSR ROM).

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.

Please note: As I have mentioned, the conversions are simply ROM ID substitutions. This creates problems when the source ROM has resources that the destination ROM doesn't. 

For example, if a preset uses an arp pattern not on the destination, the E-Mu will most likely lock up. That's why I set the arp patterns to User arp patterns. However, I suspect there can similar lock ups with presets that uses other non-existent resources.

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. 

Also, since I loaded the banks into a 12-controller box, the Preset Patchcords have non-existent sources (????). I assume that if you load them into a 16-controller box, you shouldn't have that problem.

If you or anyone else discovers more arp presets that lock up, please let me know and I can hand tweak those banks and reload them.

Steve

--- In xl7@yahoogroups.com, "Ricard" <ricard2010@...> wrote:
>
> 
> 
> --- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@> wrote:
> >
> > I see that I posted a set in 2010. Is that the set you are having problems with? Based on the readme file, I see that I simply changed the ROM ID to point to the P2K Composer ROM--including non-existant arp patterns. Maybe that's causing the sysex-too-fast error. Let me know if those are the files causing a problem for you and I will delete those and try a different conversion.
> 
> Yes, that's the set. Although at the time it seemed that at least someone on the list tested it with success, which is why I think it's strange that I can't get it to work now.
> 
> As I mentioned, it's not just the Sysex: too fast that's the problem; when transferring the file with Bank 0 in it, my XL-7 stores up to patch 37, the patch names are there, etc, but looking at the Instrument assignments, they point to Instrument 0 of the CMPRS ROM which is None (I don't know if that's a true sample, or just a placeholder for "be quiet"). At least one of the Instruments seemed to point to another ROM I have in the machine (the XL-7 I believe) which I thought was strange. All the patches that the machine managed to download were silent, although I have not tried to determine if it's solely because of the Instrument assignments or there's something else in the patch that causes it to not play (i.e. volume set too low, no key range mapped, or whatever).
> 
> My spontaneous guess is that the ROM assignments in the files are wrong, so for each patch downloaded the XL-7 tries to locate it within the sample sets it actually has, which it fails to do, hence the incorrect assignments and ultimate error (because of some bug causing during the search process). I don't know enough about the XL-7 to know if this is even a reasonable thought though.
> 
> Is there anywhere one can see the ROM ID in the menus on the XL-7, or do you have to look in the sysex files for that? I was thinking that perhaps there are different versions of the Composer ROM with different ROM ID's. Normally one wouldn't notice the difference as the patches on the ROM always refer to the actual ROM in question.
> 
> /Ricard
> 
> /Ricard
>

PS: If the 2013 version of the banks work for you, I will delete the 2010 versions and reorganize the folder (reword the write up, get rid of the whole thing about the errors, etc.). Please let me know.  Thanks.
Steve

--- 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

Thanks for testing them; glad they loaded OK. If you don't have arps in your user slots, just load some in or point it to an arp in one of your other ROMs. I count 8 arp:xxxxx presets in the P2500 ROM, although it has 299 arp patterns (plus one --empty-- pattern). I haven't played around with copying ROM arp patterns to user arp slots, but I think it can be done. If so, it would be possible to save the arp patterns for those 8 arps and upload them.

Please let me know if there are any other glitches with the 2013 set so I can try to fine tune them by hand. I will remove the 2010 banks.

Steve




--- In xl7@yahoogroups.com, "Ricard" <ricard2010@...> wrote:
>
> --- 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
>

--- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@...> wrote:
>
> Thanks for testing them; glad they loaded OK. If you don't have arps in your user slots, just load some in or point it to an arp in one of your other ROMs. I count 8 arp:xxxxx presets in the P2500 ROM, although it has 299 arp patterns (plus one --empty-- pattern). I haven't played around with copying ROM arp patterns to user arp slots, but I think it can be done. If so, it would be possible to save the arp patterns for those 8 arps and upload them.
> 
> Please let me know if there are any other glitches with the 2013 set so I can try to fine tune them by hand. I will remove the 2010 banks.

I'll try out some more patches. At any rate they are a very definite improvement over the 2010 set.

BTW, the program you've used to manipulate the sysex files, is that something you've written yourself? 

/Ricard

Yeah. "Syxer" started out as being the first step in a sysex display/analyzer program (MS-DOS command line program). Every couple of years or so I tweak it. One of the tweaks a few years ago was to compile it so it runs in windows as a command/cmd program. I think the original command-line code is still there, but none of the newer functions are in the command-line parser.

The fanciest things it does is (1) report some basic stuff (ROM IDs, list of preset names, packet by packet hex display, etc.) for any number of consecutive presets in a *.syx bank and (2) allows for the simple substitution of the ROM IDs in a bank of presets.

I have written about it here and in the P2K user group, including ideas for expansion--if I had time or people willing to compile info about the different e-mu ROMs. To read more, search this group and the p2k group for "Syxer."

It was originally written using Borland Pascal, but in recent years I have used the dev-Pas IDE (from Bloodshed) which uses Free Pascal. I have tried (unsuccessfully) to talk my son into recoding it for java or something like that. It might be nice to have it as an online tool.

Steve

--- In xl7@yahoogroups.com, "Ricard" <ricard2010@...> wrote:

[snip]

> BTW, the program you've used to manipulate the sysex files, is that something you've written yourself? 
> 
> /Ricard
>

Steve, aren't you having deja-vu? I had this exact problem a few weeks ago when we discussed it. There is clearly something wrong with the older versions of the P2500 - > Composer SYX files. The "Ver4" you posted more recently did work for me, but the FX send amounts are not translated (in 12 knob machines) because they are linked to controllers N & M.

Regards,
Ken

--- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@...> wrote:
>
> PS: If the 2013 version of the banks work for you, I will delete the 2010 versions and reorganize the folder (reword the write up, get rid of the whole thing about the errors, etc.). Please let me know.  Thanks.
> Steve
>

LOL!  I didn't make the connection until you mentioned it.  I assume you are referring to this thread: http://launch.groups.yahoo.com/group/p2k/message/15878 . I didn't re-read that thread, but perhaps I didn't make the connection because that was about the PK-6 banks converted by Sika.  (Or did we discuss the P2500 to P2K conversions, too?)

I know I wrote (in the P2K group) about the complexities of doing more than simple substitutions using Syxer. I have indeed thought about it, but do not anticipate having the time needed. Hmmmmmmm. Maybe I could try a few simple things--testing for the presence of cords using MidiM -->MidiP and converting them. I know I wrote about that in the P2K group. I could automate a simple substitution for the FX send. Let me re-read that thread.

Steve 

--- In xl7@yahoogroups.com, "K2500X" <ken1978ny@...> wrote:
>
> Steve, aren't you having deja-vu? I had this exact problem a few weeks ago when we discussed it. There is clearly something wrong with the older versions of the P2500 - > Composer SYX files. The "Ver4" you posted more recently did work for me, but the FX send amounts are not translated (in 12 knob machines) because they are linked to controllers N & M.
> 
> Regards,
> Ken
> 
> --- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@> wrote:
> >
> > PS: If the 2013 version of the banks work for you, I will delete the 2010 versions and reorganize the folder (reword the write up, get rid of the whole thing about the errors, etc.). Please let me know.  Thanks.
> > Steve
> >
>

Footnote:
Here's the link to the discuss of FX Send patchords: http://launch.groups.yahoo.com/group/p2k/message/15887 .

In short, the P2K presets seem to use MidiK and MidiL which are used by the P2500 presets for something else. Searching for controller usage in the patchcords, finding available controllers, and juggling the patchcords would have to be quite involved. I am not quite ready for that challenge, but I will give it some thought as it goes in the direction of the "Parametizer" software I mentioned.

Steve

--- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@...> wrote:
>
> LOL!  I didn't make the connection until you mentioned it.  I assume you are referring to this thread: http://launch.groups.yahoo.com/group/p2k/message/15878 . I didn't re-read that thread, but perhaps I didn't make the connection because that was about the PK-6 banks converted by Sika.  (Or did we discuss the P2500 to P2K conversions, too?)
> 
> I know I wrote (in the P2K group) about the complexities of doing more than simple substitutions using Syxer. I have indeed thought about it, but do not anticipate having the time needed. Hmmmmmmm. Maybe I could try a few simple things--testing for the presence of cords using MidiM -->MidiP and converting them. I know I wrote about that in the P2K group. I could automate a simple substitution for the FX send. Let me re-read that thread.
> 
> Steve 
> 
> --- In xl7@yahoogroups.com, "K2500X" <ken1978ny@> wrote:
> >
> > Steve, aren't you having deja-vu? I had this exact problem a few weeks ago when we discussed it. There is clearly something wrong with the older versions of the P2500 - > Composer SYX files. The "Ver4" you posted more recently did work for me, but the FX send amounts are not translated (in 12 knob machines) because they are linked to controllers N & M.
> > 
> > Regards,
> > Ken
> > 
> > --- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@> wrote:
> > >
> > > PS: If the 2013 version of the banks work for you, I will delete the 2010 versions and reorganize the folder (reword the write up, get rid of the whole thing about the errors, etc.). Please let me know.  Thanks.
> > > Steve
> > >
> >
>