H3000 system exclusive format

That’s kind of what I thought.  I did have the slightly crazy idea of dumping each algorithm and doing some detective work to parse out each field.

The downside of course is that even with that info there’s no real way to provide a remote editor with any kind of real time (or even semi-real time) control because you’d have to continually resend the entire patch back with each change.

Not that that is hard (once it’s figured out), it’s just that the experience from a user perspective is more halting and likely the H3000 could get overwhelmed pretty easily.

At least with something like the tc 2290,you can send the sysex equivalent of front panel button pushes to simulate a user doing stuff, so that’s somewhat better.

Wow, thanks so much for that.   I’ll be poring over that in the morning.

Tom

Had a brief look this morning with my coffee.

First of all – that was a ton of work you did.

Second, I’m going to need more coffee.

Third – When I start dumping some of the sysex for the various programs, some of this will start to make more sense.  I will try not to ping you about any of the specifics in that spreadsheet even though it’s only been 10+ years.  🙂

I’ve spent a chunk of time deciphering the PCM 80 bit-packed format as well as dumps from the Oberheim Cyclone, LXP-5, and some Waldorf products and write code as part of my day job, so all of this raw info is going to be a huge boost to start things off.

Yes – I tend to use my H8000FW a lot more than the 3000, but part of that is the eveNET remote for it.  I’m hoping that I can put together a somewhat decent editor for the 3000 running on the Electra One MIDI controller hardware platform.  We’ll see how that goes.

Again – much thanks for what you provided.  The work involved is understood and appreciated.

Thanks for that.   I dumped a few presets and started looking through them.

Standard procedure is that there’s a standard header identifying what the dump is,  the data,  then usually a checksum. I did note that different algorithms had different size dumps.

John – I started trying to use the Parm sheet to see if I could get the H3000 to respond to an NRPN parameter change, but no luck so far.

The implication from the spreadsheet is (for example) sending the NRPN of 4 changes the Right feedback value for algorithm 100.

I tried various combinations of the NRPN byte messages with no success.

If you could send one parameter string that is sent from the Max code that would go a long way to being able to initially talk to the 3000.

The sysex parsing I’m saving for a bit later because that’s a lot of dump patch/decipher sysex, match things up, rinse and repeat.

If you’d rather carry on follow-on discussion via email, I’m available at — tmoravan    AT   yahoo DOT com

(no idea if forum software strips out/blocks actual email addresses).

FWIW, no matter if our discussions are here on via email, my resulting efforts will be publicly available for people to use as desired.

Yes – absolutely making progress on my selected platform.

I am working on a remote editor for the Electra One MIDI controller.

I currently have a beta version working that handles pulling back patches and displaying/editing values for algorithms 100 – 111.

I can fully read the sysex dumps for all algorithms.  The time consuming aspect is designing the controls and menus to handle all the various parameter ranges and types used by the H3000.

I also know of at least 1 other person/group working on an Electra One editor and 2 other people/groups working on Max implementations.

If anyone needs info on how to request a sysex patch dump from the H3000 and then parse it into the various parameters, just ask and I’ll help where I can.

The Electra One platform uses Lua as the programming interface (similar to Python in that it’s an untyped language), so the code reads like Python or C.  If you know a language like that, reading and translating what I’ve done should be straightforward.

I believe I know the answer to this, but I have to ask in case any 3rd party individuals have explored this area.  Does anyone have the ability to make changes to the H3000 OS to possibly address a couple of MIDI bugs?  I ran into a few things as I have been creating a remote editor for the H3000.

The first issue is that the right channel delay parameter in algorithms 102 and 103 (so far) can range from 0 to 1000 ms, but via MIDI, they only go from 0 to 500 ms (matching the left channel delay parameter). Any values sent higher than that are ignored.

The other issue is a bit more esoteric – from the H3000 front panel, some parameters increment by large values using the encoder knob and by smaller amounts using the up/down arrows.  Via MIDI, it’s a bit different.  If the encoder changes by 0.04 (for example) and the up/down changes it by 0.01, a single value change via MIDI will typically change it by either 0.02 or 0.04.  However, the H3000 will send the same MIDI sysex string with the value 3 more times using the arrow keys while the display changes by 0.01 each time.  The theory is you can hook 2 H3000’s together and they’ll match each other.  However, when I try to send the same value multiple times (to match the arrow key behavior) the H3000 ignores the extra messages so I can’t get finer increment/decrement values.

Interesting.  Mine is an H3000 SE with the popular ‘kitchen sink’ upgrade giving it everything but the broadcast algorithm (113) and the sampling board (algs 120,121).

So maybe it’s a glitch in that particular upgrade.  It would be slightly interesting to hear from others that still have 3000’s in various stages (the D/SX, etc)

Yes – as part of my sanity check for my editor, I’m bringing up every algorithm and going through each parameter full range to verify I have it coded correctly.  There’s so many variations because the algorithms were not all created by the same team at the same time.  Those two delays go to 1000 ms from the front panel (encoder or arrows).

You’ve probably noticed that at some point in the list of algorithms things like panning changed from -11 — 0 — +11 (internally using negative MIDI values) to 0 — 22 (using all positive and zero MIDI values and then internally adjusting it).

Same named parameter is sometimes a percent, sometimes just a raw value, etc, so even though I have code in for the parameters, they still need verification based on what my unit shows and can do.  The word Tedium, bravely (and accurately) used by the original devs (algorithm 108) applies across the board to this.   lol

Actual question for anyone still following this thread and using an H3000 — do you find yourself adjusting the individual input and output levels for each patch you create or do you pretty much just use the master levels and leave it at that?