What is the performance cost of observing a property with live.observer?

startec's icon

Ideally I would observe every property in my Live set with a live.observer.

Is there a significant performance penalty to having many of these objects in my set?

Does the performance of a live.observer change if the property that is observing changes frequently?

Marc Assenmacher's icon

I would also like to know more about this.

schlam's icon

Hello.

The announcement of Live 12 seems to be interesting about the "performance pack".
Because "observe every property in my Live set", as you said, is a kind of "goal" for lot of people.
I can wait to test how the new "variation" device and the ''Performer" device are made/working..


The daily patch I am using is observing and morphing more than 1000 parameters in a Live.set and it's working (sometimes=) quite good...Iit's really not perfect and I can feel some lag sometimes. So, lots of [Live observer} can be used, but the use of deferlow with this object can be tricky sometimes if you read all the warnings of the console that seem to be "false positive" warnings... Anyway, imo, I observe that Live.observer is often sending information twice, and sometimes more.. (someone confirms?), but you can use a lot of them with the use of [deferlow] and [change].

Trying to answer to your last question: "Does the performance of a live.observer change if the property that is observing changes frequently?"

I don't think that the performance of the object changes, but the consequences can be "after" the live.observer. You may have to use [deferlow] or speedlim/qlim after...