Reversing the UNO Pro #6
Comments
|
When sending something like Feeding this one back results in |
|
In the response This means that the request will need to be 'adjusted'. It could be that the Pro is more like the Drum which separates patches into Kits & Patterns, rather than having 1 item. You can slowly increase the numbers of bytes (zeros?) you send until the Synth accepts the command, and then figure out what the bytes do. Another thing to note is that I sometimes saw a response with a lower cmd value - for example CMD 0x33 to change preset would have 0x32 in it's response. As you saw 0x32 being sent from device perhaps these are async messages, replies without a CMD, I also sees these in my logs from the Drum. Anyhow build confidence that CMD 0x33 is for setting which present is active. |
|
Next suggestion? Maybe add same bytes from 0x32 to CMD 0x33... ie select patch 5 with Maybe the two vales are patch & sequence pattern? |
|
Noted the Drum replies (0x32) in double bytes, so maybe the Pro just uses 2 bytes for selecting preset Yes... Pro has 256 presets, so it MUST use 2 bytes. Note Midi is 7 bit, so |
|
Hello from the future! I'm interested in working on reverse engineering the Uno Pro spec assuming it's not been done yet. The data in this thread is about two years old: does anyone know if further progress has been made? Such as identifying the patch-request sysex command? |
|
Hi @SeanLuke personally I never got my hands on a Pro, so haven't done any real investigates. Above was from discussion with another user... Willing to offer any help/encouragement I can. |
|
Okay, here's what I have ascertained at first glance. REQUEST PATCH NAME: [Patch names are for some reason independent of patches] RESPONSE: NAME... is a non-zero-terminated string of UP to 14 characters, WRITE PATCH NAME: NAME... is a non-zero-terminated string of UP to 14 characters. REQUEST CURRENT MEMORY: RESPONSE: DATA... is 294 bytes long. It appears to be a simple parameter byte encoding. WRITE PATCH: DATA... is 294 bytes long. It appears to be a simple parameter byte encoding. At present I don't know how to request a patch (other than doing a PC, then requesting from current memory, which is suboptimal). REQUEST PATCH CHUNK: [ Unknown Function. This happens when copying a preset in the librarian but why I don't know ]] CHUNK goes 0...4 RESPONSES: [To each chunk request] Chunk 0 is 305 bytes total SETTING PARAMETERS: UNKNOWN: [ This shows up sometimes ] RESPONSE: |
That's some pretty awesome info! It might be helpful to identify/hilight the 'CMD' byte(s), and if you haven't noticed the response appears to include a 'error' byte (
Perhaps it's telling you the [current patch], followed by the [patch] for the data. Note: SysEx/Midi is 7bit, so two bytes is actually 128 * 128 max value.
Can you provide a hexdump/example?
Did you try replacing the
Why is this more data than the 'request current patch'? Do you see the same data structures? Perhaps into also includes sequencer info.
Note: I found that the SysEx setting of parameters allowed for finer resolution.
CMD 0x11 used to enter device mode?
CMD 0x21 write setup parameter?
CMD 0x33 = switch to preset? |
|
Some more. When SONG is pressed, this unknown command is emitted by the machine: Then this unknown command is emitted
Sure. After loading patch 0 bank 0 into memory, here's the current memory dump:
Here's patch 0 bank 0 chunk 0: Here's chunk 1: Here's chunk 2: Here's chunk 3 Here's chunk 4 I note that these chunks have different lengths (at least chunks 1-4) than described earlier. I can't explain that.
Yeah. I'm guessing that chunk 00 is the patch data. |
|
More.
It appears to be the same structure. So chunk 0 is probably the patch data.
Thing is, the unit emits CC, and the editor also emits CC. And you're right, they're not fine enough! But I don't know what the sysex equivalents should be. Also this appears to be NAK: UNKNOWN varies: it might be the remaining bytes in the original message? Not clear.. COMMAND is in response to your particular command. So if you sent something like ["Request Chunk #5 from patch 0 bank 0" -- there is no chunk #5] You'd get back: |
On the original you could use the 'write current patch' (CMD 0x30), but only send one (or a few) parameters/values.
Yep, |
As you note this is similar format to that from "Chunk 0". It doesn't really look like Original's format, which was a sequence of parameters/values. as described here: For the UNO Drum they implemented some really weird stuff, and this made it hard to understand what was what.... if you change a single parameter slightly, does that change show in hexdump? Does change in data make logical sense...
The 0x3F is very suspicious. Midi/SysEx is only 7bit, I've seen multiple different devices pack 8bit data into 7bit to send across Midi. You may need to unpack 7bit->8bit before the patch data makes sense, Examples: Are you able to save a patch (from the editor) to hard-disk? What format does that have? |
|
Hi all, here's »Above was from discussion with another user« :) . Thanks for sharing your findings. I was able to request patch names from my Pro. I also was able to fetch "current memory" by F0 00 21 1A 02 03 37 00 00 F7. Did you have any luck requesting a particular preset (or even request all presets) in order to do a backup? |
|
I now have the editor running on a Mac as well as MIDI monitor. When pressing "Get" in the editor, the Uno Synth Pro sends all 256 preset names as SysEx. |
|
When I select all presets on the Uno Synth Pro in the editor window and press "TO LIB" (which means dumping all presets to the Mac), the Uno transmits 1280 SysEx messages of different sizes, potentially 5 per preset. |
|
When I try to fetch presets 1 by 1, e.g. Preset 1, then preset 2, then 3 and then 4, the Uno always sends 5 SysEx messages. However, the length of those messages differs per preset, see hardcopy attached. At least the first one always consists of 305 bytes. |
It seems that the UNO Pro is a least a little similar to the original, obviously the storage size will be a lot bigger.
https://cgi.ikmultimedia.com/ikforum/viewtopic.php?f=43&t=27841&p=120259#p120259
The Pro does not respond to the enquiry message:
F0 7e 00 06 01 F7
It does respond to the version inquiry:
f0 00 21 1a 02 03 12 f7
Response:
F0 00 21 1A 02 03 00 12 01 31 2E 30 2E 31 20 23 23 2E 23 23 20 23 23 2E 23 23 00 F7
Interestingly, the Pro emits SysEx when scrolling through presets, like this:
F0 00 21 1A 02 03 32 00 01 00 01 F7
F0 00 21 1A 02 03 32 00 02 00 02 F7
F0 00 21 1A 02 03 32 00 03 00 03 F7
The text was updated successfully, but these errors were encountered: