Smart Signals and Nodes

Smart signals

• Full integration with Jamoma Graph and Audio Graph
• signal version of parameter What do we need in it ?
• time-stamped parameter changes?

Smart nodes

Nodes in the NodeLib have more intelligence: rather than simply providing a access to the tree, it can perform functions on the tree including activity notifications and the such. This alleviates such work from the hub and parameters and makes it more general.

Email correspondence from jamoma-devel follows.

Hi Tim, I understand the idea but for now the NodeLib (and how Modular0.6 use it) is not working this way. In 0.6, the NodeLib only references TTObjects under a TTNode stored at an address, it notifies observers of address creation/destruction and provides tools to look into these database. So a lot of TTModular classes used to look into / subscribe to the NodeLib in order to make an internal cache of TTObjects (updating it each time an address creation/destruction appends). Then, when those TTModular classes do what they have to do, they call messages / set attributes directly on the TTObjects they bind. Considering this mecanism, the TTContainer cache all the TTObjects registered under his address and then observe their Value attribute / Command message to provide the feature I described in last mail. I had certainly a good reason to do that when I choose to separate the NodeLib from the TTObject activity but I can't remember this reason. But I'm agree this features about NodeLib dealing with TTObject's activity should be a feature for 0.7 ;-) Best, TO Le 10 mars 11 à 04:03, Timothy Place a écrit :

I might be really wrong here, so please feel free to discard this idea.

If we back up and stop thinking about Max patches for a minute, and instead we just thinking about a tree structure. The tree structure is represented in various ways, one of which is our OpenSoundControl namespace. Like this:

                         bitdepth
        aDegradeModule <

myPatcher < srRatio anotherModule

I'm imagining that the hub represents the two nodes in this tree named "aDegradeModule" and "anotherModule". The hub, as the representative of this node in the tree, should be able to provide the information about activity of itself and its sub-nodes.

One possible implementation is that the activity for "aDegradeModule" could be accessed through its hub. The hub would then tap into the NodeLib. The NodeLib could notify the hub anytime there is a message going to myPatcher/aDegradeModule/* .

While I could be wrong, this seems much more straight-forward to me. I probably misunderstand something, but I don't know why the parameters need be involved.

Is it possible to just tap into the NodeLib and listen to it at any point on the tree?

best, Tim

from http://redmine.jamoma.org/projects/modular/wiki/Jamoma_07