I need help reading the names of UB-Xa patches. When triggering a dump from the panel, the UB-Xa dumps 8 sysex dumps for each sound. All in all 1024 sysex dumps for each bank. (8x128=1024). When I read the documentation that I uploaded here, it looks like the names are in positions 78-93, 16 characters. I can also read that each parameter contains two 7 bit characters for a 16 character patch name. Can someone explain to me how I can see the names as ASCII? The first name in Bank A should be Brass Ensemb… something. The display do not show all 16 characters.
I posted a request trying to decipher UB-Xa Patch names over at the Gearspace forum (Behringer UB-Xa - Owners Discussion). I received a reply but it looks I need a Computer Science degree to figure out the answer. Still no luck.
“Posted by Mr_Mojo_Risin
Any new details available about your solution for decoding ASCII Patch Names?*
Posted by Willx:
Briefly, each pair of characters (where ascii is 7-bits normally stored in a byte of 8 bits) is bit-packed together into 14 bits, but then that is ordered little-endian (least significant byte first). So there’s a bit-shift (to shift the first byte into the second byte) and then a byte-swap (to put the second byte first). Thus the “every other byte matching” that I was seeing (from the byte swap) plus the “some bytes match if you do a bit-shift”.
The useful clue was in the sysex pdf where it says each pair of characters in the patch name has “value range” of “0,16383”. Two normal bytes would be a value range of 0-65535 (or 0-32767 if you ignored the high bit on the first ascii byte). But this said 16383 which is ie 2^14. So 14 bits, which requires the first byte to be bit-shifted into the second to get the 14-bits. But the pdf does *not* make it clear that the 2 bytes of 14-bit data are then little-endian (LSB) so ie that made things less apparent.
And note this is *separate* from the normal conversion of 7-bit midi data to 8-bit patch data. So ie 2 decodes (7-bit to 8-bit for the sysex data as a whole, and then unswap/unshift each pair of bytes in the patchname to get the ascii chars).
I’ve no idea *why* they use that particular encoding (the bit-packing doesn’t end up saving any space). Maybe it’s how the hardware expects it, so it’s easier to send it that way rather than converting for it. Maybe it’s what the original OBXA hardware did and they reproduced it exactly? No idea.”*
That’s a ‘standard’ encoding method for 2 bytes of sysex info. Lexicon’s PCM 80/81, others have this type of double compression. If no one posts an algorithm to decode it, I’ll put something up Monday. I’ve done this for other sysex implementations, so shouldn’t be too bad.
And I’m looking forward to your sysex parsing of the UB-Xa. Will you use standard parsing methods from the E1, or will you write your own parsing logic in lua?
There was a holiday here and we had family over, so I had less time than planned.
Looking at the dump, I noticed that each packet is a separate sysex transmission. So they’re a lot of 0xF0 … 0xF7 blocks. That was throwing me off at first. No idea how the E1 will handle all these separate packets since each one has the same header. Code will be needed to deal with that I would think.
In any case, I’ll keep working on the parsing aspect of it.
If you look at the numbers marked in yellow, you can see that the header (01) and 7 packets (02) have different numbers (00-06). It could be used to distinguish the different dumps.
Then the dump should be unpacked and finally some magic with the patch name.
It seems that the numbers that are highlighted are the numbers that should be used in the checksum calculation. If that is correct, Behringer has not followed the File Dump standard100%. The standard says that all bytes except F0, Checksum and F7 should be included. The checksum in this example is 07 and that is what the php script also calculates.
For sysex messages the checksum is for the receiver to verify the data is unchanged. The manufacturer ID, model, etc in the header is never included, only the data portion.
Patchname, this is where I do not understand, please help me @oldgearguy I don’t even know which packet number (0-6) the name is in? The UB-Xa manual says offset 78.
Please correct me if the unpacked data is not correct.
I don’t really know how to solve it right now. You can see which of the 6 dumps is coming into Electra with the help of packet count. So you should be able to use the standard parsing method.
The request and response are not tightly coupled. A preset may have many responses defined. Electra will pick and process all of them. Also, sending the request is not mandatory for processing the responses.
If the data is transferred as multiple packets, the common header bytes should be defined to detect them and Lua used to assemble the complete message.
So I could request a patch dump and if the synth sent back 7 sysex messages (all with the same 0xF0 .. header .. data .. 0xF7 format) the Electra One would process all of them and strip the F0/F7 and concatenate the messages?
Or - I would need to use Lua to understand I’m seeing message 1 of 7, 2 of 7, etc?
