Well i was hoping i wouldn't have to use any kind of timers for that job... [int] followed by [change] do a good and (in terms of cpu) inexpensive job, but to "resample" my control flow i will need [metro] or [pulse] afaik... if i do that, of course i will not add a [metro] to each knob and envelope but i will set up a central "control clock" with a single [metro] and then i will feed this to every part that needs to "resample" control signals.
This leads me to the question (i remember it coming up earlier but i cannot find the topic sorry), if i want to basically modify pd's own control rate, is there a more direct/general way to do it?

Thanks,

Andras

2009/7/19 Alex <x37v.alex@gmail.com>
You could try making it so that you don't send sysex messages on every
change.. just poll for changes at a certain rate.. and only sent the
most recent change at that rate?

-Alex

2009/7/17 András Murányi <muranyia@gmail.com>:
[...]
> 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?
>