<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div class="im">2009/7/8 Alex <span dir="ltr"><<a href="mailto:x37v.alex@gmail.com" target="_blank">x37v.alex@gmail.com</a>></span><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think that pd's midi out doesn't take whole sysex messages though,<div class="im"><br>
you simply send a stream of bytes. This is how it has been working<br>
for me. I created an abstraction which takes a list of bytes and<br>
makes it into a sysex message (stream of bytes) [adds the sysex start<br>
and start and then outputs bytes one by one] and it works quite well<br>
for me.<br>
</div></blockquote><div><br>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.<br> </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Btw, the sysex loopback code [using the software through] that you<br>
sent initially does work for me.. I get the whole message.<br>
</blockquote></div></div><br clear="all">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.<font color="#888888"><br>
</font></blockquote></div><br>Now that i'm trying with a Midisport everything is OK.<br>Another thing was that i was a bit lost in Yamaha's midi spec for the mu100 but i've found it out. ;)<br><br>However now i see that pd's performace is becoming really waving as i'm tring to pump out more midi data.<br>
My old-new questions would be:<br>- 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?<br>
- 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?<br>
<br>Thanks,<br><br>Andras<br><br>