Rasputin wrote:Also, think you can reverse that process by a similar manner?
Could you test this file?
Sad to report that it did not work.
The transfer worked fine--it did not end prematurely--but the resulting sample pads are empty. I know that the RZ-1 nulls out the sample memory if it detects something invalid**
, so there may be a special byte needed at the end. I will look into this to see if it is applicable to the non-loading issue at hand.
** for the curious minded, there are also certain checks at boot to see if there are invalid data such as out-of-range tempo, etc. and the RZ-1 will reinitialize all battery backed RAM space if this is found to be the case
Here is how to calculate the needed byte. It's important to note that this byte replaces
what would be the last sample byte entirely, and is not
just tacked onto the end of the wave data.
Last byte in sample RAM (before turning into high/low nibble bytes) -- these would be the final two bytes directly before F7 when in SysEx form:
bit 0~4 = unused; all must be 0 or sample RAM will reinitialize on boot -- if bit 0, 1, 2, 3, or 4 are set then configuration is corrupt
bit 5 = SAMPLE 1~4 linked (must be exclusively set); hexcode of $20
bit 6 = SAMPLE 3+4 linked (can be mutually set w/ bit 7); hexcode of $40
bit 7 = SAMPLE 1+2 linked (can be mutually set w/ bit 6); hexcode of $80
SAMPLE 1+2 paired and SAMPLE 3+4 paired = hexcode of $C0
SAMPLE 1, 2, 3 and 4 are not linked (each pad independent) = hexcode of $00
Odd technical minutiae regarding the RZ-1 sampling feature:
Sample pads 1, 2, and 3 all hold the same amount of sample data. Sample pad 4 actually holds slightly less than any of the other pads, so it ends up being imperceptibly shorter than the rest -- about 2 samples fewer. The last couple bytes of sample RAM are used to hold general data instead of sample points.
Edit: This was indeed the issue. Changed both bytes before the F7 to $00 (re-nibbilizes to $00), enabling all sample pads to sound separately.