Hallo, IOhannes m zmoelnig hat gesagt: // IOhannes m zmoelnig wrote:
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)
Even for global dsp state properties, only offering a global receiver for queries(!, not for state changes) is bad. As Hans asked for examples: Assume I do a [blockdelay~] abstraction, similar to [z~], but it specifies its [delread~] length in blocks. For this I need to query the blocksize and the samplerate. A typical approach would be to loadbang [samplerate~] and a hypothetical [blocksize~] object to calculate the duration of a block in milliseconds, then set the [delread~] with that. Nice and easy.
Now if blocksize and samplerate were only accessible through a global [s/r pd] send/receive pair, the [blockdelay~] abstraction would have to send a message to the global "pd", which would result in a message coming out of *all* [r pd] receivers in all instances of [blockdelay~] and everywhere else. If you don't want that message to trigger your computations again (which would be unnecessary, because you already computed everything with your loadbang), you would need to block the receiver or use cold inlets or whatnot. All of this just because the language designer decided to pollute the global variable namespace without a compelling reason.
Rant off. ;)
Ciao