[PD] Control rate (Was: Sysex out problems)

András Murányi muranyia at gmail.com
Wed Jul 29 02:34:33 CEST 2009


[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 at 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 at 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 at 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 at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090729/cfe81f71/attachment.htm>


More information about the Pd-list mailing list