I just had a thought, what about adding an outlet to [block~] that will output the block size as a float when [block~] is banged? I can't think of any other way to query what the current block size is, and it would be useful sometimes.
.hc
------------------------------------------------------------------------ ----
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
Hans-Christoph Steiner wrote:
I just had a thought, what about adding an outlet to [block~] that will output the block size as a float when [block~] is banged? I can't think of any other way to query what the current block size is, and it would be useful sometimes.
banging [switch~] allows you to do dsp processing on demand. since [block~] and [switch~] are so closely related (on the Pd side they are very similar (with [switch~] being a better [block~]); on the C side they are the basically same) i would suggest to do any additional overloading.
i agree however, that it would be nice to get the current blocksize, overlap and oversample from within Pd.
gfmdasrt IOhannes
On May 23, 2008, at 9:00 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I just had a thought, what about adding an outlet to [block~] that will output the block size as a float when [block~] is banged? I can't think of any other way to query what the current block size is, and it would be useful sometimes.
banging [switch~] allows you to do dsp processing on demand. since [block~] and [switch~] are so closely related (on the Pd side they are very similar (with [switch~] being a better [block~]); on the C side they are the basically same) i would suggest to do any additional overloading.
i agree however, that it would be nice to get the current blocksize, overlap and oversample from within Pd.
It seems that adding an outlet to block~/switch~ seems to be the most obvious interface for getting the data. Perhaps just a message then?
.hc
gfmdasrt IOhannes
------------------------------------------------------------------------ ----
Access to computers should be unlimited and total. - the hacker ethic
Hans-Christoph Steiner wrote:
On May 23, 2008, at 9:00 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I just had a thought, what about adding an outlet to [block~] that will output the block size as a float when [block~] is banged? I can't think of any other way to query what the current block size is, and it would be useful sometimes.
banging [switch~] allows you to do dsp processing on demand. since [block~] and [switch~] are so closely related (on the Pd side they are very similar (with [switch~] being a better [block~]); on the C side they are the basically same) i would suggest to do any additional overloading.
i agree however, that it would be nice to get the current blocksize, overlap and oversample from within Pd.
It seems that adding an outlet to block~/switch~ seems to be the most obvious interface for getting the data. Perhaps just a message then?
I'd personally prefer new objects:
[blocksize~] [overlap~] [oversampling~]
to match the existing:
[samplerate~]
Rationale:
You might want to get the blocksize etc in more than one place. It might be inconvenient to patch cables from the [block~]. Plus the reasons that IOhannes mentioned.
Thanks,
Claude
On May 23, 2008, at 12:07 PM, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
On May 23, 2008, at 9:00 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I just had a thought, what about adding an outlet to [block~] that will output the block size as a float when [block~] is banged? I can't think of any other way to query what the current block size is, and it would be useful sometimes.
banging [switch~] allows you to do dsp processing on demand. since [block~] and [switch~] are so closely related (on the Pd side they are very similar (with [switch~] being a better [block~]); on the C side they are the basically same) i would suggest to do any additional overloading.
i agree however, that it would be nice to get the current blocksize, overlap and oversample from within Pd.
It seems that adding an outlet to block~/switch~ seems to be the most obvious interface for getting the data. Perhaps just a message then?
I'd personally prefer new objects:
[blocksize~] [overlap~] [oversampling~]
to match the existing:
[samplerate~]
Rationale:
You might want to get the blocksize etc in more than one place. It might be inconvenient to patch cables from the [block~]. Plus the reasons that IOhannes mentioned.
That works for me.
.hc
Thanks,
Claude
------------------------------------------------------------------------ ----
There is no way to peace, peace is the way. -A.J. Muste
Or, how about three extra outlets to samplerate~ (so as not to have to add more to the top-level namespace)
cheers Miller
On Fri, May 23, 2008 at 11:07:18AM +0100, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
On May 23, 2008, at 9:00 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I just had a thought, what about adding an outlet to [block~] that will output the block size as a float when [block~] is banged? I can't think of any other way to query what the current block size is, and it would be useful sometimes.
banging [switch~] allows you to do dsp processing on demand. since [block~] and [switch~] are so closely related (on the Pd side they are very similar (with [switch~] being a better [block~]); on the C side they are the basically same) i would suggest to do any additional overloading.
i agree however, that it would be nice to get the current blocksize, overlap and oversample from within Pd.
It seems that adding an outlet to block~/switch~ seems to be the most obvious interface for getting the data. Perhaps just a message then?
I'd personally prefer new objects:
[blocksize~] [overlap~] [oversampling~]
to match the existing:
[samplerate~]
Rationale:
You might want to get the blocksize etc in more than one place. It might be inconvenient to patch cables from the [block~]. Plus the reasons that IOhannes mentioned.
Thanks,
Claude
http://claudiusmaximus.goto10.org
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hmm, while the idea of a single object is good, I think the object is clearly called "samplerate" so getting the rest of that info from it doesn't really make sense.
.hc
On May 23, 2008, at 9:48 PM, Miller Puckette wrote:
Or, how about three extra outlets to samplerate~ (so as not to have to add more to the top-level namespace)
cheers Miller
On Fri, May 23, 2008 at 11:07:18AM +0100, Claude Heiland-Allen wrote:
Hans-Christoph Steiner wrote:
On May 23, 2008, at 9:00 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I just had a thought, what about adding an outlet to [block~] that will output the block size as a float when [block~] is banged? I can't think of any other way to query what the current block size is, and it would be useful sometimes.
banging [switch~] allows you to do dsp processing on demand. since [block~] and [switch~] are so closely related (on the Pd side they are very similar (with [switch~] being a better [block~]); on the C side they are the basically same) i would suggest to do any additional overloading.
i agree however, that it would be nice to get the current blocksize, overlap and oversample from within Pd.
It seems that adding an outlet to block~/switch~ seems to be the most obvious interface for getting the data. Perhaps just a message then?
I'd personally prefer new objects:
[blocksize~] [overlap~] [oversampling~]
to match the existing:
[samplerate~]
Rationale:
You might want to get the blocksize etc in more than one place. It might be inconvenient to patch cables from the [block~]. Plus the reasons that IOhannes mentioned.
Thanks,
Claude
http://claudiusmaximus.goto10.org
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
There is no way to peace, peace is the way. -A.J. Muste
Hallo,
On May 23, 2008, at 9:48 PM, Miller Puckette wrote:
Or, how about three extra outlets to samplerate~ (so as not to have to add more to the top-level namespace)
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, while the idea of a single object is good, I think the object is clearly called "samplerate" so getting the rest of that info from it doesn't really make sense.
I agree with Hans (except for the top-posting reply style) and would like to add that instead of separate outlets, maybe a single outlet would be better, that spits out messages prefixed with "blocksize N", "overlap M", "samplerate O" would be better as it could be extended with other messages later. Notice that I included "samplerate" here: such an object could be a general info object for the dsp state ([dspinfo~]?)
Ciao
Quoting Frank Barknecht fbar@footils.org:
with other messages later. Notice that I included "samplerate" here: such an object could be a general info object for the dsp state ([dspinfo~]?)
i think it is a good idea, but some remarks which nobody has mentioned yet:
afair [samplerate~] will give you the system-samplerate which might be different from the patch's samplerate. that's one of the reasons why i don't like miller's suggestion.
[dspinfo~] sounds very generic too: i would expect to give me information about the system's dsp state rather than a patch's state.
this might be nitpicking.
anyhow, it would be nice to have an object telling me whether dsp has been turned on (or off!) in a certain sub-patch (as well as giving more info on this). i think the [r pd][route dsp] approach is a kludge...
mfgasdr IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On May 25, 2008, at 12:31 PM, zmoelnig@iem.at wrote:
Quoting Frank Barknecht fbar@footils.org:
with other messages later. Notice that I included "samplerate" here: such an object could be a general info object for the dsp state ([dspinfo~]?)
i think it is a good idea, but some remarks which nobody has mentioned yet:
afair [samplerate~] will give you the system-samplerate which might be different from the patch's samplerate. that's one of the reasons why i don't like miller's suggestion.
[dspinfo~] sounds very generic too: i would expect to give me information about the system's dsp state rather than a patch's state.
this might be nitpicking.
anyhow, it would be nice to have an object telling me whether dsp has been turned on (or off!) in a certain sub-patch (as well as giving more info on this). i think the [r pd][route dsp] approach is a kludge...
Maybe this:
[dsp( | [s pd]
[r pd] | [route dsp]
A similar thing could be used for getting the block size, etc. from the patch, so you could send [; pd samplerate( to get the main samplerate, then [; pd-mypatch.pd samplerate( to get the current patch's samplerate, etc.
.hc
mfgasdr IOhannes
This message was sent using IMP, the Internet Messaging Program.
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie
Quoting Hans-Christoph Steiner hans@eds.org:
i think the [r pd][route dsp] approach is a kludge...
Maybe this:
[dsp( | [s pd]
[r pd] | [route dsp]
exactly this is the kind of "kludge" i am talking about. i hope that "kludge" means something really bad and ugly, as this is how i use this word here.
mfgasd.r IOhannes
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On May 25, 2008, at 5:29 PM, zmoelnig@iem.at wrote:
Quoting Hans-Christoph Steiner hans@eds.org:
i think the [r pd][route dsp] approach is a kludge...
Maybe this:
[dsp( | [s pd]
[r pd] | [route dsp]
exactly this is the kind of "kludge" i am talking about. i hope that "kludge" means something really bad and ugly, as this is how i use this word here.
You mean it's a kludge if there isn't a special object for this? I think conceptually, it is like sending to the pd "object" itself. I mean that if you send [; pd dsp( then you'll get a reply with the current state. The only problem there is that [; pd dsp( could be interpreted as [;pd dsp 0( if there is no different between lack of an argument and an argument initialized to 0.
.hc
mfgasd.r IOhannes
This message was sent using IMP, the Internet Messaging Program.
------------------------------------------------------------------------ ----
Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
On May 25, 2008, at 5:29 PM, zmoelnig@iem.at wrote:
Quoting Hans-Christoph Steiner hans@eds.org:
i think the [r pd][route dsp] approach is a kludge...
Maybe this:
[dsp( | [s pd]
[r pd] | [route dsp]
exactly this is the kind of "kludge" i am talking about. i hope that "kludge" means something really bad and ugly, as this is how i use this word here.
You mean it's a kludge if there isn't a special object for this?
The real problem is that it's global: I may not want all my [r pd] receivers to get activated every time something somewhere queries the state of DSP.
Ciao
Frank Barknecht wrote:
exactly this is the kind of "kludge" i am talking about. i hope that "kludge" means something really bad and ugly, as this is how i use this word here.
You mean it's a kludge if there isn't a special object for this?
The real problem is that it's global: I may not want all my [r pd] receivers to get activated every time something somewhere queries the state of DSP.
yep. a dedicated object does not have this problems.
fgamsdr IOhannes
On May 26, 2008, at 9:09 AM, IOhannes m zmoelnig wrote:
Frank Barknecht wrote:
exactly this is the kind of "kludge" i am talking about. i hope that "kludge" means something really bad and ugly, as this is how i use this word here.
You mean it's a kludge if there isn't a special object for this?
The real problem is that it's global: I may not want all my [r pd] receivers to get activated every time something somewhere queries the state of DSP.
yep. a dedicated object does not have this problems.
Hmm, for DSP state, that's global, so using a global receive symbol makes sense, IMHO. For other things, perhaps you could use the patch receive name, is [receive pd-mypatch.pd].
.hc
fgamsdr IOhannes
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, for DSP state, that's global, so using a global receive symbol makes sense, IMHO.
The problem is not, that the state is global, but that with the send/receive approach there would only be a global way to access the state, but no locally restricted way.
Take for example [samplerate~]: The (global) samplerate also is a global property, but with [samplerate~] I can access this information locally, i.e. it will only be sent to the outlet of the [samplerate~] object that gets a bang. Imagine if instead of [samplerate~] there was only a global [s pd-samplerate] and [r pd-samplerate] pair available. Everytime, you'd want to get the samplerate, you would also activate all other places where you have a [r pd-samplerate]!
Chuck's workaround of [spigot]ting all receivers of course is even more of a kludge and may in fact be proof of a lack of needed functionality.
Ciao
On Mon, 2008-05-26 at 21:40 +0200, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, for DSP state, that's global, so using a global receive symbol makes sense, IMHO.
The problem is not, that the state is global, but that with the send/receive approach there would only be a global way to access the state, but no locally restricted way.
Take for example [samplerate~]: The (global) samplerate also is a global property, but with [samplerate~] I can access this information locally, i.e. it will only be sent to the outlet of the [samplerate~] object that gets a bang. Imagine if instead of [samplerate~] there was only a global [s pd-samplerate] and [r pd-samplerate] pair available. Everytime, you'd want to get the samplerate, you would also activate all other places where you have a [r pd-samplerate]!
Chuck's workaround of [spigot]ting all receivers of course is even more of a kludge and may in fact be proof of a lack of needed functionality.
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)
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.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
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
On May 26, 2008, at 9:54 PM, Roman Haefeli wrote:
On Mon, 2008-05-26 at 21:40 +0200, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Hmm, for DSP state, that's global, so using a global receive symbol makes sense, IMHO.
The problem is not, that the state is global, but that with the send/receive approach there would only be a global way to access the state, but no locally restricted way.
Take for example [samplerate~]: The (global) samplerate also is a global property, but with [samplerate~] I can access this information locally, i.e. it will only be sent to the outlet of the [samplerate~] object that gets a bang. Imagine if instead of [samplerate~] there was only a global [s pd-samplerate] and [r pd-samplerate] pair available. Everytime, you'd want to get the samplerate, you would also activate all other places where you have a [r pd-samplerate]!
Chuck's workaround of [spigot]ting all receivers of course is even more of a kludge and may in fact be proof of a lack of needed functionality.
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)
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.
The one thing lacking there is the ability to actively query the state, rather than passively tracking it.
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 respond to changes in state, so a change of state in a global thing should be reflected globally. Anyone have an example of where this wouldn't make sense?
.hc
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
Hallo, Hans-Christoph Steiner hat gesagt: // 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 respond to changes in state, so a change of state in a global thing should be reflected globally.
I thought this thread was about state *queries* (see subject) not state changes?!? Those two are different.
Ciao
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
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
-
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Miller Puckette -
Roman Haefeli -
zmoelnig＠iem.at