Wondering if there's a more efficient way to do the bit in gray. It's an approximation of InRange.ar(signal, low, high) from SuperCollider (except that InRange is 1 if low <= signal <= high, while this Pd patch produces 1 for low < signal < high, close enough).

(I never understood why signal-rate comparators aren't in vanilla...? I know they're in cyclone but that doesn't explain the reasoning why they didn't make the cut for vanilla.)

hjh

How about [expr~ if((($v1 > $f2) && ($v1 < $f3)), 1, 0)]

@ddw_music you can also spoof relationals by using a [tabread~] with an array that only has a 0 and a 1

probably cheaper:
outrange~

for inrange~
invert this by substracting [-~] this from [sig~ 1]

alexandros -- Sure. I was also thinking of the advice to avoid expr~ wherever possible, for performance. (Come to think of it... aren't you the developer of omniFilter_abs~, which reworks the mmb filters to avoid fexpr~?)

seb-harmonik.ar -- I wonder whether tabread~ or clip~ is faster.

lacuna -- Ooh, that's very good. I had half of this idea (recognizing that the signal, clipped to the range, would be equal to one of the endpoints for out of range inputs) but I hadn't come up with the rest.

Thanks!
hjh

@ddw_music [expr~] is not terribly expensive for CPU, [fexpr~] is the one to avoid and never use unless you have an actual reason to do so. The few times I have tested [expr~] against the vanilla solution, [expr~] won out thanks to its larger number of operations making the math simpler.

@oid said:

@ddw_music [expr~] is not terribly expensive for CPU, [fexpr~] is the one to avoid and never use unless you have an actual reason to do so.

Good to know (and easy to get confused about).

hjh

Tested it by [clone]ing:
in this case [expr~] is much more expensive than Vanilla:
almost triple CPU, double RAM and took longer to "create", too.

perftest.zip

Of course, patching-wise it's the other way around ...

@lacuna From what I understand [cputime] is not accurate for measuring actual cpu use, something about pd not knowing what else is done by the cpu during that time, only knows when to start and stop timing, you can not isolate individual bits of the patch so neatly on the cpu level and you can not keep the cpu from doing other things. Do you know if that is accurate? On my computer [expr~] ends up double the cpu as measured by [cputime] and 0.4% more when measured by htop but has the occasional peak at about double cpu.

@lacuna said:

perftest.zip

[expr~] is almost twice as hard on CPU as the vanilla version.

That being said, I also miss vanilla logic operators for signals, and how to hack them at minimum CPU (without [expr~]) is one of my pet peevs

@bocanegra Putting more into [expr~] tends to drop it's usage from my experience, a bulk of cpu is the object itself for simple operations, so if you dump more of the patch into the object and not use it just to be a simple operator cpu use will start getting better and more in line with vanilla objects. This does lead to somewhat ridiculous 3 or 4 line long [expr~]s, but it works. Should add that it was a good while ago that I played with this and I am second guessing my abilities back then, but that might just be unfounded fear coming from having recently looked at and reworked some of my abstractions from those days.

@oid said:

a bulk of cpu is the object itself for simple operations

This is my primary objection to the [expr] family. The second is the lack of portability to various (lib)pd implemetations