david,miller: i don't think that the suggested solution [247, NN, NN, 240( will actually work (but i haven't tested, of course) because of the non-existing raw-midi: instead all of your bytes will be encapsulated into separate sysex packages, which is kind of dumb... (at least this is what kmidimon tells me when intercepting the outgoing midi-stream)
Do you mean that you can send messages eliminating F7 and F0 to let the API compensate for it?
I'm looking at the source code in svn, assuming you use [midiout] to send sysex. The midiout object has one method, for floats : midiout_float(), in x_midi.c, line 681. It just calls outmidi_byte() in s_midi.c, line 239. If Pd was compiled with USEAPI_ALSA defined, then outmidi_byte calls sys_alsa_putmidibyte() in s_midi_alsa.c line 234, otherwise it calls sys_putmidibyte() in s_midi_oss.c line 182. These functions just send a single byte. There is no interpretation done, no F0 or F7 are added. Each byte is sent separately through the port without being queued.
Possibly if the bytes of a sysex packet are too far apart in time other software may not receive it correctly? Or if you send the bytes as one message Pd interprets the second byte as an argument for midiout, since midiout has no method for list, the default method will be used. Or maybe you have the status bytes backwards: sysex begins with F0 (240) and ends with F7 (247). All the bytes in between must be less than 128. The example above should be [240, NN, NN, 247(
Martin