Tiny Orbit

I have been using the Function object quite a bit in my own patching recently but I have always unnecessarily run it at audio rate. I was wondering if anybody knew how i could run the attached patch at event rate, rather then audio rate, so as to be more efficient on the CPU

running-the-function-object-at-event-rate

The [function] object is not actually an MSP object. Just send an x value in its left inlet, and it will send the corresponding y value of the function out its left outlet. Thus, you can step through the domain to step through the function.

Do note that when you run it at event rate, your timing will probably drift because of accumulated timing errors.

If CPU usage is a major concern, I'd look into downsampling via poly~. (There are several threads that discuss how). The timing performance should be much better.

If CPU usage is a major concern, I'd look into downsampling via poly~.  (There are several threads that discuss how). The timing performance should be much better.


No need to fear "drift" if you do the math right. There seems to be a commonly held misconception that Max can't deal with sub-millisecond timing.

Drift doesn't matter much in the short run, so if this is just a one-shot type of thing, then it'd be totally fine timing wise. It really depends on what you're doing, how long you're doing it for, and how precisely timed events need to be. YMMV, and see what works for your application.

If you were going to use the envelope as an LFO those sub-milliseconds can add up (and differences may not always show up in tests under lower processor loads). My (admittedly fussy) preference is still for a signal based approach because I find it easier to reason with and because it is not affected by what else is happening in the patch (or if it is, that's a sign of something catastrophic usually). The cost is higher in terms of CPU (though downsampling helps a great deal) but the costs are baked into the system. Zigzag~ would also be a good option for an envelope-like LFO since it will do what line~ does, but with looping and extra functions.

The bit below is messy but shows the drift in iterative timing approaches (e.g. connecting bang from line~ back into function). A metro-based solution will be pretty tight relative to phasor~ provided that the timing interval doesn't change, though it will differ it does since metro's clock interval doesn't get updated at the same rate as phasor~'s. A better test would probably involve loading 50 copies of this patch...

Drift doesn't matter much in the short run, so if this is just a one-shot type of thing, then it'd be totally fine timing wise.  It really depends on what you're doing, how long you're doing it for, and how precisely timed events need to be.  YMMV, and see what works for your application.

If you were going to use the envelope as an LFO those sub-milliseconds can add up (and differences may not always show up in tests under lower processor loads).  My (admittedly fussy) preference is still for a signal based approach because I find it easier to reason with and because it is not affected by what else is happening in the patch (or if it is, that's a sign of something catastrophic usually).   The cost is higher in terms of CPU (though downsampling helps a great deal) but the costs are baked into the system.  Zigzag~ would also be a good option for an envelope-like LFO since it will do what line~ does, but with looping and extra functions.  

The bit below is messy but shows the drift in iterative timing approaches (e.g. connecting  bang from line~ back into function).  A metro-based solution will be pretty tight relative to phasor~ provided that the timing interval doesn't change, though it will differ it does since metro's clock interval doesn't get updated at the same rate as phasor~'s.  A better test would probably involve loading 50 copies of this patch...


The bang that comes out of the right outlet of [line~] is fine for notifying that the end of the breakpoint function has been reached, but it should not be relied upon for impeccable timing accuracy to trigger itself repetitively (e.g., in emulation of [phasor~]). There will almost always be a small difference between the time the [line~] reaches its destination and the start of the next signal vector (which is the soonest it can begin its next ramp).

Wow, cheers guys this was an excellent answer !

Running the Function Object at Event Rate