[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 <padawa...@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 <muran...@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.a...@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 <muran...@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? >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list