Re: [PD] switch~ & cputime climbing

2007-06-13 Thread Frank Barknecht
Hallo,
Claude Heiland-Allen hat gesagt: // Claude Heiland-Allen wrote:

> A solution:
> 
> Use a better data structure than a linked list; a balanced tree would 
> reduce time complexity to O(log n) instead of O(n) (if I remember 
> correctly), admittedly at the cost of harder implementation.
> 
> Workaround:
> 
> Don't send messages to a switch~'d off vline~.

I think, people should be careful with sending messages to
switched-off dsp-objects anyway and consider switching off message
calculation inside their subpatches using [spigot] as well. 

I suspect, other objects besides [vline~] may show similar behaviour.
At least I've encountered the cpu-climbing in switched-off subpatches
in some of my patches as well, that definitely weren't using [vline~].
I didn't yet find out which objects or combination of objects were
causing this, but blocking message calculation managed to fix it.

Ciao
-- 
 Frank Barknecht _ __footils.org_ __goto10.org__

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-12 Thread Kyle Klipowicz
So just use this for now:

[X]  [inlet messages]
|   |
[t f f]_ |
|   ||
[switch]   [spigot]
|
 [vline~]


~Kyle

On 6/12/07, Claude Heiland-Allen <[EMAIL PROTECTED]> wrote:
> Dafydd Hughes wrote:
> > I never figured out exactly why the climb was happening, but I found
> > that it happened when I turned off dsp in the abstraction, but left
> > the non-dsp elements running, ie continually trying to pass messages
> > to line~ and vd~ objects etc.  Switching off the mechanics when
> > switching off dsp solved it for me.
>
> Yes, sending many messages to a vline~ in a switch~'d off subpatch
> causes CPU usage to rise dramatically.  I nearly froze my box with Pd in
> RT mode when I set the metro period to 1ms and switch~'d the subpatch
> off, with the subpatch switch~'d on the cpu usage remains stable.  See
> attached test patch...
>
> Why this is happening:
>
> Sending a message to vline~ creates a t_vseg, which are stored in a
> sorted linear linked list, which means the time taken to add each new
> line segment would be O(n), where n is the number of existing line segments.
>
> If the subpatch containing vline~ is switch~'d off, the t_vseg's aren't
> removed by the dsp perform routine, which means that CPU usage rises
> quadratically if messages are sent to the vline~ at a constant rate (I
> think, it's been a while since I analyzed algorithmic time complexity).
>
> A solution:
>
> Use a better data structure than a linked list; a balanced tree would
> reduce time complexity to O(log n) instead of O(n) (if I remember
> correctly), admittedly at the cost of harder implementation.
>
> Workaround:
>
> Don't send messages to a switch~'d off vline~.
>
>
> Claude
> --
> http://claudiusmaximus.goto10.org
>
> #N canvas 0 0 450 300 10;
> #N canvas 0 0 450 300 \$0-subpatch 0;
> #X obj 28 17 inlet;
> #X obj 26 270 outlet~;
> #X obj 208 269 switch~;
> #X obj 208 19 inlet;
> #X obj 29 48 t b b;
> #X obj 59 74 random 100;
> #X obj 24 94 random 100;
> #X obj 23 121 pack f f;
> #X obj 24 164 vline~;
> #X connect 0 0 4 0;
> #X connect 3 0 2 0;
> #X connect 4 0 6 0;
> #X connect 4 1 5 0;
> #X connect 5 0 7 1;
> #X connect 6 0 7 0;
> #X connect 7 0 8 0;
> #X connect 8 0 1 0;
> #X restore 68 117 pd \$0-subpatch;
> #X obj 161 67 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
> 1;
> #X obj 68 68 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1
> ;
> #X obj 197 67 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
> 1;
> #X msg 197 90 \; pd dsp \$1;
> #X obj 302 88 metro 1000;
> #X obj 302 111 t b b;
> #X obj 302 133 cputime;
> #X obj 302 64 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
> 1;
> #X floatatom 302 165 5 0 0 0 - - -;
> #X floatatom 119 67 5 0 0 0 - - -;
> #X obj 68 91 metro 10;
> #X text 14 205 cputime climbs when many messages are sent to a vline~
> in a switched off subpatch...;
> #X connect 1 0 0 1;
> #X connect 2 0 11 0;
> #X connect 3 0 4 0;
> #X connect 5 0 6 0;
> #X connect 6 0 7 0;
> #X connect 6 1 7 1;
> #X connect 7 0 9 0;
> #X connect 8 0 5 0;
> #X connect 10 0 11 1;
> #X connect 11 0 0 0;
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>
>


-- 
-

 -
  - --
http://perhapsidid.wordpress.com

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-12 Thread Claude Heiland-Allen

Dafydd Hughes wrote:

I never figured out exactly why the climb was happening, but I found
that it happened when I turned off dsp in the abstraction, but left
the non-dsp elements running, ie continually trying to pass messages
to line~ and vd~ objects etc.  Switching off the mechanics when
switching off dsp solved it for me.


Yes, sending many messages to a vline~ in a switch~'d off subpatch 
causes CPU usage to rise dramatically.  I nearly froze my box with Pd in 
RT mode when I set the metro period to 1ms and switch~'d the subpatch 
off, with the subpatch switch~'d on the cpu usage remains stable.  See 
attached test patch...


Why this is happening:

Sending a message to vline~ creates a t_vseg, which are stored in a 
sorted linear linked list, which means the time taken to add each new 
line segment would be O(n), where n is the number of existing line segments.


If the subpatch containing vline~ is switch~'d off, the t_vseg's aren't 
removed by the dsp perform routine, which means that CPU usage rises 
quadratically if messages are sent to the vline~ at a constant rate (I 
think, it's been a while since I analyzed algorithmic time complexity).


A solution:

Use a better data structure than a linked list; a balanced tree would 
reduce time complexity to O(log n) instead of O(n) (if I remember 
correctly), admittedly at the cost of harder implementation.


Workaround:

Don't send messages to a switch~'d off vline~.


Claude
--
http://claudiusmaximus.goto10.org
#N canvas 0 0 450 300 10;
#N canvas 0 0 450 300 \$0-subpatch 0;
#X obj 28 17 inlet;
#X obj 26 270 outlet~;
#X obj 208 269 switch~;
#X obj 208 19 inlet;
#X obj 29 48 t b b;
#X obj 59 74 random 100;
#X obj 24 94 random 100;
#X obj 23 121 pack f f;
#X obj 24 164 vline~;
#X connect 0 0 4 0;
#X connect 3 0 2 0;
#X connect 4 0 6 0;
#X connect 4 1 5 0;
#X connect 5 0 7 1;
#X connect 6 0 7 0;
#X connect 7 0 8 0;
#X connect 8 0 1 0;
#X restore 68 117 pd \$0-subpatch;
#X obj 161 67 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X obj 68 68 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1
;
#X obj 197 67 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X msg 197 90 \; pd dsp \$1;
#X obj 302 88 metro 1000;
#X obj 302 111 t b b;
#X obj 302 133 cputime;
#X obj 302 64 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0
1;
#X floatatom 302 165 5 0 0 0 - - -;
#X floatatom 119 67 5 0 0 0 - - -;
#X obj 68 91 metro 10;
#X text 14 205 cputime climbs when many messages are sent to a vline~
in a switched off subpatch...;
#X connect 1 0 0 1;
#X connect 2 0 11 0;
#X connect 3 0 4 0;
#X connect 5 0 6 0;
#X connect 6 0 7 0;
#X connect 6 1 7 1;
#X connect 7 0 9 0;
#X connect 8 0 5 0;
#X connect 10 0 11 1;
#X connect 11 0 0 0;
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-07 Thread Dafydd Hughes
Ha!  Thanks, Kyle.  Actually, it's mostly based on David Golightly's
granular delay, which is a really elegant piece of work, and without
which I never would have been able to try this.  I ended up rewriting
it without the scheduler, and changed some other stuff too.  I'm
halfway through another, but here's the most recent, which should be
way more efficient and talks OSC.  Disclaimer: it's still pretty old
and has lots of my dumb patching!

http://sideshowmedia.ca/zips/lois.zip

So strange that weirdness isn't getting duplicated.  I wonder what's up...

cheers
dafydd

On 6/6/07, Kyle Klipowicz <[EMAIL PROTECTED]> wrote:
> No problems here on a G4 PowerBook, but this delay is pretty rad, do
> you have any more?!
>
> ~Kyle
>
> On 6/6/07, Dafydd Hughes <[EMAIL PROTECTED]> wrote:
> > Hi folks
> >
> > Okay - I think this is more or less the same patch, with a couple of
> > minor changes:
> >
> > http://sideshowmedia.ca/cputest.zip
> >
> > Oddly, I can't reproduce my original problem, although some
> > fascinating new things have shown up.  Perhaps it was a PowerPC issue?
> >  (I'm now on a MacBook)
> >
> > Try switching on & off the main dsp and test_lois.  On my computer
> > (extended test 6 - delays not working in later tests) cputime goes up
> > slightly when I turn dsp off.
> >
> > I never figured out exactly why the climb was happening, but I found
> > that it happened when I turned off dsp in the abstraction, but left
> > the non-dsp elements running, ie continually trying to pass messages
> > to line~ and vd~ objects etc.  Switching off the mechanics when
> > switching off dsp solved it for me.
> >
> > I hope this helps!  I'd love to hear if this test patch climbs on a
> > PowerPC still.
> >
> > cheers
> > dafydd
> >
> > On 6/6/07, Phil Stone <[EMAIL PROTECTED]> wrote:
> > > Hi Derek,
> > >
> > > I'm not positive about this, but I think I've traced the CPU-climb to
> > > the [moog~] filter.  It has an odd behavior that can be broken into
> > > three phases:
> > >
> > > 1) no audio greater than zero amplitude has passed through it yet (since
> > > patch load)
> > > 2) audio of some amplitude >0 passes through
> > > 3) audio passing through goes back to zero amplitude
> > >
> > > At 3) (or, more accurately, several seconds after), its CPU usage climbs
> > > fairly dramatically, only to drop down again when the amplitude of the
> > > audio goes up again.   Something in the filter model doesn't like zero
> > > amplitude, but only after it's first processed something greater than 
> > > zero.
> > >
> > > I meant to test this more rigorously, but got sidetracked.  At any rate,
> > > when I switch~ the [moog~] filter out, CPU usage holds steady.  To be
> > > clear, I don't think this relates to [switch~].  I'm on a Macbook Pro,
> > > currently running 0.39rc2.
> > >
> > > Phil
> > >
> > >
> > >
> > > Derek Holzer wrote:
> > > > Hi Phil,
> > > >
> > > > just to keep this in people's minds... I have exact same problem
> > > > described in these emails with my Particle Chamber granular synthesis
> > > > patch. It has 32 "switch~ed" voices. Using one instance seems to be
> > > > OK, but two or more leads to exponentially-growing CPU usage that
> > > > eventually makes PD unresponsive to the GUI (and eventually would
> > > > probably crash PD if I let it go on...) I guess this could relate to
> > > > the "isn't the GUI supposed to have lower priority thanprocess?"
> > > > thread, since this particular problem makes PD a bit unusable for the
> > > > kind of performances I want to be doing with it. The fact that PD
> > > > lacks a usable voice-allocation method (i.e. CPU resources can be
> > > > allocated and de-allocated to a voice, something which switch~ has a
> > > > bug with, and which Nqpoly~ and so on does not do at all) means that I
> > > > must start looking into SuperCollider to work with my polyphonic
> > > > granular synthesis stuff. Sad but true...
> > > >
> > > > d.
> > > >
> > > > Phil Stone wrote:
> > > >> Hi,
> > > >>
> > > >> I'm getting a slow-but-steady climbing CPU when running some
> > > >> synthesis patches.  I (like the poster below) have sub-modules that
> > > >> can be switch~ed on and off.  An archive search turned up the
> > > >> following un-replied post:
> > > >>> Hi all
> > > >>>
> > > >>> Okay.  I'm stumped.
> > > >>>
> > > >>> Recently, I've noticed that my cpu meter has been steadily rising.
> > > >>> I  think I may have found the culprit.
> > > >>>
> > > >>> A while back I thought I'd put a power switch (just a switch~
> > > >>> object)  on my poor-man's granular delay line, as my performance
> > > >>> patches are  getting a bit bulky.
> > > >>>
> > > >>> Try this (if you have the time):
> > > >>>
> > > >>> http://www.sideshowmedia.ca/cputest.zip
> > > >>>
> > > >>> cputest.pd: (needs expr, but I think that's all)
> > > >>>
> > > >>> 1. turn on audio in pd, but leave the power (p toggle) in "lois"
> > > >>> off.  Watch the cpu meter climb (over a period of 5 minutes or so -
> > 

Re: [PD] switch~ & cputime climbing

2007-06-06 Thread hard off

i'm getting a similar problem in a large modular patch that does a LOT of
switch~ing

cpu usage just gradually climbs.  also i just switched from a powerbook
running osx, to a toshiba running ubuntu studio, so i doubt it is platform
specific.

this thread has given me a few ideas for how to debug it.  will report back
if i have any success.
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Kyle Klipowicz
No problems here on a G4 PowerBook, but this delay is pretty rad, do
you have any more?!

~Kyle

On 6/6/07, Dafydd Hughes <[EMAIL PROTECTED]> wrote:
> Hi folks
>
> Okay - I think this is more or less the same patch, with a couple of
> minor changes:
>
> http://sideshowmedia.ca/cputest.zip
>
> Oddly, I can't reproduce my original problem, although some
> fascinating new things have shown up.  Perhaps it was a PowerPC issue?
>  (I'm now on a MacBook)
>
> Try switching on & off the main dsp and test_lois.  On my computer
> (extended test 6 - delays not working in later tests) cputime goes up
> slightly when I turn dsp off.
>
> I never figured out exactly why the climb was happening, but I found
> that it happened when I turned off dsp in the abstraction, but left
> the non-dsp elements running, ie continually trying to pass messages
> to line~ and vd~ objects etc.  Switching off the mechanics when
> switching off dsp solved it for me.
>
> I hope this helps!  I'd love to hear if this test patch climbs on a
> PowerPC still.
>
> cheers
> dafydd
>
> On 6/6/07, Phil Stone <[EMAIL PROTECTED]> wrote:
> > Hi Derek,
> >
> > I'm not positive about this, but I think I've traced the CPU-climb to
> > the [moog~] filter.  It has an odd behavior that can be broken into
> > three phases:
> >
> > 1) no audio greater than zero amplitude has passed through it yet (since
> > patch load)
> > 2) audio of some amplitude >0 passes through
> > 3) audio passing through goes back to zero amplitude
> >
> > At 3) (or, more accurately, several seconds after), its CPU usage climbs
> > fairly dramatically, only to drop down again when the amplitude of the
> > audio goes up again.   Something in the filter model doesn't like zero
> > amplitude, but only after it's first processed something greater than zero.
> >
> > I meant to test this more rigorously, but got sidetracked.  At any rate,
> > when I switch~ the [moog~] filter out, CPU usage holds steady.  To be
> > clear, I don't think this relates to [switch~].  I'm on a Macbook Pro,
> > currently running 0.39rc2.
> >
> > Phil
> >
> >
> >
> > Derek Holzer wrote:
> > > Hi Phil,
> > >
> > > just to keep this in people's minds... I have exact same problem
> > > described in these emails with my Particle Chamber granular synthesis
> > > patch. It has 32 "switch~ed" voices. Using one instance seems to be
> > > OK, but two or more leads to exponentially-growing CPU usage that
> > > eventually makes PD unresponsive to the GUI (and eventually would
> > > probably crash PD if I let it go on...) I guess this could relate to
> > > the "isn't the GUI supposed to have lower priority thanprocess?"
> > > thread, since this particular problem makes PD a bit unusable for the
> > > kind of performances I want to be doing with it. The fact that PD
> > > lacks a usable voice-allocation method (i.e. CPU resources can be
> > > allocated and de-allocated to a voice, something which switch~ has a
> > > bug with, and which Nqpoly~ and so on does not do at all) means that I
> > > must start looking into SuperCollider to work with my polyphonic
> > > granular synthesis stuff. Sad but true...
> > >
> > > d.
> > >
> > > Phil Stone wrote:
> > >> Hi,
> > >>
> > >> I'm getting a slow-but-steady climbing CPU when running some
> > >> synthesis patches.  I (like the poster below) have sub-modules that
> > >> can be switch~ed on and off.  An archive search turned up the
> > >> following un-replied post:
> > >>> Hi all
> > >>>
> > >>> Okay.  I'm stumped.
> > >>>
> > >>> Recently, I've noticed that my cpu meter has been steadily rising.
> > >>> I  think I may have found the culprit.
> > >>>
> > >>> A while back I thought I'd put a power switch (just a switch~
> > >>> object)  on my poor-man's granular delay line, as my performance
> > >>> patches are  getting a bit bulky.
> > >>>
> > >>> Try this (if you have the time):
> > >>>
> > >>> http://www.sideshowmedia.ca/cputest.zip
> > >>>
> > >>> cputest.pd: (needs expr, but I think that's all)
> > >>>
> > >>> 1. turn on audio in pd, but leave the power (p toggle) in "lois"
> > >>> off.  Watch the cpu meter climb (over a period of 5 minutes or so -
> > >>> the toggle prints the cputime every 10 seconds).  On my computer
> > >>> (G4  Powerbook, HCS extended 0.38.4) it starts around 5% and hits
> > >>> 10%  after 5 minutes.
> > >>>
> > >>> 2. Do the same with "lois" on.  For me, cpu hovers around 13-14%.
> > >>> No  increase.
> > >>>
> > >>> 3. Repeat step 1.  After 10-15 minutes, cputime is higher than with
> > >>> "lois" on.  Switch "lois" on, and cpu drops.  Huh?
> > >>>
> > >>> I have no idea what's going on, but am I missing something
> > >>> important?  Thanks in advance.
> > >>>
> > >>> cheers
> > >>> dafydd
> > >>>
> > >>
> > >> Does anybody have any insight on this?  I don't remember this
> > >> happening until fairly recently, but don't know if it dates to when I
> > >> started switch~ing modules.  I'm currently running 0.39.2-extended
> > >> RC1 on a MacBook Pro.
> > >>
>

Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Dafydd Hughes
Hi folks

Okay - I think this is more or less the same patch, with a couple of
minor changes:

http://sideshowmedia.ca/cputest.zip

Oddly, I can't reproduce my original problem, although some
fascinating new things have shown up.  Perhaps it was a PowerPC issue?
 (I'm now on a MacBook)

Try switching on & off the main dsp and test_lois.  On my computer
(extended test 6 - delays not working in later tests) cputime goes up
slightly when I turn dsp off.

I never figured out exactly why the climb was happening, but I found
that it happened when I turned off dsp in the abstraction, but left
the non-dsp elements running, ie continually trying to pass messages
to line~ and vd~ objects etc.  Switching off the mechanics when
switching off dsp solved it for me.

I hope this helps!  I'd love to hear if this test patch climbs on a
PowerPC still.

cheers
dafydd

On 6/6/07, Phil Stone <[EMAIL PROTECTED]> wrote:
> Hi Derek,
>
> I'm not positive about this, but I think I've traced the CPU-climb to
> the [moog~] filter.  It has an odd behavior that can be broken into
> three phases:
>
> 1) no audio greater than zero amplitude has passed through it yet (since
> patch load)
> 2) audio of some amplitude >0 passes through
> 3) audio passing through goes back to zero amplitude
>
> At 3) (or, more accurately, several seconds after), its CPU usage climbs
> fairly dramatically, only to drop down again when the amplitude of the
> audio goes up again.   Something in the filter model doesn't like zero
> amplitude, but only after it's first processed something greater than zero.
>
> I meant to test this more rigorously, but got sidetracked.  At any rate,
> when I switch~ the [moog~] filter out, CPU usage holds steady.  To be
> clear, I don't think this relates to [switch~].  I'm on a Macbook Pro,
> currently running 0.39rc2.
>
> Phil
>
>
>
> Derek Holzer wrote:
> > Hi Phil,
> >
> > just to keep this in people's minds... I have exact same problem
> > described in these emails with my Particle Chamber granular synthesis
> > patch. It has 32 "switch~ed" voices. Using one instance seems to be
> > OK, but two or more leads to exponentially-growing CPU usage that
> > eventually makes PD unresponsive to the GUI (and eventually would
> > probably crash PD if I let it go on...) I guess this could relate to
> > the "isn't the GUI supposed to have lower priority thanprocess?"
> > thread, since this particular problem makes PD a bit unusable for the
> > kind of performances I want to be doing with it. The fact that PD
> > lacks a usable voice-allocation method (i.e. CPU resources can be
> > allocated and de-allocated to a voice, something which switch~ has a
> > bug with, and which Nqpoly~ and so on does not do at all) means that I
> > must start looking into SuperCollider to work with my polyphonic
> > granular synthesis stuff. Sad but true...
> >
> > d.
> >
> > Phil Stone wrote:
> >> Hi,
> >>
> >> I'm getting a slow-but-steady climbing CPU when running some
> >> synthesis patches.  I (like the poster below) have sub-modules that
> >> can be switch~ed on and off.  An archive search turned up the
> >> following un-replied post:
> >>> Hi all
> >>>
> >>> Okay.  I'm stumped.
> >>>
> >>> Recently, I've noticed that my cpu meter has been steadily rising.
> >>> I  think I may have found the culprit.
> >>>
> >>> A while back I thought I'd put a power switch (just a switch~
> >>> object)  on my poor-man's granular delay line, as my performance
> >>> patches are  getting a bit bulky.
> >>>
> >>> Try this (if you have the time):
> >>>
> >>> http://www.sideshowmedia.ca/cputest.zip
> >>>
> >>> cputest.pd: (needs expr, but I think that's all)
> >>>
> >>> 1. turn on audio in pd, but leave the power (p toggle) in "lois"
> >>> off.  Watch the cpu meter climb (over a period of 5 minutes or so -
> >>> the toggle prints the cputime every 10 seconds).  On my computer
> >>> (G4  Powerbook, HCS extended 0.38.4) it starts around 5% and hits
> >>> 10%  after 5 minutes.
> >>>
> >>> 2. Do the same with "lois" on.  For me, cpu hovers around 13-14%.
> >>> No  increase.
> >>>
> >>> 3. Repeat step 1.  After 10-15 minutes, cputime is higher than with
> >>> "lois" on.  Switch "lois" on, and cpu drops.  Huh?
> >>>
> >>> I have no idea what's going on, but am I missing something
> >>> important?  Thanks in advance.
> >>>
> >>> cheers
> >>> dafydd
> >>>
> >>
> >> Does anybody have any insight on this?  I don't remember this
> >> happening until fairly recently, but don't know if it dates to when I
> >> started switch~ing modules.  I'm currently running 0.39.2-extended
> >> RC1 on a MacBook Pro.
> >>
> >>
> >> Phil Stone
> >>
> >> ___
> >> PD-list@iem.at mailing list
> >> UNSUBSCRIBE and account-management ->
> >> http://lists.puredata.info/listinfo/pd-list
> >>
> >
>
>
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list

Re: [PD] switch~ & cputime climbing

2007-06-06 Thread martin.peach
That looks like the old denormal problem again, where the cpu goes into some 
kind of exception handling when a floating point value is between zero and the 
next smallest full-precision float, a number like 0.01.

Martin

> I'm not positive about this, but I think I've traced the CPU-climb to 
> the [moog~] filter.  It has an odd behavior that can be broken into 
> three phases:
> 
> 1) no audio greater than zero amplitude has passed through it yet (since 
> patch load)
> 2) audio of some amplitude >0 passes through
> 3) audio passing through goes back to zero amplitude
> 
> At 3) (or, more accurately, several seconds after), its CPU usage climbs 
> fairly dramatically, only to drop down again when the amplitude of the 
> audio goes up again.   Something in the filter model doesn't like zero 
> amplitude, but only after it's first processed something greater than zero.
> 
> I meant to test this more rigorously, but got sidetracked.  At any rate, 
> when I switch~ the [moog~] filter out, CPU usage holds steady.  To be 
> clear, I don't think this relates to [switch~].  I'm on a Macbook Pro, 
> currently running 0.39rc2.
> 
> Phil
> 
> 
> 
> Derek Holzer wrote:
> > Hi Phil,
> >
> > just to keep this in people's minds... I have exact same problem 
> > described in these emails with my Particle Chamber granular synthesis 
> > patch. It has 32 "switch~ed" voices. Using one instance seems to be 
> > OK, but two or more leads to exponentially-growing CPU usage that 
> > eventually makes PD unresponsive to the GUI (and eventually would 
> > probably crash PD if I let it go on...) I guess this could relate to 
> > the "isn't the GUI supposed to have lower priority thanprocess?" 
> > thread, since this particular problem makes PD a bit unusable for the 
> > kind of performances I want to be doing with it. The fact that PD 
> > lacks a usable voice-allocation method (i.e. CPU resources can be 
> > allocated and de-allocated to a voice, something which switch~ has a 
> > bug with, and which Nqpoly~ and so on does not do at all) means that I 
> > must start looking into SuperCollider to work with my polyphonic 
> > granular synthesis stuff. Sad but true...
> >
> > d.
> >
> > Phil Stone wrote:
> >> Hi,
> >>
> >> I'm getting a slow-but-steady climbing CPU when running some 
> >> synthesis patches.  I (like the poster below) have sub-modules that 
> >> can be switch~ed on and off.  An archive search turned up the 
> >> following un-replied post:
> >>> Hi all
> >>>
> >>> Okay.  I'm stumped.
> >>>
> >>> Recently, I've noticed that my cpu meter has been steadily rising.  
> >>> I  think I may have found the culprit.
> >>>
> >>> A while back I thought I'd put a power switch (just a switch~ 
> >>> object)  on my poor-man's granular delay line, as my performance 
> >>> patches are  getting a bit bulky.
> >>>
> >>> Try this (if you have the time):
> >>>
> >>> http://www.sideshowmedia.ca/cputest.zip
> >>>
> >>> cputest.pd: (needs expr, but I think that's all)
> >>>
> >>> 1. turn on audio in pd, but leave the power (p toggle) in "lois"  
> >>> off.  Watch the cpu meter climb (over a period of 5 minutes or so -  
> >>> the toggle prints the cputime every 10 seconds).  On my computer 
> >>> (G4  Powerbook, HCS extended 0.38.4) it starts around 5% and hits 
> >>> 10%  after 5 minutes.
> >>>
> >>> 2. Do the same with "lois" on.  For me, cpu hovers around 13-14%.  
> >>> No  increase.
> >>>
> >>> 3. Repeat step 1.  After 10-15 minutes, cputime is higher than with  
> >>> "lois" on.  Switch "lois" on, and cpu drops.  Huh?
> >>>
> >>> I have no idea what's going on, but am I missing something  
> >>> important?  Thanks in advance.
> >>>
> >>> cheers
> >>> dafydd
> >>>   
> >>
> >> Does anybody have any insight on this?  I don't remember this 
> >> happening until fairly recently, but don't know if it dates to when I 
> >> started switch~ing modules.  I'm currently running 0.39.2-extended 
> >> RC1 on a MacBook Pro.
> >>
> >>
> >> Phil Stone
> >>
> >> ___
> >> PD-list@iem.at mailing list
> >> UNSUBSCRIBE and account-management -> 
> >> http://lists.puredata.info/listinfo/pd-list
> >>
> >
> 
> 
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Claude Heiland-Allen
Derek Holzer wrote:
> This could almost be the denormal problem again. Is it an Intel 
> processor on the MacBook? Intels are notorious for poor handling of 
> denormal numbers, which occur when the mantissa (decimal places) of a 
> number representing an audio signal becomes too long (such as happens 
> with reverb tails, etc). Check the archives for more than just a bit of 
> discussion on this, with some solutions (?) and certainly some workarounds.

Some solutions are presented here, with rationales as when each solution 
is best used:

http://www.musicdsp.org/files/denormal.pdf

In my exponential decay envelopes, I add a small number and subtract it 
again, which forces denormals (which are very close to zero) to be 
exactly zero.

Example: if you have 4 significant digits:

denoraml  = 0.0001234
denormal  + 0.0001234=> 0.00012341234
truncate to 4 significant digits => 0.0001234
truncated - 0.0001234=> 0 (exact)

This has to be done *within* the feedback loop, as that is where the 
denormals cause bigger problems.

Other methods may be more appropriate for different scenarios...


BTW: it isn't just Intel processors, on AMD athlon-xp I reduced CPU 
usage a fair bit too (although I hear Intel Pentium-4 is particularly bad).


Claude
-- 
http://claudiusmaximus.goto10.org

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Phil Stone
Derek Holzer wrote:
> This could almost be the denormal problem again. Is it an Intel 
> processor on the MacBook? Intels are notorious for poor handling of 
> denormal numbers, which occur when the mantissa (decimal places) of a 
> number representing an audio signal becomes too long (such as happens 
> with reverb tails, etc). Check the archives for more than just a bit 
> of discussion on this, with some solutions (?) and certainly some 
> workarounds.
Yes, it's an Intel Core Duo in the MacBook.  When I first noticed this 
pattern, I thought it sounded like denormalling, but I dismissed the 
idea, thinking that Core Duo's couldn't *still* have this problem.

How wrong I was.   Your reply prompted me to do a little web searching.  
See:  http://charm.cs.uiuc.edu/subnormal/  and notice how abysmally the 
Core Duo performs in denormal situations -- worse than previous Intels, 
if this benchmark is to be believed.

Thank you (and others who mentioned this) for pushing me past the "can't 
be" stage.  I'll look into workarounds.


Phil

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Derek Holzer
This could almost be the denormal problem again. Is it an Intel 
processor on the MacBook? Intels are notorious for poor handling of 
denormal numbers, which occur when the mantissa (decimal places) of a 
number representing an audio signal becomes too long (such as happens 
with reverb tails, etc). Check the archives for more than just a bit of 
discussion on this, with some solutions (?) and certainly some workarounds.

Sounds like I need to look deeper into my own patches as well, to find 
this CPU climbing business in my granulators. I find it most weird that 
one instance has no issues, but two or more cause problems. It's like 
they interfere with each other. I rigorously checked all send/receive 
pairs and such, so I don't know what it could be at this point. Except 
grossly inconvenient!

d.

Phil Stone wrote:
> Hi Derek,
> 
> I'm not positive about this, but I think I've traced the CPU-climb to 
> the [moog~] filter.  It has an odd behavior that can be broken into 
> three phases:
> 
> 1) no audio greater than zero amplitude has passed through it yet (since 
> patch load)
> 2) audio of some amplitude >0 passes through
> 3) audio passing through goes back to zero amplitude
> 
> At 3) (or, more accurately, several seconds after), its CPU usage climbs 
> fairly dramatically, only to drop down again when the amplitude of the 
> audio goes up again.   Something in the filter model doesn't like zero 
> amplitude, but only after it's first processed something greater than zero.
> 
> I meant to test this more rigorously, but got sidetracked.  At any rate, 
> when I switch~ the [moog~] filter out, CPU usage holds steady.  To be 
> clear, I don't think this relates to [switch~].  I'm on a Macbook Pro, 
> currently running 0.39rc2.

-- 
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 64:
"Don't stress one thing more than another"

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Phil Stone
Hi Derek,

I'm not positive about this, but I think I've traced the CPU-climb to 
the [moog~] filter.  It has an odd behavior that can be broken into 
three phases:

1) no audio greater than zero amplitude has passed through it yet (since 
patch load)
2) audio of some amplitude >0 passes through
3) audio passing through goes back to zero amplitude

At 3) (or, more accurately, several seconds after), its CPU usage climbs 
fairly dramatically, only to drop down again when the amplitude of the 
audio goes up again.   Something in the filter model doesn't like zero 
amplitude, but only after it's first processed something greater than zero.

I meant to test this more rigorously, but got sidetracked.  At any rate, 
when I switch~ the [moog~] filter out, CPU usage holds steady.  To be 
clear, I don't think this relates to [switch~].  I'm on a Macbook Pro, 
currently running 0.39rc2.

Phil



Derek Holzer wrote:
> Hi Phil,
>
> just to keep this in people's minds... I have exact same problem 
> described in these emails with my Particle Chamber granular synthesis 
> patch. It has 32 "switch~ed" voices. Using one instance seems to be 
> OK, but two or more leads to exponentially-growing CPU usage that 
> eventually makes PD unresponsive to the GUI (and eventually would 
> probably crash PD if I let it go on...) I guess this could relate to 
> the "isn't the GUI supposed to have lower priority thanprocess?" 
> thread, since this particular problem makes PD a bit unusable for the 
> kind of performances I want to be doing with it. The fact that PD 
> lacks a usable voice-allocation method (i.e. CPU resources can be 
> allocated and de-allocated to a voice, something which switch~ has a 
> bug with, and which Nqpoly~ and so on does not do at all) means that I 
> must start looking into SuperCollider to work with my polyphonic 
> granular synthesis stuff. Sad but true...
>
> d.
>
> Phil Stone wrote:
>> Hi,
>>
>> I'm getting a slow-but-steady climbing CPU when running some 
>> synthesis patches.  I (like the poster below) have sub-modules that 
>> can be switch~ed on and off.  An archive search turned up the 
>> following un-replied post:
>>> Hi all
>>>
>>> Okay.  I'm stumped.
>>>
>>> Recently, I've noticed that my cpu meter has been steadily rising.  
>>> I  think I may have found the culprit.
>>>
>>> A while back I thought I'd put a power switch (just a switch~ 
>>> object)  on my poor-man's granular delay line, as my performance 
>>> patches are  getting a bit bulky.
>>>
>>> Try this (if you have the time):
>>>
>>> http://www.sideshowmedia.ca/cputest.zip
>>>
>>> cputest.pd: (needs expr, but I think that's all)
>>>
>>> 1. turn on audio in pd, but leave the power (p toggle) in "lois"  
>>> off.  Watch the cpu meter climb (over a period of 5 minutes or so -  
>>> the toggle prints the cputime every 10 seconds).  On my computer 
>>> (G4  Powerbook, HCS extended 0.38.4) it starts around 5% and hits 
>>> 10%  after 5 minutes.
>>>
>>> 2. Do the same with "lois" on.  For me, cpu hovers around 13-14%.  
>>> No  increase.
>>>
>>> 3. Repeat step 1.  After 10-15 minutes, cputime is higher than with  
>>> "lois" on.  Switch "lois" on, and cpu drops.  Huh?
>>>
>>> I have no idea what's going on, but am I missing something  
>>> important?  Thanks in advance.
>>>
>>> cheers
>>> dafydd
>>>   
>>
>> Does anybody have any insight on this?  I don't remember this 
>> happening until fairly recently, but don't know if it dates to when I 
>> started switch~ing modules.  I'm currently running 0.39.2-extended 
>> RC1 on a MacBook Pro.
>>
>>
>> Phil Stone
>>
>> ___
>> PD-list@iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list
>>
>


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread dafydd hughes
Oh gosh...

I think I can remember what it involved, but I don't think I have the
patch anymore.

Let me see if I can dig it up.

cheers
dafydd

On 6/6/07, Derek Holzer <[EMAIL PROTECTED]> wrote:
> Ooops! File not found! Dafydd...could you re-post your test patch please?
>
> http://www.sideshowmedia.ca/cputest.zip
>
> thx,
> d.
>
> Derek Holzer wrote:
>
> > One test patch came up earlier in thread:
> >
> > http://lists.puredata.info/pipermail/pd-list/2007-04/049372.html
>
> --
> derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
> ---Oblique Strategy # 104:
> "Listen in total darkness, or in a very large room, very quietly"
>


-- 
www.sideshowmedia.ca
skype: chickeninthegrass

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Derek Holzer
Ooops! File not found! Dafydd...could you re-post your test patch please?

http://www.sideshowmedia.ca/cputest.zip

thx,
d.

Derek Holzer wrote:

> One test patch came up earlier in thread:
> 
> http://lists.puredata.info/pipermail/pd-list/2007-04/049372.html

-- 
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 104:
"Listen in total darkness, or in a very large room, very quietly"

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Derek Holzer
Hi Roman,

Roman Haefeli wrote:

> this is definitely not a general problem of pd. the most
> netpd-instruments do switch~ing all the time and i never noticed an
> increasing cpu usage over time on my and on many other computers. 

> you might also provide a little testpatch, that triggers to problem on
> your machine, so that everyone can easily test as well.

One test patch came up earlier in thread:

http://lists.puredata.info/pipermail/pd-list/2007-04/049372.html

> here:
> 
> ubuntu dapper
> pd-vanilla 0.40.2 (compiled from source)
> no increased cpu usage due to [switch~]ing

Here:

Mac Powerbook 1.67 GHz PowerPC G4

OSX 10.4.9, PD Extended 0.39.2
and
Gentoo Linux, PD 0.39.2 self-compiled

both exhibit exponential CPU climbing, will test more with mentioned 
test patch and report back

best,
d.


-- 
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 14:
"Ask people to work against their better judgement"

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Roman Haefeli
On Wed, 2007-06-06 at 13:27 +0300, Derek Holzer wrote:
> Hi Phil,
> 
> just to keep this in people's minds... I have exact same problem 
> described in these emails with my Particle Chamber granular synthesis 
> patch. It has 32 "switch~ed" voices. Using one instance seems to be OK, 
> but two or more leads to exponentially-growing CPU usage that eventually 
> makes PD unresponsive to the GUI (and eventually would probably crash PD 
> if I let it go on...) I guess this could relate to the "isn't the GUI 
> supposed to have lower priority than  process?" thread, since this 
> particular problem makes PD a bit unusable for the kind of performances 
> I want to be doing with it. The fact that PD lacks a usable 
> voice-allocation method (i.e. CPU resources can be allocated and 
> de-allocated to a voice, something which switch~ has a bug with, and 
> which Nqpoly~ and so on does not do at all) means that I must start 
> looking into SuperCollider to work with my polyphonic granular synthesis 
> stuff. Sad but true...

this is definitely not a general problem of pd. the most
netpd-instruments do switch~ing all the time and i never noticed an
increasing cpu usage over time on my and on many other computers. 

that is why i think it would be interesting to know, if this problem is
os or pd-distro specific. maybe it would make sense to collect
information about systems, where this is happening and where not, in
order to isolate the source of the problem. 
you might also provide a little testpatch, that triggers to problem on
your machine, so that everyone can easily test as well.


here:

ubuntu dapper
pd-vanilla 0.40.2 (compiled from source)
no increased cpu usage due to [switch~]ing

 



___ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de


___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] switch~ & cputime climbing

2007-06-06 Thread Derek Holzer
Hi Phil,

just to keep this in people's minds... I have exact same problem 
described in these emails with my Particle Chamber granular synthesis 
patch. It has 32 "switch~ed" voices. Using one instance seems to be OK, 
but two or more leads to exponentially-growing CPU usage that eventually 
makes PD unresponsive to the GUI (and eventually would probably crash PD 
if I let it go on...) I guess this could relate to the "isn't the GUI 
supposed to have lower priority thanprocess?" thread, since this 
particular problem makes PD a bit unusable for the kind of performances 
I want to be doing with it. The fact that PD lacks a usable 
voice-allocation method (i.e. CPU resources can be allocated and 
de-allocated to a voice, something which switch~ has a bug with, and 
which Nqpoly~ and so on does not do at all) means that I must start 
looking into SuperCollider to work with my polyphonic granular synthesis 
stuff. Sad but true...

d.

Phil Stone wrote:
> Hi,
> 
> I'm getting a slow-but-steady climbing CPU when running some synthesis 
> patches.  I (like the poster below) have sub-modules that can be 
> switch~ed on and off.  An archive search turned up the following 
> un-replied post:
>> Hi all
>>
>> Okay.  I'm stumped.
>>
>> Recently, I've noticed that my cpu meter has been steadily rising.  I  
>> think I may have found the culprit.
>>
>> A while back I thought I'd put a power switch (just a switch~ object)  
>> on my poor-man's granular delay line, as my performance patches are  
>> getting a bit bulky.
>>
>> Try this (if you have the time):
>>
>> http://www.sideshowmedia.ca/cputest.zip
>>
>> cputest.pd: (needs expr, but I think that's all)
>>
>> 1. turn on audio in pd, but leave the power (p toggle) in "lois"  
>> off.  Watch the cpu meter climb (over a period of 5 minutes or so -  
>> the toggle prints the cputime every 10 seconds).  On my computer (G4  
>> Powerbook, HCS extended 0.38.4) it starts around 5% and hits 10%  
>> after 5 minutes.
>>
>> 2. Do the same with "lois" on.  For me, cpu hovers around 13-14%.  No  
>> increase.
>>
>> 3. Repeat step 1.  After 10-15 minutes, cputime is higher than with  
>> "lois" on.  Switch "lois" on, and cpu drops.  Huh?
>>
>> I have no idea what's going on, but am I missing something  
>> important?  Thanks in advance.
>>
>> cheers
>> dafydd
>>   
> 
> Does anybody have any insight on this?  I don't remember this happening 
> until fairly recently, but don't know if it dates to when I started 
> switch~ing modules.  I'm currently running 0.39.2-extended RC1 on a 
> MacBook Pro.
> 
> 
> Phil Stone
> 
> ___
> PD-list@iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 

-- 
derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista
---Oblique Strategy # 109:
"Lost in useless territory"

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


[PD] switch~ & cputime climbing

2007-04-27 Thread Phil Stone
Hi,

I'm getting a slow-but-steady climbing CPU when running some synthesis 
patches.  I (like the poster below) have sub-modules that can be 
switch~ed on and off.  An archive search turned up the following 
un-replied post:
> Hi all
>
> Okay.  I'm stumped.
>
> Recently, I've noticed that my cpu meter has been steadily rising.  I  
> think I may have found the culprit.
>
> A while back I thought I'd put a power switch (just a switch~ object)  
> on my poor-man's granular delay line, as my performance patches are  
> getting a bit bulky.
>
> Try this (if you have the time):
>
> http://www.sideshowmedia.ca/cputest.zip
>
> cputest.pd: (needs expr, but I think that's all)
>
> 1. turn on audio in pd, but leave the power (p toggle) in "lois"  
> off.  Watch the cpu meter climb (over a period of 5 minutes or so -  
> the toggle prints the cputime every 10 seconds).  On my computer (G4  
> Powerbook, HCS extended 0.38.4) it starts around 5% and hits 10%  
> after 5 minutes.
>
> 2. Do the same with "lois" on.  For me, cpu hovers around 13-14%.  No  
> increase.
>
> 3. Repeat step 1.  After 10-15 minutes, cputime is higher than with  
> "lois" on.  Switch "lois" on, and cpu drops.  Huh?
>
> I have no idea what's going on, but am I missing something  
> important?  Thanks in advance.
>
> cheers
> dafydd
>   

Does anybody have any insight on this?  I don't remember this happening 
until fairly recently, but don't know if it dates to when I started 
switch~ing modules.  I'm currently running 0.39.2-extended RC1 on a 
MacBook Pro.


Phil Stone

___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list