how to handle control, views and patch ?

Before we dive into the strategies that we could implement, let me first introduce what we are talking about.

control

This is used by remote devices to:

1. get the list of available methods
2. get the type of these methods
3. set and get the current value
4. be notified on method CREATE or DELETE

view

A view is simply a description of widgets (position, type, method connection) that should be displayed on an interface (or mapped to some hardware controls).

In order to build a view, we need the following information:

1. list of widgets
2. widget position and type
3. method(s) to control
4. a way to CREATE and DELETE widgets

patch

A patch enables the remote interface to view and update the signal processing (reprogram). In order to enable this remote programming, we need:

1. list of “nodes” (method containers)
2. node position and type
3. list of methods in each node
4. list of outlets in each “node” (signal sources that can be connected to methods)
5. a way to CREATE and DELETE nodes, outlet connections or methods

strategy

Currently, we are using a strategy based on pure osc calls for control (get method listing, get types, set/get values). But we do not handle DELETE operations there.

The other two parts use JSON to encode views and patch information. CREATE and DELETE are supported with new keys in the JSON dictionary or keys set to null.

problems

Using different mechanisms (JSON + “pure” osc) forces duplication of functionality and it is never clear where and how to notify the changes.

It would be nice to have a unique way to handle each of the needs listed above. If we go for an url based system (where everything is exposed through it’s own url), we might get into trouble: too many elements in index, using too much ram.

In order to evaluate the “everything has an url” solution, I created 100’000 objects and this used 197Mb (64bit). This means that (once 1.2Mb overhead has been removed) that each object takes around 2Kb and that’s not negligible. Compilation with 32bit only takes 158Mb, 967Kb overhead = 1.5Kb per object.

This means that if every object has to generate approximately 10 sub-objects (”/obj/@view”, ”/obj/@view/x”, ”/obj/@view/y”, ”/obj/@view/width”, ”/obj/@view/height”, ”/obj/@view/hue”, ”/obj/@view/widget”, ”/obj/@class”), this means that useful objects weight around 20Kb and that’s a waste of resources !

needs

As you can see in this second draft, if we move “widgets” into their own url, we can reduce the number of needs to 7 and we therefore consider widget definition (position, size, etc) as attributes. Same goes for node definition and eventually link definition. This has the added advantage that we can simply add a Hash in Object to store all attributes, without the Object needing to know anything about them.

See oscit for details on attributes.