SOUND ON SOUND

[nathanscribe]

So. I've got a 27 byte sysex configuration file that I can't find any way to send to the device from my old Mac running 10.9.5 (I know, I know)

I've tried Sysex Librarian (doesn't read the file properly, thinks it's only 3 bytes), Logic 9 (impossible to work out how to do literally anything with sysex in this frankly dreadful nightmare of an application), and Mixbus doesn't do sysex at all. The file itself is fine, it opens in a hex editor with no trouble.

Any other options? It's driving me up the wall.

[desmond]

Snoize!

https://www.snoize.com/sysexlibrarian/

Never had a single problem with it.

Can you upload the file to see it?

[nathanscribe]

Snoize!

https://www.snoize.com/sysexlibrarian/

Never had a single problem with it.

Can you upload the file to see it?

Sadly Desmond, this is one of my bugbears. Snoize has worked flawlessly with almost everything I've pointed it at/at it, but this? Nope. It thinks this 27 byte file is 3 bytes. No idea why. It only shows as 3 bytes in the list, and 'view contents' only shows 3 bytes. It's definitely not 3 bytes, it's 27.

[desmond]

Like I said, can you upload the file? I can check here...

[Eddy Deegan]

Snoize has worked flawlessly with almost everything I've pointed it at/at it, but this? Nope. It thinks this 27 byte file is 3 bytes. No idea why. It only shows as 3 bytes in the list, and 'view contents' only shows 3 bytes. It's definitely not 3 bytes, it's 27.

This sounds as if Snoize is having difficulty parsing it. Are you certain that the file is complete in and of itself and not merely the 'payload' to be used with a device-specific SysEx header?

Does the data in the file start with 0xF0 and end with 0xF7, and is the second byte in the data the correct ID for the manufacturer of the hardware?

[desmond]

Or maybe there's a >7-bit value in there which is breaking the sysex string.

All of which is why I was asking to look at the file, as it seems weird to me, I've never found Snoize anything other than totally reliable for anything I've ever thrown at it...

[nathanscribe]

This sounds as if Snoize is having difficulty parsing it. Are you certain that the file is complete in and of itself and not merely the 'payload' to be used with a device-specific SysEx header?

Does the data in the file start with 0xF0 and end with 0xF7, and is the second byte in the data the correct ID for the manufacturer of the hardware?

It does. It's for a DIY piece of gear so I wonder if Snoize expects something from a set of manufacturers. But I do know other people have used this file with no trouble.

[nathanscribe]

Here you go, just copied from the user guide, but I believe the file to be accurate. It's just a string of key assignments for a drum module, with a data byte (that 00 near the end) for sustain behaviour:

F0 00 90 90 23 24 25 26 28 27 27 29 2B 2A 2C 2D 2F 2E 2E 30 32 31 31 33 33 00 F7

[Eddy Deegan]

Hmm. A manufacturer ID of 0 is reserved for ID extensions, which are 3 bytes long.

That might be the problem. As a sanity check, if you change that second byte to 0x01, does it solve the issue of Snoize only seeing it as 3 bytes?

[nathanscribe]

As a sanity check, if you change that second byte to 0x01, does it solve the issue of Snoize only seeing it as 3 bytes?

Nope, but it now thinks the device is made by Sequential.

[Eddy Deegan]

OK, well it was worth a go (and Sequential's ID is 0x01, so that makes sense).

I see a couple of 90s in there. They are > 7-bit values. Are they decimal values? (In which case they should be specified as 5A). Valid SysEx only contains data bytes up to a value of 7F (127).

[nathanscribe]

I see a couple of 90s in there. They are > 7-bit values. Are they decimal values? (In which case they should be specified as 5A).

Ah, that is a very good point. Hang on a tick while I faff them around.

[desmond]

The two 90's are the problem, bigger than 7-bit values, as I suggested above.

(Verified in Snoize, change them to something under 128 (decimal) and the string works as expected).

Basically, Snoize is telling you that was a completely invalid sysex string and was terminating it at the invalid bytes with an F7 (entirely correctly as per the MIDI spec I think you'll find).

Like I said - always reliable! :thumbup: ;)

[Eddy Deegan]

The two 90's are the problem, bigger than 7-bit values, as I suggested above.

+1 :thumbup:

[nathanscribe]

Thanks chaps, Sysex Librarian now sees the full thing and will send it as desired.

The device isn't responding correctly though so that's another battle, and it may well end with fire and a kazoo.

I really hate MIDI. :headbang: