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
Le 2012-03-01 à 12:02:00, Jonathan Wilkes a écrit :
And is it possible to make local symbol tables that are separate from the global symbol table?
Look into my proposals that I wrote back in 2006 or so, probably on pd-dev. But I don't think I got any replies on them at all.
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?
DSP graphs allow dsp-methods to call dsp_add with all sorts of very context-specific arguments such as direct pointers to the internals of tables and of delwrite~ and such. To make those into context-independent things would require a lot of work. But you don't necessarily need to do that if all you want is just to avoid most of the recompilation whenever you add or remove a few abstraction instances at any given moment.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
----- Original Message -----
From: Mathieu Bouchard matju@artengine.ca To: Jonathan Wilkes jancsika@yahoo.com Cc: pd-list pd-list@iem.at Sent: Thursday, March 1, 2012 5:11 PM Subject: Re: [PD] dsp graph question
Le 2012-03-01 à 12:02:00, Jonathan Wilkes a écrit :
And is it possible to make local symbol tables that are separate from the
global symbol table?
Look into my proposals that I wrote back in 2006 or so, probably on pd-dev. But I don't think I got any replies on them at all.
Oh interesting-- there's an entire thread on namespaces for send/receive. Never noticed that before.
From 2006 all I see is some stuff about deallocatable symbols-- is that what you're referring to?
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?
DSP graphs allow dsp-methods to call dsp_add with all sorts of very context-specific arguments such as direct pointers to the internals of tables and of delwrite~ and such. To make those into context-independent things would require a lot of work. But you don't necessarily need to do that if all you want is just to avoid most of the recompilation whenever you add or remove a few abstraction instances at any given moment.
Yes that's pretty much all I want to do.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
Le 2012-03-01 à 14:33:00, Jonathan Wilkes a écrit :
Oh interesting-- there's an entire thread on namespaces for send/receive. Never noticed that before.
From 2006 all I see is some stuff about deallocatable symbols-- is that what you're referring to?
That's an approximate year. There are probably several threads on the topic(s). I remember writing about deallocatable symbols in more recent years, but the thing that I think was in 2006, is about splitting the receive-table away from the symbol-table so that receive-symbols could become local : have a global t_symbol * but have a local s_thing. Then receive-symbols wouldn't necessarily be symbols anymore, they'd be pairs of one $0 and one t_symbol *... I'm reinventing this in my head as I write it, maybe.
It's possible to fit a very large $0 in a_type because most values of t_atomtype aren't taken. For example, all negative values of t_atomtype could be reserved to mean the local-symbol where $0 = -a_type.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
On Thu, Mar 1, 2012 at 2:02 PM, Jonathan Wilkes jancsika@yahoo.com wrote:
Not sure if this makes sense, but here goes:
Can a Pd dsp graph be nested inside a Pd dsp graph?
This occurs whenever you make a sub-canvas. For each canvas, there is a new dspcontext struct created. The canvas->dsp graph process creates a nested dsp graph, delimited from its parent by block prolog/epilog (when re-blocked from parent) and inlet/outlet prolog/epilog code.
It may be possible to think of just any sub-graph as being a nested dsp graph, for that matter. But yes, I think it's clear that nested dsp graphs can be programmed and used.
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]?
Not possible yet! Every time you add/delete a connection (and some other conditions I'm not sure of), the dsp stops, rebuilds its entire graph, and re-starts. Just set ugen_loud to 1 and re-compile--you will be greeted with a representation of Pd building your dsp graph every time you make changes to it.
Comments in d_ugen.c have said--for a long time--that this is not a preferred way of doing things. It's just the way things are done now.
I'm obviously still very sketchy on signal graph compilation, so links to any documentation or resources are appreciated!
-Jonathan
I wouldn't want you to have to learn all the hard lessons about how Pd does it's internal management of dsp chains and the like, but--if it's interesting to you and you might want to become a developer, I recommend reading d_ugen.c, g_canvas.c, g_io.c, and d_resample.c. It's all in there.
Feel free to ask any other questions.
Chuck
-
Charles Henry -
Jonathan Wilkes -
Mathieu Bouchard