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
Show quoted textHide quoted text
> > the code, I will check to see if I used the XOR.
> >
>