SysEx using VST v2.4

[aciddose]

well the only really safe way to do that is to have your own interface. this is how for example versions of synthesizers such as virus ti accomplish it.

otherwise you're depending upon drivers anyway. either the system's midi drivers support multiple clients or they don't. you have no control over that. what you can do is add a midi wrapper which is provided by some tools such as midi ox.

the advantage is that of course you get the mixing/multi-client support ensured regardless of what midi hardware the user has. you also don't need to provide special hardware. the disadvantage is that the user is forced to manually configure their midi devices using your wrapper instead of the native interfaces.

of course you also have the option of leaving this to the user who is unlucky enough to have drivers that don't support multiple clients. you can also leave out support for hosts that are not sysex compatible.

since you want things to actually work i guess you're forced to implement the wrapper somehow and provide both direct access to the midi i/o and host i/o in your plugin.

i think this is why we don't see many successful attempts at these types of controllers. i've seen a lot of attempts but they've never become very popular.

it's a shame really that it has to be so difficult. i'm not sure why more hosts don't support sysex.

[arakula]

i'm not sure why more hosts don't support sysex.

Presumably because their developers don't have the background that would make it a necessity. If you don't have external hardware devices that implement SysEx as the major means to control non-standard features, why bother? Just because some freaks want to do things outside the wonderful, feature-packed, overcomplete DAW control program of theirs? I mean, all an artist needs to have today is a laptop, right?

Just to make sure there's no misunderstanding - the above is deeply sarcastic; I'm owner of some 30 or 40 hardware synths myself, so I think it's a shame, too - and of course my hosts support it, both receiving and sending SysEx from VST(i).

[Caco]

Hey Rick, if you want to keep things simple then just build it all with Sensomusic Usine. Usine has a Sysex Editor and can even export your patch as an independent VST if you want

Caco long time friend

Can Usine created stuff be fully skinned up with custom controls? If so I'll definitely check that out. Part of the fun is the programming part is the design work

Yes the controls in Usine can be skinned with your beautiful art work
http://www.sensomusic.com/wiki/doku.php ... ors_bitmap

http://www.sensomusic.com/wiki/doku.php ... sex_editor

[grymmjack]

Hey Rick, if you want to keep things simple then just build it all with Sensomusic Usine. Usine has a Sysex Editor and can even export your patch as an independent VST if you want

Caco long time friend

Can Usine created stuff be fully skinned up with custom controls? If so I'll definitely check that out. Part of the fun is the programming part is the design work

Yes the controls in Usine can be skinned with your beautiful art work
http://www.sensomusic.com/wiki/doku.php ... ors_bitmap

http://www.sensomusic.com/wiki/doku.php ... sex_editor

Awesome. Thanks very much for this tip.

[grymmjack]

Usine looks incredible. I love the mnml

@Caco; i've downloaded the pro demo but I can't export a VST/VSTi, do you own it and can export a sample one? I just want to see what kind of shell is around it. If it can be fully "private label branded" or if it's got some kind of Usine shell that's unchangeable, etc.

Thanks man. Regardless of this, you've opened a deep pit with the Usine recommendation. I had no idea it was this robust. Thought it was just a weird avant garde kind of toy, didn't realize it was like reaktor/max and could compile to VST/i.

[Caco]

Usine looks incredible. I love the mnml

@Caco; i've downloaded the pro demo but I can't export a VST/VSTi, do you own it and can export a sample one? I just want to see what kind of shell is around it. If it can be fully "private label branded" or if it's got some kind of Usine shell that's unchangeable, etc.

Thanks man. Regardless of this, you've opened a deep pit with the Usine recommendation. I had no idea it was this robust. Thought it was just a weird avant garde kind of toy, didn't realize it was like reaktor/max and could compile to VST/i.

sent you a pm

[grymmjack]

OK so I'm trying to compile the Tutorial project with VSTGUI v4.0.1 and VST SDK 2.4.

I've got AGain compiling, and also VSTXSynth.

I've got my bearings on how things are setup sorta, and now I'm trying to take that next step and getting something to work with a real GUI interface.

I've got the tutorial compiled, but opening it in Cantabile, it shows absolutely no window or anything, just the toolbar.

From what I can see in the resources folder, there should be a knob or something. I'm seeing no window at all.

Any help is appreciated.

I'm using Visual C++ 2008 Express

[mkdr]

if you have any option, it's a much better idea to go with NRPNs in almost every case.

even sending whole presets can be managed quite efficiently by setting up the NRPN (98, 99) and then sending out data to data entry (6). since midi has the ability to drop all data except the new 7+1 bits you send it means you get almost full bandwidth AND you have both parameter and channel selection.

it's also guaranteed to work with any device that will transmit CCs correctly, which includes pretty much everything.

sysex is, for the purposes of transmitting control information or blocks of data, pretty much obsolete.

Doesn't sending one NRPN parameter take up 16 bytes compared to just 1 on sysex(inside a program dump)? Midi interfaces also drop CC's if there's too much of them coming through(run out of buffer).. you'll need a timed stream for sending all that data.


In any case, i've seen better results with sysex than with CC based patch changes.. and i've build dozens of patch loaders for synths. But it is a slippery slope as most hosts don't support sysex. The best approach in my opinion is having your own midi-port, independent of the host.

[aciddose]

no, it only takes one byte. it depends upon the support your hardware has, but it's possible to output a stream of continuous bytes in a non-standard format which will be compatible with other midi devices. (they'll just ignore it.)

so what i do is output the destination code i want, then output a string of values for the entire block of data i want to send. the code on my device looks up the address and starts writing.

this method obviously isn't safe for every possible case, but it works fine. (actually i have no idea if this works with every driver and host... there is no reason it should but i'm sure it's possible assumptions were made about message length being = 4 byte in lots of places.)

sysex would be better if hosts supported it, because it works identically when you look at the uart stream.

[mkdr]

no, it only takes one byte. it depends upon the support your hardware has, but it's possible to output a stream of continuous bytes in a non-standard format which will be compatible with other midi devices. (they'll just ignore it.)

so what i do is output the destination code i want, then output a string of values for the entire block of data i want to send. the code on my device looks up the address and starts writing.

this method obviously isn't safe for every possible case, but it works fine. (actually i have no idea if this works with every driver and host... there is no reason it should but i'm sure it's possible assumptions were made about message length being = 4 byte in lots of places.)

sysex would be better if hosts supported it, because it works identically when you look at the uart stream.

I didn't quite follow.

If a midi message like you say is 4 bytes (status, channel and 2 data bytes), how would you get an NRPN that takes 4 of those messages to be sent with just one byte?

Or do you mean to send each "value" as one of the midi message bytes? In that case you are basicly doing sysex, but out of spec. And in that case the driver, the interface or the recipient could just drop a few if there's too much traffic. So, worst of both worlds. I don't see the point.

[arakula]

A MIDI message in VST 2 is defined as an event that has a 4 byte data area for the MIDI message. Presumably defined this way since it can be casted to a 32-bit integer (at least in Windows, this is the format used for normal MIDI messages). That, however, has nothing to do with the MIDI messages that are sent to and from the device drivers; here, normal MIDI messages take up 1 to 3 bytes, depending on their type and Running Status.

To set up an NRPN, you need to send 2 messages:
1) a 3-byte controller message for the higher 7 bits of the number
2) another 3-byte one for the lower 7 bits of the number; assuming there's no other MIDI message in between, this is shortened to 2 bytes because it's got the same status byte.

Then, you need to send data bytes. Here, I don't follow aciddose's logic that they would take up only one byte. A message sent using Data Entry is a 3-byte controller message. The status byte may be optimized away by Running Status, but the second byte, which defines the Data Entry controller, and the third byte, the real data, must be sent, so it's always 2 bytes for one data byte. Or 3, if a non-realtime MIDI message with another status byte was sent in between.

So, sending an NRPN message needs a minimum of 7 bytes for 1 data byte, and 2 more for each following data byte. That's considerably more than a SysEx, which normally has a fixed size of 3 or 5 (F0, 1 or 3 bytes manufacturer ID, F7), plus how many bytes it needs to specify the command (implementation detail), plus the data bytes themselves, each taking up 1 byte.

Aciddose's "1 byte" can only be achieved with a MIDI device which uses specific code that violates the MIDI standard, together with a matching custom device driver on the computer side that violates it in the same way. In this scenario, it's possible.

[aciddose]

i was going to post that yes, that's obvious.

i was talking about sending packets longer than three bytes, but the hardware would need to support that. it really just isn't practical.

so it's a 1/2 ratio on long packets assuming you use n/rpn and with sysex you also have the nasty overhead of the id components.

it would be easier to deal with if midi allowed for packing any number of bytes using the msb as the flag to end the stream.

well, it does, but if you had the ability to ignore the standard you could be using sysex anyway.

the bright side of n/rpn though is that once you set up the destination it's possible to leave it set (don't write 127/127) and keep sending data-entry. so if you're manipulating one parameter it does actually become only 1/2.

it would be possible to send single bytes like i suggested if after a data-entry command, the device didn't clear the status byte or first data byte. (call this uber running-status or lsd mode)

where would this break the standard? if the next message were another CC the byte would be expected to write into data1, not data2 followed by handling the message. it would work fine as long as data-entry were always followed by another byte with the msb set - that is if running status were not used immediately following data-entry.

that's essentially how sysex works - once the codes are set data is read continuously until the end of stream flag.

so actually it would make sense to implement as part of the standard, it's just a little too late now i guess. ...and you already have sysex.

[grymmjack]

aciddose: I'm stuck with whatever the hardware mfg's are using man.

Have you guys done much with VSTGUI 4? It seems like it's very robust, cross platform, etc. (i'm talking about the googlecode vstgui project).

Thanks for keeping this thread alive.

[arakula]

where would this break the standard?

Running Status only keeps the Status byte, not the first data byte. Never. This would violate the standard.

If you look at the special case where you would want to transfer a data byte containing 0x06 or 0x26, you'll see why your idea is not going to work. These are the IDs of the Data Entry Coarse and Fine controllers. How should the device find out whether these are data bytes, or a new controller ID with the same status byte?

[aciddose]

did i add that all in an edit? lsd-mode indeed.

i meant to post it all together. it was a question to myself actually and i did go through how it would break the standard if other devices didn't implement it the same way.

we have a lot of extra cc values left undefined. it's possible special "uber running-status" modes might be defined this way in the future.

i would like it if we had this ability to send larger packets (extra data bytes) and replace polyphonic aftertouch with such a system for sending variable-length control messages rather than laying it on top of the existing control code system.

you'd have to call that midi version X though.. incompatible with previous versions.

no i've got my own gui code so i haven't used vstgui since i tried it back in 2003-2004. i wrote photo-shop capabilities into the current one. has vstgui4 stepped up on that? do they support alpha blending so on and software / accelerated pixel buffers yet?

the one thing i've been wanting to implement is acceleration of my pixel buffer operations using gl shaders.