Does the FP50 accept system exclusive Data Request?

[crlMIDI]

Hi, this question could also apply to the Roland FP30, which has a similar MIDI implementation.

A few years ago I wrote a microtuning application for my Roland JV1010 that splits the keyboard into 1 MIDI channel per octave, so that each individual note can be microtuned using the Scale Tuning settings. I'm interested in historical temperaments. I had to stop because the old JV stopped working.

The details are in the link so it's sufficient to say here that I used an Arduino microcontroller with its MIDI code library, and the PC is used only as a terminal for sending commands and receiving the responses.

I recently acquired an FP50 and am trying to port the application to the different address map. Unfortunately, the FPs don't seem to allow you to send a Data Request (sysex command 11h). Just in case I've messed up because of the time that has passed, please could someone confirm this?

It would be possible to do without Data Request, but that would involve re-writing some code, which one tries to avoid doing. Anyway, I'm cautious and like to check what I've done to the instrument!

 

[SeaGtGruff]

On page 11 of the FP-50's MIDI Implementation document it says:

■Individual Parameters
Individual Parameter Transmission transmits data (or requests data) for one parameter as one exclusive message (one packet of “F0 ..... F7”).
In Individual Parameter Transmission, you must use the Address and Size listed in the following “Parameter Address Map.” Addresses marked at “#” cannot be used as starting addresses.

I don't see a similar comment about bulk data requests; the only references to bulk data are for transmission. Of course, that doesn't necessarily mean you can't request data in bulk; but if bulk requests don't work, you could try requesting just the individual parameters.

There's an example of setting the scale tuning for the 12 notes of channel 1 on page 19, and I see that-- unlike Yamaha's XG Scale Tuning messages, which are sent one note at a time-- you must set all 12 notes at once, and I assume you also request and receive all 12 notes at once.

 

[crlMIDI]

Thanks.

Your reply helps rephrase the question about Roland equipment.

The example on page 19 does indeed modify all twelve notes of a part (associated with a MIDI channel).

On my old JV you could change just one note at a time by giving the appropriate address (40 to 4B in the FP), as indicated on page 14. It was the same as on page 19 except that you could change the address LSP and send only one data byte.

I'd missed the # Individual parameters information in the FP manual, but it doesn't matter because I can always send the previous scale with one note changed. However, as I said it's a pity to have to rewrite and debug software for each instrument model.

I haven't yet tried Setting data on the FP as I was hoping first to find a means of checking my transmissions by reading the data back from the instrument.

With the JV I could first verify the current value for the note being changed by sending a Sysex Request (byte 5 = 11h instead of 12h for Sysex Set). That way, my program handles correctly any bugs or missed transmissions.

The FP manuals make no mention of Sysex Request and my FP50 doesn't respond to those messages. I found no information or comment on when and for which models Sysex Request seems to have been removed. This seems surprising, because it prevents programmers from following normal error-catching and debugging practice. I guess I'll have to track bugs by sending wrong notes and listening to them!

 

[SeaGtGruff]

According to the FP-50's MIDI Implementation document, you can't set the Scale Tuning for individual notes; you must set them as a block of all 12 notes. It doesn't say this in so many words, but it does say that addresses which are listed with a hash mark (#) after the low byte cannot be addressed directly, or something like that, and the addresses for C# through B all have hash marks after them.

Also, even though the document seems to imply that you can use Data Request 1 (DR1) GS commands, there are no examples or explanations about this, so it may well be that the FP-50 just ignores them. I know that my XGlite Yamaha keyboards appear to ignore any XG Parameter Request and XG Dump Request commands.

But on the chance that DR1 commands are indeed recognized, just make sure you've modified your code to send the correct number of bytes for the address, since the FP-50 has 3-byte addresses, whereas I think the JV had 4-byte addresses?

 

[crlMIDI]

It gets worse. The arabian scale example on page 19 of the MIDI implementation document (FP-50_MI.pdf) gives the wrong checksum (50hex). The correct value is 76hex.

I thought it was dotage on my part, but MIDI Tools confirms this; MIDI Tools is part of a professional offering, and is effectively free for hobbyists. My own implementation in C++ on an Arduino microcontroler also gives 76hex. Finally, before going completely mad, I set up the calculation via decimal numbers in LibreOffice Calc. The file is attached because I haven't seen a spreadsheet to do Roland checksums, and there's a hidden trap with the HEX2DEC function.

The example of a checksum calculation (only 1 data byte) on page 18 is correct.

It's hard to know what Model ID to use for example for Data Set (page 9) because the manual doesn't state what state the instrument is in when you switch it on. Is it always GS (ID 42h) or something else that's kept secret?

The FP-50 did kindly reply to the Identity Request message on page 8, but so far not to anything else I've sent.

You're right that the JV had 4-byte addresses and you could change one note at a time.

While I'd missed the address hashtag you mentioned, I did notice that the memory map for part parameters is not in MIDI order: memory blocks start with part/channel 10, which gets block number zero. OK, it's nothing much and percussionists might like it, but it means you have to add a lookup table or something to code you hoped was stable.

Apart from errors, which have been remarked upon in the past, perhaps the worst thing about Roland's MIDI implementation documents is their chaotic layout and typography, which has not changed since my JV manual dated 2000. Essential information is scattered all over the place, and those circles and squares for delimiting sections are very hard to follow. Why can't they use hierarchical section numbering like everyone else?

 

[SeaGtGruff]

I hadn't even looked at the explanation of how to calculate the checksum in the documentation, or tried to calculate it myself. It's disappointing that the documentation contains the wrong checksum value, but I guess I'm not too terribly surprised, as it seems like the quality of manuals has been declining over the years, especially for less-expensive models. It's as though less importance were placed on proof-reading the manuals for those models, or the average user isn't expected to be able to comprehend the material unless it's simplified and abbreviated (i.e., dumbed-down).

I did notice Roland's crazy part-numbering some months ago when looking at a manual for a different model. I'm not sure why they did that. It could be so that the drum part comes first-- or I guess it could even be so that parts 1 to 9 are numbered as 1 to 9 rather than 0 to 8.

EDIT: As for the model ID, one might hope that it would always be the same for reasons of consistency and sanity, but I know that with Yamaha keyboards it can vary depending on the specific type of SysEx command-- e.g., XG commands have one ID, but style-related commands have a different ID.

 

[crlMIDI]

I think I can now answer my own question: the FP50 does not accept system exclusive Data Request.

This contradicts the quote from the manual given above by SeaGtGruff, Jul 25, 2017. In particular, the "size" (number of bytes requested) is mentioned here and given in the table of System Parameters; size is needed only for Requests and therefore the Roland document is misleading. I read it before buying my FP-50 and so was misled.

The Identity Request Message (page 8 of MIDI implementation manual) (F0 7E 10 06 01 F7) elicited the response Identity Reply given on page 10. That proves my setup works bidirectionally.

The Arabian scale (page 19) set to part/channel 1 with the corrected checksum of 76 did change the scale setting:
F0 41 10 42 12 40 11 40 3A 6D 3E 34 0D 38 6B 3C 6F 40 36 0F 76 F7
Note that the model ID has to be 42h (GS; see Data Set 1 (DT1) on page 9).

I could set, for example, quarter-tone mean temperament on channel 3:
F0 41 10 42 12 40 13 40 40 28 39 4A 32 43 2B 3D 25 36 47 2F 54 F7

However, Request Scale Tune messages never elicited a response. For channel 1 the sysex is
F0 41 10 42 11 40 11 40 00 00 0C 63 F7
Same result if the leading 00 00s of the size parameter 0C are omitted.
This sysex, modeled on the Data Set messages above, is very straightforward and I am sure it is correct.

Note for anyone new to this game: the keyboard and the parameter settings of these instruments are not assigned to any MIDI channel within the instrument. Notes you play are exported via MIDI out on the channel you set, and your external device has to send them back to MIDI in. It also has to generate all the other commands you will need like tone (patch changes).

Finally, I lost some time because MidiOx stopped working after a Windows 10 compulsory update (Microsoft is in the process of exterminating software it disapproves of). I can't use Linux because my Prodipe 4x4 MIDI interface hasn't got a driver; I'll have to wire up an Arduino to replace it. My tests were done under Windows using Bome SendSX and Midi Tools. SendSX has a MIDI thru. So does Midi Tools (which as a bonus does your checksum calculations), except that the free offering adds some funny notes.