[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!

Andras

On Tue, Jul 21, 2009 at 10:40 PM, Andy Farnell <padawan12@obiwannabe.co.uk> wrote:

Pd does not have a "control rate" as such. All message domain
computations happen at audio block boundaries and happen as
fast as possible. From the foregoing discussion it may be
that some kind of list drip or list sequence operation will
help make things smoother.

andy





On Tue, 21 Jul 2009 19:26:10 +0200
András Murányi <muranyia@gmail.com> wrote:

> 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?