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

[Andy Farnell]

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


-- 
Use the source