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?
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?
Hello !
What is the easiest way to connect a wiimote to pb on ubuntu ?
Thanks in advance. Damien.
[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.ukwrote:
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?
-
András Murányi -
Andy Farnell -
Damien Henry