posted 13 May 2010 11:12            

1 - Using a sound editor together with a Midi monitor, identified specific exclusive midi messages related to a particular parameter I targetted to control from kyma instead of a MIDI sound editor.

2 - Identified Bytes stream where then copied to the MIDIOutputEventInBytes Bytes parameter field. Ie : F0 xx xx xx ... xx F7. No matter what the sysex message consists in, it doesn't need to be described here. Any MIDI exclusive message is expressed in between F0 and F7 bytes.
Ie : 16rF0 16r40 16r00 ... etc... 16rF7

3 - Controled the stream output from kyma using also an identical MIDI monitor . I got confused about it: When Trigger activated, the entire bytes stream goes out except the last F7 byte that 'closes' the sysex message stream. One has to trigger again to see the F7 byte output , followed then by the following stream 's bytes supposed to go when trigger activated once more etc.

What I get :

1st trigger : [F0 xx xx xx ...
2nd trigger : F7][F0 xx xx xx ...
|---------------------------------------------> time
0 | |
t1 t2

What I should get :

1st trigger : [F0 xx xx xx ... F7]
2nd trigger : [F0 xx xx xx ...F7]

|---------------------------------------------> time
0 | |
t1 t2

(this text picture doesn't render spaces & tabs as eddited in the message, sure you got the idea of that picture)

4- Checked every possible reason, made sure about any midi filter on the path (released anything that could stop exclusive messages on their way)

5- Tried outputing ordinary MIDI messages such as a MIDI note On, which does work fine (a 3 bytes stream). Back to sysex message attempts, last F7 byte doesn't come out at once with the other bytes that preceedes it, F7 byte goes out only on the next trigger as illustrated above.

I presume this actually is the reason why I don't see the MIDI device reacting as It should, even if one particular byte (F7) goes out with some delay after the ones that preceedes.

Any idea & help welcome.

posted 13 May 2010 13:08            

So the problem ends up by a question which is the following :
May this be considered as a bug involving the MIDIOutputEventBytes prototype or is there any other way to do this ?

My goal actually consists in having the capability to send sysex bytes streams to an external MIDI device considering that the external controled parameter value is given from a Kyma fader in the vcs. To be further accurate, my project will consist in controlling up to 128 oscillators for additive synthesis and formant filters of an external synthesizer. Hence up to 256 of these prototypes should be included like these in the final sound. That particular prototype should not be too much processor demanding, hopefully I can gather that much within a sound without running out of available processor resource.

posted 14 May 2010 02:13            

I then supposed this 0xFF byte could have some 'temporising' effect on the overall stream message , so I tried adding again the sysex closing byte after 0xFF. And it actually worked !

The end result is that I can see ,on the midi monitor, a well 'shaped' midi exclusive message that respects the protocol, whilst the actual strem provided in the prototype parameter field is not :

What we see (parameter filed) is now :
16rF0 xx xx xx ... xx 16rF7 16rFF 16rF7
What we consequently get (monitored midi output)is :
16rF0 xx xx xx ... xx 16rF7

One of the Byte I entered within curly braces is evaluated as it should be. As a prove of this, my external midi device reacts properly as expected, so the actual output sysex stream is well shaped and understood, again at the condition of the extra 16rFF 16rF7 bytes added in the prototype 'Bytes' parameter field.

Maybe some can try this and confirm. In case this has been confirmed, this then also confirms a bug inherent to the MidiOutputEventInBytes prototype ?....