Hello, by all means attach your question as a follow message (reply) to this thread. So we keep everything together.

Note, there has been some discussion just recently regarding SYSEX on a different Yamaha device, you should have a look at that and see if there is any useful help there?

Geoff

I can get a dump of my TG100 tone generator's parameters by pressing buttons on the unit,
but I can't get it to respond to a sysex request.

There must be something wrong with the message I'm sending.

The gory details are here http://ncvp.co.uk/tg100

Thanks in advance for any assistance.

- Nick

Hello Nick,

I'll have to get part of the manual through. I'm not sure I want the whole thing, I'd really need just the bit with all the technical midi stuff.

I've got the manuals for my own Yamaha MU90r, which may or not help.

If your setup will send a midi file, you might find things easier to create a midi file containing your sysex string, rather than have to re-enter the sort of data you're doing. May be easier to try small adjustments? But that's your choice.

I note that you show two strings, one that works, another that doesn't. But the headers are different? I would have expected that for strings of the sort you're trying, the first three data bytes (after the F0H for systex) should be the same, i.e. 43H for Yamaha, nnH for device number, nnH for Model ID. Your examples show two bytes matching, the third is not. Is this correct?

For my MU90r, the CHK is required where there is a variable ## of bytes data. If the Dump Request is asking for a defined block (i.e. a specific and invariable ## of bytes) then a CHK is not required.

Do you have any midi files that include sysex for your device? This may give some hints as to the exact structure of the sysex. I have quite a few Yamaha XG specific files for the MU devices, and these work on my MU90r as well.

More later.

Geoff

Hello again,

Right, I've got the manual with the relevant data in.

Firstly, I note that there DO seem to be differences regarding the third byte, so your examples may be OK.

I've seen that page 74 contains a detailed example of the Dump Request command. Esp regarding the LM_0068RQ data, which is entered as hex values of the ASCII data, including literal spaces i.e. 20H.

Also, I'm not sure if your example was doing this, but the CHK should incl the start address as well as the data and the CHK - where a CHK is required.

Geoff

Hello Geoff,

Thanks for your replies.

Page 74 of the manual seems to be key, and shows the skeleton of the dump request sysex I'm trying to send. As you point out, the structure of this message is different from all the others. A couple of notes on this page are particularly gnomic:

1) "Data is correctly processed if the Dump request receive address corresponds with the Start Address and the Dump Requests' byte count is correct". I don't know quite what this means, but I assume that asking for the 10 bytes from 30 00 00, which is what the manually initiated dump sends in its first message, should be valid. This coresponds to 30 00 00 00 01 02 in the 6 bytes of start address and byte count.

2) "The check sum's lowest 7-bit value is zero after adding the Start Address, Data and check sum" This surely means that the sum of the 3 address bytes, the 3 byte count bytes and the checksum must be 0 mod 7F, and 30 + 01 + 02 + 4D = 80 = 0 mod 7F.

Puzzling on...

- Nick

Hello Nick,

Looking in some detail. Counting bytes. Looking at tables. *&$*%!*

I'm not certain, but I THINK the byte count you have in your data is not correct.

According to the table, the partic data you're looking for starting at 30H, 00H, 00H should be 10 (0AH) bytes.

The byte count values are using 7 bit numbers, i.e. each byte can take up to 127 (7FH).

Your data shows 00H,01H,02H. I make this 128 + 2 = 130.

10 (0AH) would be 00H,00H,0AH as this fits into 1 byte regardless of it being 7 or 8 bits.

How did you determine the values YOU show for the byte count?

Geoff.

Hi Geoff,

You're quite right. I made an error in the address bit shuffling, so I think the complete message should be:
F0 43 10 7A 4C 4D 20 20 30 30 36 38 52 51
30 00 00 00 00 0A
00 00 00 00 00 00 00 00 00 46 F7

Unfortunately, the TG100 also remains silent when sent this message.

I've corrected my notes at http://ncvp.co.uk/tg100/

- Nick

You say - the TG100 remains silent. What does that mean?

When you send the command that works, what does the TG100 do then. Does it say something, do you get something back, or have you determined otherwise that the command DID work?

With this new command, I'd expect that you should get data back (which you did not before?). Is the console command set to receive as well as send, should it display, or do what, with anything coming back? The low level process for sending data is different to the process for receiving.

I think your little pic showed that midi OUT of the TG was connected to midi IN of your computer, to get something back.

Geoff

I mean that even with the corrected dump request the TG100 does not output anything.
The hardware configuration remains as shown in http://ncvp.co.uk/tg100/hware_01.jpg
I use amidi in Linux and Cakewalk in Windows 10.
Pressing the appropriate buttons on the TG100 generates the same "dump all" file in Linux and Windows.
Playing midi files in Linux and Windows works normally.
Sending F0 43 10 27 30 35 06 00 15 F7 (4.1.9 All Parameters Reset, page 73) works in Linux and Windows.

- Nick

Hi Geoff,

Success!

Derek on the Yamaha Musicians Forum suggested setting the device number to 20 rather than 10.
This caused the TG100 to burst into life and issue dump messages.
The message I received in response to:
F0 43 20 7A 4C 4D 20 20 30 30 36 38 52 51
30 00 00 00 00 0A
00 00 00 00 00 00 00 00 00 46 F7
exactly matched the first in the "dump all" output here http://ncvp.co.uk/tg100/tg100_dump_all.txt
I hadn't picked up that 20 in the device number specified a dump request and 10 a dump reply. (I still haven't found it anywhere in the manual)

Just to confirm, I sent:
F0 43 20 7A 4C 4D 20 20 30 30 36 38 52 51
30 02 00 00 00 18
00 00 00 00 00 00 00 00 00 36 F7
requesting the 24 bytes of Multipart 11, and the TG100 responded with:
F0 43 10 27 30 02 00 38 00 0A 01 08 00 40 64 08 08 00 7F 04 40 40 40 40 40 02 0F 00 40 00 00 3B F7
which again matched the appropriate message in the "dump all" response.

Thanks very much for your help.

- Nick

Nick,

Sorry to be pedantic...

A 'Dump Request' is where you tell the device to send certain data back to the computer. It would not change anything on the device.

So the second line of your earlier message is wrong??

Regarding the sysex, we were using 20, and that message WAS a Dump Request. I'm not following why that wasn't working. I can understand that the resultant dump had the 20 replaced with 10.

Correction. Yes, your original data WAS 10. The table in the manual DID show 20 (p.74). I didn't spot that (it's in binary !!).

Great that you've got it working anyway. Once you've solved the basic 'theory', it should be OK to get all the separate details working??

Geoff