Hans-Christoph Steiner wrote:
Personally, I don't see a problem with a global receive for a global state. To me, I think that a dataflow program should be set up to
first off, the initial thread was _not_ about global states. - the blocksize is _local_ (unless you want to query the dac-blocksize which is currently hardcoded to 64 samples) - the samplerate we are interested in is _local_ (the global samplerate can be queried via [samplerate~] - overlap-factor is _local_ (ok, i think you get the picture by now)
querying with [; pd-mypatch.pd dsp( or listening via [r pd-mypatch.pd] works fine if all your abstractions have the same blocksize / overlapfactor / samplerate. however, in this case the query result may be no so interesting...the fun only starts when things begin to differ.
so we have to do it more patch-local, probably by [namecanvas] (wasn't that "deprecated"?) - but what's the difference to [dspinfo~] then - apart from the fact that [dspinfo~] is pretty selfexplanatory (just like [samplerate~])...?
in theory, everything could be done using a query/response mechanism; they call this sql. (could be an interesting cml)
fgamsrd IOhannes