2009/7/8 Alex <x37v.alex@gmail.com>
I think that pd's midi out doesn't take whole sysex messages though,

you simply send a stream of bytes.  This is how it has been working
for me.  I created an abstraction which takes a list of bytes and
makes it into a sysex message (stream of bytes) [adds the sysex start
and start and then outputs bytes one by one] and it works quite well
for me.

If it's your list2sysex abstraction then I have already witnessed and tried it...! So far with not more success than using a comma-separated list.
 
Btw, the sysex loopback code [using the software through] that you
sent initially does work for me.. I get the whole message.

Hmm! Now I think I will have to try with some reliable midi-out hardware as the the Audigy is rumoured to eat up sysex and my MOTU is going crazy, not to mention that it does jack-midi only and the a2jmidid bridge is not so very good with other than simple and slow tunes.

Now that i'm trying with a Midisport everything is OK.
Another thing was that i was a bit lost in Yamaha's midi spec for the mu100 but i've found it out.  ;)

However now i see that pd's performace is becoming really waving as i'm tring to pump out more midi data.
My old-new questions would be:
- Provided that a knob is directly driving a sysex pattern which spits out way more data than necessary, who do i best slow down my data, staying realtime? I guess i shall drop some of it somehow, or i shall kinda resample the datastream. Could you Sirs recommend an economic way to do this?
- My machine is a moderate powerhouse (Opteron 148 @2200, 4G), my kernel is rt and audio in pd is off however performance is waving, and my simple sequencer is becoming unstable. What are the crucial points of keeping the patch 'fast', where do you think i generally lose the most cpu?

Thanks,

Andras