[drip] is not 'realtime', but i think i have found what i need: [speedlim] from the cyclone library. It just samples the stream at given intervals. I hope it is cpu-economic as well!<br><br>Andras<br><br><div class="gmail_quote">
On Tue, Jul 21, 2009 at 10:40 PM, Andy Farnell <span dir="ltr"><<a href="mailto:padawan12@obiwannabe.co.uk">padawan12@obiwannabe.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Pd does not have a "control rate" as such. All message domain<br>
computations happen at audio block boundaries and happen as<br>
fast as possible. From the foregoing discussion it may be<br>
that some kind of list drip or list sequence operation will<br>
help make things smoother.<br>
<br>
andy<br>
<div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
On Tue, 21 Jul 2009 19:26:10 +0200<br>
András Murányi <<a href="mailto:muranyia@gmail.com">muranyia@gmail.com</a>> wrote:<br>
<br>
> Well i was hoping i wouldn't have to use any kind of timers for that job...<br>
> [int] followed by [change] do a good and (in terms of cpu) inexpensive job,<br>
> but to "resample" my control flow i will need [metro] or [pulse] afaik... if<br>
> i do that, of course i will not add a [metro] to each knob and envelope but<br>
> i will set up a central "control clock" with a single [metro] and then i<br>
> will feed this to every part that needs to "resample" control signals.<br>
> This leads me to the question (i remember it coming up earlier but i cannot<br>
> find the topic sorry), if i want to basically modify pd's own control rate,<br>
> is there a more direct/general way to do it?<br>
><br>
> Thanks,<br>
><br>
> Andras<br>
><br>
> 2009/7/19 Alex <<a href="mailto:x37v.alex@gmail.com">x37v.alex@gmail.com</a>><br>
><br>
> > You could try making it so that you don't send sysex messages on every<br>
> > change.. just poll for changes at a certain rate.. and only sent the<br>
> > most recent change at that rate?<br>
> ><br>
> > -Alex<br>
> ><br>
> > 2009/7/17 András Murányi <<a href="mailto:muranyia@gmail.com">muranyia@gmail.com</a>>:<br>
> > [...]<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<br>
> > mu100<br>
> > > but i've found it out. ;)<br>
> > ><br>
> > > However now i see that pd's performace is becoming really waving as i'm<br>
> > > 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<br>
> > out<br>
> > > way more data than necessary, who do i best slow down my data, staying<br>
> > > realtime? I guess i shall drop some of it somehow, or i shall kinda<br>
> > resample<br>
> > > 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<br>
> > is<br>
> > > rt and audio in pd is off however performance is waving, and my simple<br>
> > > sequencer is becoming unstable. What are the crucial points of keeping<br>
> > the<br>
> > > patch 'fast', where do you think i generally lose the most cpu?<br>
</div></div></blockquote></div><br>