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

[Frank Barknecht]

Hallo,
Roman Haefeli hat gesagt: // Roman Haefeli wrote:

> why not using an abstraction for global states in order to access them
> locally?
>
> [inlet] [receive pd]
> |      /
> [b ] [route dsp]
> |   /
> [f ]
> |
> [outlet] 
> 
> or am i missing the point here? (sorry, if so. i didn't read the full
> thread)

Why force people to use such abstractions? 

> personally, i don't see the main problem in the state being global,
> since turning global values in only locally accessible values is simple.
> the major problem i have with the [r pd] approach is, that there is no
> way to know the state without having changed the state at least once,
> which is paradox, since if you deliberately change something, you don't
> need to request it's current state anymore.

We're indeed talking about getting info about the current state, not
just about state changes. Hans' idea was to use this: 

  |dsp( <- Note: There's no 0 or 1 here!
  |
  [s pd]

to receive the properties of the dsp state on the receiver bound to "pd"
like this:

  [r pd]
  |
  [route dsp]
  |
  [route samplerate blocksize ...] <- for example.

That is, to extend the current "dsp" message of the "pd"-binding with
status retrieval messages.

I think this is not a good approach. Reason:

While changes to the dsp state happen only occasionally and probably are
of interest to all [r pd] receivers, just taking a peek at the current
dsp status to get blocksize or samplerate may happen quite often. 

But if some filter abstraction needs to read the current samplerate, it
is completely unnecessary to notifiy everything else about this. It is
not only completely unnecessary, its side effect would be, that you need
to guard every [r pd] receiver who should not propagate the status
message with [spigot] or special abstractions like your sketch above. 

Ciao
-- 
Frank Barknecht