Delphi ASIO & VST sourceforge project

[Norbert Stellberg]

Hello,

how can I send a Sysex message ?

with best regards

Norbert

[TRN76]

Hello,

how can I send a Sysex message ?

Sysex are regular midi witch starts with $F0 and ends with $F7.
For full specs, look at MIDI specification site: http://www.borg.com/~jglatt/tech/midispec.htm

Should get you started...

[Norbert Stellberg]

Sysex are regular midi witch starts with $F0 and ends with $F7.

Ok, I replay my question with other words:
How I can send Sysexes with the vst tools ?

with best regards

Norbert

[Norbert Stellberg]

Sysex are regular midi witch starts with $F0 and ends with $F7.

Ok, I replay my question again
can I send Sysexes with the vst tools ?

with best regards

Norbert

[TRN76]

Do you wanne send sysex from host to plugin? or from plugin to host? ...or you can always send to a hardware mididevice!
Anyways I'm curiuos too, as I could need sysex in VST enviroment too.

[Norbert Stellberg]

Do you wanne send sysex from host to plugin? or from plugin to host? ...or you can always send to a hardware mididevice!
Anyways I'm curiuos too, as I could need sysex in VST enviroment too.

I will made a plugin alike a midi player.
Input: MidiIn
Output: ToHost
A lot of midifiles has sysexes, and these I will send.

with best regards

Norbert

[Christian Budde]

Regarding MIDI messages:

To process Midi-Data from the Host you have to write the event handler 'OnProcessMidi' within your plugin. Like:

Code: Select all

procedure TMyVSTModule.VSTModuleProcessMidi(Sender: TObject; MidiEvent: TVstMidiEvent);
const CCDiv : Single = 1/127;
begin
 with MidiEvent do
  begin
   Status:=midiData[0] and $F0; // channel information is removed
   if (Status=$B0) then
    begin
     if fMidiLearnParam>=0 then
      begin
       if fMidiLearnParam<ParameterProperties.Count-1 then
        begin
         ParameterProperties[fMidiLearnParam].CC:=midiData[1];
         fMidiLearnParam:=-1;
        end;
      end;
     for i:=0 to ParameterProperties.Count-1 do
      if midiData[1]=Byte(ParameterProperties[i].CC)
       then Parameter[i]:=VSTParameter2Parameter(midiData[2]*CCDiv,i);
    end;
  end;
end;

The above code implements the mapping of CC data to then parameter stored in fMidiLearnParam.

You can also use MidiEvent here to process sysex data. Here's the definition of TMidiEvent:

Code: Select all

  TVstMidiEvent = record
    EventType       : TVSTEventType;
    ByteSize        : LongInt; 
    DeltaFrames     : LongInt; 
    Flags           : TVstMidiEventFlags;  
    NoteLength      : LongInt;             
    NoteOffset      : LongInt;             
    MidiData        : array[0..3] of Byte; 
    Detune          : Byte;                
    NoteOffVelocity : Byte;
    Reserved1       : Byte;                
    Reserved2       : Byte;                
  end;

The most important here is the MidiData array. You can do all the basic MIDI stuff (from the MIDI specification here, including sysex stuff).

In case you want to send MIDI data to the host, you can use

Code: Select all

procedure MIDI_Out(b1, b2, b3, b4: byte; offset: Integer = 0);
procedure MIDI_CC(ch, num, val: Integer; offset: Integer = 0);
procedure MIDI_ChannelAftertouch(ch, val: Integer; offset: Integer = 0);
procedure MIDI_NoteOff(ch, note, val: Integer; offset: Integer = 0);
procedure MIDI_NoteOn(ch, note, val: Integer; offset: Integer = 0);
procedure MIDI_PitchBend(ch, val: Integer; offset: Integer = 0);
procedure MIDI_PitchBend2(ch, x1, x2: Integer; offset: Integer = 0);
procedure MIDI_PolyAftertouch(ch, note, val: Integer; offset: Integer = 0);
procedure MIDI_ProgramChange(ch, val: Integer; offset: Integer = 0);

where the most generic is MIDI_Out(b1, b2, b3, b4: byte; offset: Integer = 0);

Here you can find the same 4 bytes again. So passing MIDI information thru your plugin would be:

Code: Select all

procedure TMyVSTModule.VSTModuleProcessMidi(Sender: TObject; MidiEvent: TVstMidiEvent);
begin
 with MidiEvent 
  do MIDI_Out(midiData[0], midiData[1], midiData[2], midiData[3]);
end;

I hope this helps,

Christian

[JCJR]

Thanks Christian

Since most of the shortest sysex messages tend to be in the ballpark of 8 or 10 bytes, do you know the VSTi convention for stuffing sysex into the 4 byte packets in a TVSTMidiEvent?

I've seen different sequencers handle the internal storage different ways. Since the PC divorces short midi messages and sysex in separate function calls, sometimes have seen PC sequencers make an internal sysex event type where the four MIDI bytes in a track's MIDI event record are used to hold a pointer to sysex data. So in that scheme, each timestamped sysex event takes one slot in the track event record, and each such sysex event points to a separate pointer holding the sysex data.

What I used to do was store sysex messages in as many consecutive internal message slots as was necessary, up to four bytes per event. So the status first byte of the first event would be F0, and then 3 bytes of sysex data in thje rest of the first event.

Then my parser could identify any number of subsequent events as sysex continuation data, because such events would always have a status byte < $80. And the final terminating sysex end-marker would be a single-byte midi event record with F7.

This was easy to display/edit in an event list editor, and really huge packets could be timestamped to transmit at the same rate they were received, so tranmitting the data wouldn't 'choke' the receiving synth (which was a problem with many hardware synths with big patch dumps). The trickiest part was to make sure the string of packets did not get broken apart by other short midi messages if you did a track merge or a quantize or overdub or cut/copy/paste. But it wasn't terribly difficult.

I have seen other sequencers which store only one sysex byte per event, which may be simple to parse. But such a scheme is wasteful. If each track MIDI event ferinstance takes 12 bytes, then a 10,000 byte sysex dump would occupy 120,000 bytes of track storage.

Anyway, that is just offtopic rambling.

Do ya'll know how Steinberg stuffs sysex into a series of packets?

A related question would be: Does anyone know what percent of VSTi synths are programmed to recognize sysex?

[darlock]

To JCJR.
Yea. Your question is right.
I'm also coding a vst pugin for control hardware synth (many sysex bulk dumps to send or receive).
I'm was modify some code in DAEffectX.pas for handle sysex events.
But work only sysex receiving. Dumps of hundreds and more bytes handled and recognized by my vst plugin without any problems.
But i'm had a strange bugs with sysex transmiting. Only one packet only send and vst plugin hangup. I'm trying for some combinations of buffer and memory allocating... no success.

If you need more detail code i'm can expalain it.

[Norbert Stellberg]

I'm was modify some code in DAEffectX.pas for handle sysex events.
But work only sysex receiving. Dumps of hundreds and more bytes handled and recognized by my vst plugin without any problems.

Perhaps you can spend Christian this changes ? I think, a good sysex handling is
a very good enhancement for this very good tools.

with best regards

Norbert

[asseca]

A related question would be: Does anyone know what percent of VSTi synths are programmed to recognize sysex?

Another related question:
- how many hosts actually support SYSEX handling, I have found Cubase, VstHost and maybe Usine.
- energyXT, Reaper, Traktion, Chainer, Bidule does not seem to handle SYSEX at all

This gives me the idea that it *might* be better to send SYSEX directly to the MIDI device. Of course that MIDI device's driver must then be able to handle multi MIDI streams.

[Norbert Stellberg]

A related question would be: Does anyone know what percent of VSTi synths are programmed to recognize sysex?

Hello,
I think, all vst plugins which send midi events, must can send sysexes.
Sysex is a part of midi definition table.
Why I shall send sysex directly to the midi port ? I think, it is not
the fine programming of a vst plugin, isn't it ?

with best regards

Norbert

[Christian Budde]

In my eyes, SYSEX is very lame. The use of nibbles is not up-to-date to modern specifications. Keep in mind, that MIDI was specified in the 80s. The connection is slow and using nibbles you waste even more bandwidth. It was good, but today it's just a relict, especially SYSEX messages, since they are only valid exclusively for a system (hence the name). I prefer open systems. Maybe that's why I decided not to have seperate routines for sysex, since it is already possible via the generic MIDI_OUT.

Keep in mind that it might be also the windows MIDI layer which might filter out your sysex messages. There are some ridiculous rules there. If the end of the sysex command is beyond the length of the windows buffer, the message is discarded...

If you have a choice, try to do it without system exclusive stuff.

Christian

[JCJR]

Agreed, sysex is kinda the odd man out because it must be handled differently than other MIDI messages.

I was just curious if sysex does get transmitted to VST's, and if so, how the bytes are packed into the VstMidiEvent records. Currently I don't send sysex to VSTi's, but if it is possible and if it is EVER done in practice, I ought to do it for completeness of support.

For instance, the GM Reset message is very common, F0 7E 7F 09 01 F7 . If sysex is possible in VSTi's, I wouldn't be surprised if some synths respect such a message. Especially such obvious candidates as Roland or Yamaha softsynths.

And such messages are commonly inserted into published MIDI files, to do specific actions. So for completeness they ought to be sent if there is a recommended way to send them. A lot of MIDI files don't always work as expected without such embedded sysex, because the sysex messages are used to put the synth in known states at the beginning and end of songs. If a program is doing jukebox play of a bunch of MIDI files from disparate sources, playback can do unexpected things between-songs unless the synth gets initialized into known states, and in the past sysex was a tool used for that purpose.

Another issue that can be important are the short voice-editing sysex messages. There are pretty short voice parameter messages in the Roland GS and Yamaha XG specs, and thousands of commercial MIDI tunes were carefully authored to contain those messages to tailor the synth tone to the song arrangement.

So, sure, the MIDI still has the same notes regardless of those little embedded sysex messages, but such a song is probably gonna sound 'better' out-of-the-box with no user tweaking (jukebox play), if played on a compatible synth, and sending the sysex messages.

Except for really bizarre situations, I doubt if someone would want to design a brand-new VSTi synth which uses sysex for Patch storage or whatever. There are much better ways to skin the cat.

OTOH, if one were designing a 'perfect clone' of a Yamaha DX7 synth, it would probably make sense to make it recognize the sysex, because there are thousands of nice patches which were created for DX7. The labor of so many sound designers would be worthy of preserving.

[asseca]

A related question would be: Does anyone know what percent of VSTi synths are programmed to recognize sysex?

I think, all vst plugins which send midi events, must can send sysexes.
Sysex is a part of midi definition table.
Why I shall send sysex directly to the midi port ? I think, it is not the fine programming of a vst plugin, isn't it ?

As I have mentioned, there is hardly any host that can receive or send SYSEX messages, I have written a MIDI Monitor plugin which proves this ... mGUI actually can receive and send short SYSEX messages, but it is exactly this lack of SYSEX support with hosts which renders this ability useless ...
Hence the idea to implement external MIDI receive & send ...