Now I noticed this weird thing:

Compare this: [bang~] | [t b b] | | [timer] | (number) to this:

[bang~] | [t b b] | | [realtime] | (number)

With [timer] I get 1.45125, which is 64/44100*1000 as expected. With [realtime], I would expect a slightly varying value around 1.45125 approximately, but I get values below 0.1!!!!!!

Why????

The answer to this question may perhaps suggest me a trick to get the cpu-load calculations I mentioned......

Thanks m.

2008/1/10, matteo sisti sette matteosistisette@gmail.com:

Hi,

I wish I could estimate "cpu usage" (in terms I will define later) from within the patch, in order to have some part of the patch adapt to it and work with higher "resolution" when more "free" cpu power is available, and less when the cpu load is higher. For instance, I would like to have some vu-meters to monitor various signal levels, but vu-meters are expensive and I must avoid audio dropouts, so I'd like my monitors to be less accurate when I need to save cpu power, and more accurate when they can.

So, what do I mean with "cpu usage"... Suppose I could have a bang when a DSP cycle is started, and a bang when the same DSP cycle is complete: by sending those bangs to a [realtime] I could measure the interval and divide it by the teorical duration of a DSP block (i.e. 64/44100*1000 milliseconds): that would give me an estimation (however reliable) of the percentage of block time that is actually spent in computing audio data. This would be enough for me to start trying out something.

Any idea of how to do that? I know [bang~] gives a bang at the end of each DSP cycle, but how to get a bang at the beginning of the cycle?

Any other suggestion?

Thanks in advance m.

-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com

have a look at the [dsp] object/abstraction. it uses [cputime]. you should be able to feed this directly back to your patch. for example, if dsp reaches a certain percentage, then turn off some subpatches or reduce the refresh rate of your vu meters... marius.

matteo sisti sette wrote:

Hi,

I wish I could estimate "cpu usage" (in terms I will define later) from within the patch, in order to have some part of the patch adapt to it and work with higher "resolution" when more "free" cpu power is available, and less when the cpu load is higher. For instance, I would like to have some vu-meters to monitor various signal levels, but vu-meters are expensive and I must avoid audio dropouts, so I'd like my monitors to be less accurate when I need to save cpu power, and more accurate when they can.

So, what do I mean with "cpu usage"... Suppose I could have a bang when a DSP cycle is started, and a bang when the same DSP cycle is complete: by sending those bangs to a [realtime] I could measure the interval and divide it by the teorical duration of a DSP block (i.e. 64/44100*1000 milliseconds): that would give me an estimation (however reliable) of the percentage of block time that is actually spent in computing audio data. This would be enough for me to start trying out something.

Any idea of how to do that? I know [bang~] gives a bang at the end of each DSP cycle, but how to get a bang at the beginning of the cycle?

Any other suggestion?

Thanks in advance m.