Howdy all,

working on refining a couple oscillator designs that I have, and I know that the expr~ object working on signals can be cpu intensive.

However, I'm a little unclear on which cases in which it should be avoided and replaced with equivalent objects.

For example, I have a couple places where I have control signals, like envelope generators, that need simple operations performed. In one such case I have an expr~ object performing a reciprocal 1 / $v1 operation. In another cases I have even simpler operations that could be described as lines (like 1/2 $v1 + 0.5).
Because these are not audio rate signals, I'm assuming its safe enough to use the expr~ object. Although it would certainly be very easy to map these functions out to tables and use a tabread object to do the operations instead.

In another case, I compare the output of two audio signals and output a one on one side of the expr~ object if the first is larger and a one on the other side in the opposite case.

this is what I'm describing
[expr~ $v1 > $v2;
$v1 <= $v2]

I figure this must be relatively expensive, but unless there are some cheap comparator objects that are equally accurate, I can't think of any alternatives.

In another case, I compare the output of a phasor signal to a constant value to generate pulses (expr~ if ($v1 > 0.5, 1, 0)). I understand I could create a table in which x values below 0.5 equaled 0 and those above equaled one to achieve the same effect. I worry that this could be inaccurate at the discontinuity. For timing purposes, epxr~ has been accurate, and this is something I can't sacrifice.

Sorry for doing so much thinking aloud here, I do have one quick question- how do you record your cpu usage normally? is there an abstraction that works well, or do people just use tools available with their operating systems?

Having said that, do windows users find task manager acceptable, or is there something preferred?

Thanks everyone

Good questions. I'll try to answer them as best I can, but I don't really run benchmarks myself, so I might not be 100% right.

Right off the bat, though, [expr~] is a little more cpu intensive, but nothing significant. It's probably okay to use it whenever you like with today's processors, and in some cases it may make your patch easier to read. But I do understand wanting super efficiency .

@LarsXI said:

Because these are not audio rate signals, I'm assuming its safe enough to use the expr~ object.

Slightly confused here. If they're not audio rate, why aren't you using [expr]?

In another case, I compare the output of two audio signals and output a one on one side of the expr~ object if the first is larger and a one on the other side in the opposite case.

this is what I'm describing
[expr~ $v1 > $v2;
$v1 <= $v2]

I figure this must be relatively expensive, but unless there are some cheap comparator objects that are equally accurate, I can't think of any alternatives.

If you can just do the math by scaling the output of [expr~ $v1>$v2] so that it responds the way you want when it outputs a zero (i.e. if $v1<=$v2), that will be cheaper. Also, vanilla has [>~] et al., but they are broken on extended. If you want your patches to be compatible, or if you're using extended, [expr~] is the way to go.

In another case, I compare the output of a phasor signal to a constant value to generate pulses (expr~ if ($v1 > 0.5, 1, 0)).

Just using [expr~ $v1>0.5] will give you the same results. It outputs 1 if true, 0 if false. Table lookup will be faster, but in cases where you have a strict threshold like this, use [tabread~] over [tabread4~].

I think this will work fine:

[*~ 2]
|
[tabread~ mytable]

where the table is two points, 0 at index 0 and 1 at index 1. Though, on such a simple function it's probably overkill. Table lookup is really only worth it for more complex functions, like building a faster [mtof~].

Also, it's worth pointing out that in the case of [pow~], the one used in vanilla and the on extended currently defaults to are not compatible. I think this supposed to change in future releases of extended, but right now for compatibility purposes it's safer to go with [expr~ pow()].

Hope that helps.

@Maelstorm said:

@LarsXI said:

Because these are not audio rate signals, I'm assuming its safe enough to use the expr~ object.

Slightly confused here. If they're not audio rate, why aren't you using [expr]?

Ah, I have a couple oscillators I'm performing a function on, and the modulation source is the same, but its scaled a little differently for each. So, I'm using an envelope generator to create the signal? I guess that makes it audio rate anyway. haha. I have this lingering assumption that slower audio rate changes are less cpu intensive than faster ones, but maybe this is something left over from other programs I've used. So that an lfo will cost less than an audio rate oscillator. I guess the time resolution is the same, though, so this doesn't hold then.

Thanks for the explanation of the greater/less than operations. I definately have a better idea of how to configure them now. I end up using them a lot in funny operations on phasor~ output to animate wavetables. Looks like I can update the soft sync patch once more