Not sure if this makes sense, but here goes: Can a Pd dsp graph be nested inside a Pd dsp graph? And is it possible to make
local symbol tables that are separate from the global symbol table? For example-- let's imagine that [struct] has a signal inlet and a signal outlet, and has a field "canvas foo bar" which, when you create a scalar of that struct one of its "data" is a glist "foo" that takes abstraction (or subpatch) "bar" as its template. Now, for each of these scalars you instantiate you have a glist associated with it, inside which there are objects that allow access to any of the other field values for this scalar (float x, float y, etc.). Additionally, let's say each "foo" glist has one [inlet~] that takes its incoming signal from whatever is connected to the corresponding [struct] signal inlet, and one [outlet~] which sends to the [struct] signal outlet. The one caveat is that all global symbolic sends/receives inside the scalar glists are local to \ this scalar class-- there is no way to access anything in the parent patch except through the xlets of [struct]. If this were the case, then would it be possible created/destroy any of these scalars at will and only have to rebuild this "nested" dsp graph that is associated with it's [struct]? Everything would still be deterministic-- that is, all the signal objects inside these scalars would get computed before [struct] sends its output to the next signal object. But since everything inside the scalar glists is guaranteed to only interact with the other scalars (or sum to the [struct] signal outlet) it wouldn't be necessary to rebuild the parent graph, would it? Additionally, if an array of scalars only send the signal to the [struct] signal outlet and don't interact with each other (through [send~], [throw~], [etc.~]), could one could use [setsize] to to do massive polyphony without having to rebuild the entire graph? I'm obviously still very sketchy on signal graph compilation, so links to any documentation or resources are appreciated! -Jonathan
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
