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

See below.
--- In xl7@yahoogroups.com, "Keith Young" <emigr8@...> wrote:
> In then end I found that if I set the checksum to 0x7f
> it works. It shouldn't, but it does. I think it's a bug.

Its by design, not a bug. In fact, its in the sysex manual somewhere 
(0x7f = ignore checksum). Perhaps there were different people 
working on the sysex or it was inherited or something screwy was 
going on, so someone said, "Hey, let's make 0x7f a special case to 
ignore checksum!"

Sorry I didn't point that out in my previosu post.

> As for the Single Note Change, it is doing nothing for me. I would 
> expect to be able to send it and get an immediate effect when I
> play the note (I don't). If I send a whole table, it works fine.

I played around with it for about 10 min after doing the bulk dump 
and didn't get anywhere. I am thinking perhaps the bulk tuning dump 
works on tuning tables shared by the front panel and sysex, while 
the single note works purely by sysex independent of front panel 
changes. (There's the standard note somewhere in there to the effect 
that if you change it by remotely, subsequent changes need to be 
done remotely, too.)

Some footnotes that I discovered, but didn't chase too far:
(1) Tuning Table Requests (Bulk Dumps) start from 0 and actually go 
to something like 59, but after 12, you just get the last tuning 
table data, though if I remember correctly, the header makes it look 
like there are additional table.

(2) As you noticed front panel fine = 63 corresponds with 0x7f. 62 
coresponds with 0x7d, etc. You may have also noticed there is a 
third byte after coarse and fine. I tried sending intermediate fine 
values and third byte values. They did not get sent back with 
subsequent requests.

(3) There is a keyboard tuning parameter (in the middle of the 
controller parameter, I think). You may have noticed that the user 
tuning tables come at the end.

So, I was thinking that the "on-the-fly" single note tunings go 
somewhere (an undocumented table?) after the OS pulls (1) the 
keyboard tuning value and (2) if its a user table, the user table 
settings. This would make sense, esp. if the "on-the-fly" changes 
affect the built-in tunings.

That's as far as I got. I didn't test this out, though. I suppose to 
test it, I would use on of the built in turnings, audition some 
basic riff, send a sysex with whacky single note tunings, and just 
listen. 

Perhaps there are three values in the user tuning tables because all 
three ultimately get copied into an undocumentable table from which 
we don't know if we can read/request the values.

Hmmmmmm. I love logic puzzles like this. Maybe I will try to free up 
some time to test it.

--Steve




> 
> --- In xl7@yahoogroups.com, "steve_the_composer" <smw-mail@> wrote:
> >
> > Just did a quick test as follows [on XL-2500]:
> > 
> > (1) On C-2 of USer Table 1 I changed coarse to 127 and fine to 
63.
> > (2) I requested table 1: f0 7e 00 08 00 00 f7
> > 
> > Here's the first part of the dump:
> > 
> > F0 7E 00 08 01 00 [header]
> > 55 73 65 72 20 54 75 6E 69 6E 67 20 30 30 30 20 [name]
> > 7F 7E 00 [C-2]
> > 01 00 00 [C#-2]
> > 
> > (3) I then changed C-2 back to its original
> > 00 00 00
> > 
> > (4) Since I added 03, I subtracted 03 from the check sum.
> > 37 became 34
> > 
> > (5) I then sent the dump back and since I had the table up
> >  on display, I saw the 127 and 63 change back to 000 and 00.
> > 
> > I imagine the other P2Ks should work the same way.
> > 
> > BTW, I seem to recall on the P2K message board a few of us 
> discussed 
> > tuning systems. This was a year or two ago.
> > 
> > I will check out the single note change.
> > 
> > --Steve
> > 
> > PS: My checksum calculation (Roland gear) was either for the 
> > Commodore 64 or the Intel 8086/8088 and may have been in 
assembly 
> > lang. I would have used an 8 bit variable, shifted left, then 
right 
> > to drop the 8th bit and finally subtracted from 80h. If I ever 
find 
> > the code, I will check to see if I used the XOR.
> >
>