@acciddose; Not sure, looks like they do some neat things.

I used to love Ultima Underworld. You've earned some cool points for that screenshot.

I have to wonder why you are using your graphics kit to make a trainer for a game (assuming that's what it is) though

inventory/stats editor. i was bored one day and loaded up UW, decided this is a good way to test the gui lib. actually i also figured out how to fully decode for uw2 as well, so it works for both games. i haven't put any effort into flags though so no mucking up your position in the game yet. i thought it was a real shame when the few projects out there for uw rewrites died off - at least we still have arx.

another idea is for installers and so on. i like the simple nsis as things are now, but i'll probably get around to adding some custom graphics eventually. i'll be able to link into the dll (effects, xhip, whatever) inside the installer and display the same widgets as the plugin has for the installer controls.

oh man that's ridiculous

it'll be cool though.

Ok. I didn't know that.
So in essence the driver packs the needed 4 bytes that a CC for example needs, to just 3? Combining status and channel right? Sounds clever as theres only 16 channels. Makes sense

To sum stuff up: you could use a special nrpn address you'd use for binary data input(if only one address is used you can just keep sending the new data values without the address data..). That could be a nice crossover of sysex vs nrpn, that would take just 2x bandwidth of what a sysex takes, would work from a vst and on ip-midi, and wouldn't break the midi standard. That could work if your building your own hardware and can implement that on the device-end.. and if midi-interfaces won't drop any of the cc messages.

no the 2x data doesn't require anything special.

you could get 1-1 data like sysex if you broke the standard like i do. (with one midi device on one cable, it can't break anything.)

No. It's 3 bytes all the way. As the VST SDK doc says: