[PD-dev] bang [block~] to query current blocksize

Frank Barknecht fbar at footils.org
Tue May 27 10:05:03 CEST 2008


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
-- 
Frank Barknecht




More information about the Pd-dev mailing list