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?