draggable unknown method draggable() (Article context)

title unknown method title(:link=>String) (Page context)

An @ObjectProxy@ is used to mirror a specific object in a remote tree. It contains the same type signature, information and value. For example, if you have a remote tree synth with some "cutoff" parameter (url = @osc://"funky synth"/osc1/cutoff@), you will interact locally with the remote synth by reading/modifying the @ObjectProxy@. How you design your proxy object in order to interact with it is up to you, this is why ObjectProxies have to be subclassed, usually as some kind of Widget (slider, button, etc). A sub-class of "":199 is responsible for instantiating the right Widget given a remote object's type signature.

title unknown method title(:link=>String) (Page context)

An ObjectProxy keeps a cached value of the remote object's value. When it receives a local call (through the @trigger@ method), it should return the cached value or update the remote value. When a local object calls an @ObjectProxy@, it will always receive the *old value* as reply since the update operation is asynchronous. Of course, since this is just a proxy, no notification is sent from this end.

title unknown method title(:link=>String) (Page context)

When you want to change the value of a remote object, you "do something on the object proxy" (turn a button, move a slider, say "hi") and this action should call @set_value@ on the proxy. It is the @ObjectProxy@'s responsibility to forward the change to the remote object it is mirroring. [slider] --- set_value ---> [remote]/osc1/cutoff 45.0

title unknown method title(:link=>String) (Page context)

When you or someone else changes the value of an object, the object sends notifications (see "":198). These are routed to the ObjectProxy by "":200. When such a notification arrives, it updates the cached value and triggers a @value_changed@ call on the @ObjectProxy@. [remote]/osc1/cutoff 45.0 ---> value_changed ---> [slider update] As you can see, all these updates are made asynchronously (first send a query to change, then receive a "changed" notification). This requires special attention when building the widgets in order to give users a proper feedback on the success or failure of an operation. !<.213_full/! In the slider shown here, the idea is that the user moves the "ghost" slider freely (this slider is connected to @set_value@ in the @ObjectProxy@). The "current value" slider is only changed by the notifications to @value_changed@. This means that the user "feels" the latency and knows exactly what is happening.