Sysex feeling like a punishment

[nathanscribe]

Well the data string as pasted earlier is from the user manual, and that's the only info available, except for fights between people on the internet who can get no joy from this process, with others who are determined it works perfectly.

I tried both 5A and 09 and neither worked. Config light on the device just carries on flashing as though it's not received anything. Tried a slower transmission, that doesn't affect anything. Tried two different sysex apps. Neither work.

I've also tried a sysex file downloaded from the 9090 facebook group, which is claimed to work perfectly, and yet it doesn't for me at all. The string in that is 90 90 and it's 27 bytes.

[muzines]

Well the data string as pasted earlier is from the user manual, and that's the only info available, except for fights between people on the internet who can get no joy from this process, with others who are determined it works perfectly.

Links to these discussions, and the info from the manual would be helpful.

As it is, we've only got your word from your side of the story, and you might be reading the manual wrong perhaps (given you're such a fan of MIDI! )

And the string you've provided here both doesn't work, and violates the MIDI spec, so it's not a good start!

Otherwise, without any other info, and no access to the device in question, there's not much else we're going to be able to do... :shrugs:

[The Elf]

http://www.9090project.co.uk/download/9090userguide161102.pdf

Here it is, guys. It does look very strange. I can only suggest that maybe the software handling the Sys-Ex is spitting out its dummy at the hex '90's in there?

[muzines]

Hmm, bit suspicious those bytes are 90 90 and the device is a 9090.

Maybe the developer got over excited with the find/replace in the documentation...?

I'd contact the developer, because what a random MIDI transmission software will do transmitting non-valid sysex bytes is up for grabs - they could have any of multiple behaviours.

Alternatively, you could write a loop to loop through all 128 7-bit values to see if one works (some software might wrap around the 8-bit value into a 7-bit value).

That's a *really* bad sysex implementation and the developer should not have done that (if that's what he did) as he shows no understanding of basic MIDI fundamentals... He just thought the $90 $90 looked cool. Bad.

[nathanscribe]

Ah cheers Elf. Yes, it's a bit thin on info in there, the discussions online are in a private facebook group but amount to the same.

Anyhow after all this, it may be an issue with the firmware in the early PICs that were issued. Seems like the solution is to replace the PIC with one with the correct behaviour programmed in already, as trouble updating the old ones has never been resolved.

Sigh. Thank you everyone, it's good to know there's a bunch of experts hiding behind the curtains

[muzines]

You could try writing a little bit of code in your language of choice to spit out the necessary bytes via MIDI, and see whether that route works?

(The introspective link on the front of that document seems to be a different url and links to a site in Japanese. This whole thing is a bunch of weirds...!)

[nathanscribe]

You could try writing a little bit of code in your language of choice to spit out the necessary bytes via MIDI, and see whether that route works?

Unfortunately that would be Sinclair BASIC or Z80 assembler.

[CS70]

Fascinating. I looked at the device manual and it's from 2002. All is possible with devices and software from that time

Just an idea - can u try to send 0x10 0x10 instead of 0x90 0x90 ? (ie 10 10 instead of 90 90)

[muzines]

Unfortunately that would be Sinclair BASIC or Z80 assembler.

You got a MIDI interface for those?

[CS70]

Ah. According to the spec, Manufacturer ID 0x00 is "Used for ID extensions".
https://www.midi.org/specifications-old ... id-numbers

(fun that the spec has "-old" in its URL)

If you look a bit down in the page you can see how this is used - exactly with a three 8 bit words sequence.

I strongly suspect the 00 90 90 sequence is there exactly to indicate that the message is for the 9090

If the software you sent from does not understand this it might be mangling the message (masking to 0-127, for example) so that the 9090 thinks it's not a message for itself.

[muzines]

Ah, interesting...

None of those ID extensions violate the 7-bit data byte rule though.

$90 is still against the MIDI spec, which is why the sysex strings get terminated. Looks like the developer chose $90 $90 because it looked cool, without realising that *all MIDI data bytes are 7-bit values*. $7F is as high as one individual data byte can go. No exception...

[CS70]

You could try writing a little bit of code in your language of choice to spit out the necessary bytes via MIDI, and see whether that route works?

Unfortunately that would be Sinclair BASIC or Z80 assembler.

You could search for some utility to send from the command line, for example https://github.com/gbevin/SendMIDI/releases

[CS70]

Ah, interesting...

None of those ID extensions violate the 7-bit data byte rule though.

$90 is still against the MIDI spec, which is why the sysex strings get terminated. Looks like the developer chose $90 $90 because it looked cool, without realising that *all MIDI data bytes are 7-bit values*. No exception...

Yeah, since the synth is the one supposed to do the interpretation, it's not inconceivable the the programmers at the time did not apply that to the extended identification code. I mean code-wise, it would be natural to put the check of the sequence separately from the generic 0-127 byte processing in the synth, and so that in the synth's code no masking with 0x7f is done for these two bytes.

That's why initially, to try out, I proposed to use 0x10 instead of 0x90 (which is 0x90 masked by 0x7f).

But after looking as the spec, if I were a betting man, I would put my money on the synth not fully understanding/respecting the spec. It's not bulletproof precise.

Back in the time, the code sending the data was probably not caring much about what was sending...

As u say, it looks cool.

The trick for the OP is to find a way to send serial data without any check.

[muzines]

I mean I've seen some weird sysex specs designed by presumably mad, drunk or delusional Japanese engineers (Casio CZ, let's all take a drink! ) but putting effectively MIDI status bytes into a sysex string as part of the message just shows a fundamental misunderstanding of extremely basic MIDI basic fundamental basic fundamentals, at a basic, fundamental, basic level. Fundamentally.

No wonder Nathan's been having a hard time with this (blame the developer!) and no wonder random people claim success or not, because the behaviour of gear handling MIDI messages outside the spec is entirely unpredictable. I mean, the system's MIDI handling, and your MIDI interface and drivers all understand the MIDI spec, and will likely reject messages that violate it, or handle them in unpredictable ways. Maybe a particular MIDI driver on Windows and a particular version of the MIDI interface firmware doesn't check and lets that $90 byte through, and the message works for Random A. Guy, and he says "it's all good". But then Random B. Guy comes along, using the exact same gear, and says "Er, no this doesn't work" because his slightly later firmware version fixed a MIDI parsing bug that (correctly) no longer lets non-spec MIDI messages through.

Minefield.

Terrible, terrible implementation, and Nathan is suffering because of it (and presumably many many others.)

All all because sir needs his crash cymbals to decay as expected. Maybe sell the drum module and pick up a TR-505 - that'll do it!

(If I were to guess, it's possible that Core MIDI on Macs won't let non-standard messages pass, and you're on a hiding to nothing. Windows, on the other hand, probably doesn't know or care much about MIDI, so it might let you send whatever bytes you wish...)

[nathanscribe]

You jest, but the 505 is a great machine!

(waits)

Yeah no so I have been in touch with the author of Snoize Sysex Librarian, and it turns out they'd already had queries from 9090 owners and gone as far as coding a hacked version which somehow (I didn't ask) was intended to sidestep the issue. Still didn't work for me though the 9090 did respond by brielfy not flashing its LED during the first few bytes. I tried a few speeds and a few variations on the file (with the 90h replaced etc) and no joy.

I've been in touch with Trevor as well and he's aware there are problems and is going to fish out a later PIC with the updated firmware on. I don't have my own PIC capabilities so that's some good news.

[muzines]

Ah, good that you have some options.

(None of which would have been necessary had the developer RTFMM...)

I shall not react to the other thing.

[The Elf]

I never wanted for another TR-x0x drum machine since getting a TR-8S.

But this is kicking a man when he's down...

I don't know what you could use to transfer that data. Is it the kind of thing that a terminal window might be able to handle, perhaps? - though how you would set it up is beyond my skills.

Maybe this is the kind of thing for which our good Mr Folderol may be able to suggest a solution?

Overtaken by several posts and edits...

[CS70]

Haha agree!

And is something else needs to send a sysex sequence at some point, it will likely fail to be recognized the same way.

Still all Nathan needs to do is to find an utility that does NOT understand more midi than necessary to send the bytes as they are.

[CS70]

it turns out they'd already had queries from 9090 owners and gone as far as coding a hacked version which somehow

There's different ways in which they could have "hacked" their code, for example, simply stopping to interpret anything with value greater than 127 (90 hex is 144 decimal) but still "cutting" it if it is.

What you need is a utility that sends the bytes as they are, no question asked and no processing done. 2002 style.

Not an expert on mac, but on Windows/Linux would be very simple - just use an hex editor to put the bytes in the files and then send them to the serial port to which the MIDI is attached.

But give a try to the tool I sent, it might be it does just that and there's a version for MacOS.

[nathanscribe]

But give a try to the tool I sent, it might be it does just that and there's a version for MacOS.

You mean using 10h instead of 90h? Doesn't work.

It seems to be a problem with the firmware in the 9090.

[CS70]

But give a try to the tool I sent, it might be it does just that and there's a version for MacOS.

You mean using 10h instead of 90h? Doesn't work.

It seems to be a problem with the firmware in the 9090.

No that was an idea but we figured out it wasn't it. The problem is that most modern tools attempt to "interpret" the 90 90 sequence - which is not in spec.

if u read further down I sent u a link to an open source tool that may (emphasis on may) do what you need - i.e. send the raw data as it is to the synth. Maybe.

The link allows you to download a MacOS version..