>
> 2009/7/8 Alex <x37v.alex(a)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