Hi all,
here on Pd version 0.39-1test1, the value object doesn't share it's value with other value objects of identical name.
Anyone else seen this?
regrds,P
Peter Plessas wrote:
Hi all,
here on Pd version 0.39-1test1, the value object doesn't share it's value with other value objects of identical name.
Anyone else seen this?
no never, though i admit i haven't tried 0.39-1test1
however i can confirm that it works on 0.39-0, 0.39-2 and 0.40-0test01 (current CVS).
do you have any good reason to stick to an outdated test-release?
fmad.r IOhannes
IOhannes m zmoelnig wrote:
Peter Plessas wrote:
Hi all,
here on Pd version 0.39-1test1, the value object doesn't share it's value with other value objects of identical name.
Anyone else seen this?
no never, though i admit i haven't tried 0.39-1test1
however i can confirm that it works on 0.39-0, 0.39-2 and 0.40-0test01 (current CVS).
do you have any good reason to stick to an outdated test-release?
Yes: Time!
(4 kernels yesterday, lsm and alsa today, now pdp, and all i want is to give a talk about pd tomorrow) :-)
rgrds, Peter
fmad.r IOhannes
Hi again,
same thing here with pd-0.93-2, when i use the help patch for [value] and change/bang the first number box, the second [value] object (with identical name) should output this number right?
Perhaps because i am on powerpc?
chrs,Peter
IOhannes m zmoelnig wrote:
Peter Plessas wrote:
Hi all,
here on Pd version 0.39-1test1, the value object doesn't share it's value with other value objects of identical name.
Anyone else seen this?
no never, though i admit i haven't tried 0.39-1test1
however i can confirm that it works on 0.39-0, 0.39-2 and 0.40-0test01 (current CVS).
do you have any good reason to stick to an outdated test-release?
fmad.r IOhannes
At 19:22 19.05.2006, Peter Plessas wrote:
Hi again,
same thing here with pd-0.93-2, when i use the help patch for [value] and change/bang the first number box, the second [value] object (with identical name) should output this number right?
nope - it's not like send/receive! the second [value] will only output the new value when banged itself.
sven.
quote from the help patch: Notice that the number is not outputted to the outlet; it is merely stored. To retreive the number, send a "bang", like below:
Am 19.05.2006 um 19:22 schrieb Peter Plessas:
Hi again,
same thing here with pd-0.93-2, when i use the help patch for [value] and change/bang the first
number box, the second [value] object (with identical name) should
output this number right?Perhaps because i am on powerpc?
chrs,Peter
IOhannes m zmoelnig wrote:
Peter Plessas wrote:
Hi all,
here on Pd version 0.39-1test1, the value object doesn't share it's value with other value objects of identical name.
Anyone else seen this?
no never, though i admit i haven't tried 0.39-1test1 however i can confirm that it works on 0.39-0, 0.39-2 and
0.40-0test01 (current CVS). do you have any good reason to stick to an outdated test-release? fmad.r IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Hi,
wow, big apologies, just thought i found my first bug in pd, sorry for not reading everything carefully.
lg,P
Max Neupert wrote:
quote from the help patch: Notice that the number is not outputted to the outlet; it is merely stored. To retreive the number, send a "bang", like below:
Am 19.05.2006 um 19:22 schrieb Peter Plessas:
Hi again,
same thing here with pd-0.93-2, when i use the help patch for [value] and change/bang the first
number box, the second [value] object (with identical name) should
output this number right?Perhaps because i am on powerpc?
chrs,Peter
IOhannes m zmoelnig wrote:
Peter Plessas wrote:
Hi all,
here on Pd version 0.39-1test1, the value object doesn't share it's value with other value objects of identical name.
Anyone else seen this?
no never, though i admit i haven't tried 0.39-1test1 however i can confirm that it works on 0.39-0, 0.39-2 and 0.40-0test01 (current CVS). do you have any good reason to stick to an outdated test-release? fmad.r IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
It sounds like you found a bug in the documentation. It would be
great if you updated it to make it more clear and posted it.
.hc
On May 19, 2006, at 7:40 PM, Peter Plessas wrote:
Hi,
wow, big apologies, just thought i found my first bug in pd, sorry for not reading everything carefully.
lg,P
Max Neupert wrote:
quote from the help patch: Notice that the number is not outputted to the outlet; it is merely stored. To retreive the number, send a "bang", like
below: Am 19.05.2006 um 19:22 schrieb Peter Plessas:Hi again,
same thing here with pd-0.93-2, when i use the help patch for [value] and change/bang the first
number box, the second [value] object (with identical name)
should output this number right?Perhaps because i am on powerpc?
chrs,Peter
IOhannes m zmoelnig wrote:
Peter Plessas wrote:
Hi all,
here on Pd version 0.39-1test1, the value object doesn't share
it's value with other value objects of identical name.Anyone else seen this?
no never, though i admit i haven't tried 0.39-1test1 however i can confirm that it works on 0.39-0, 0.39-2 and
0.40-0test01 (current CVS). do you have any good reason to stick to an outdated test-release? fmad.r IOhannes
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/
listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity."
-John Gilmore
On Fri, 19 May 2006, Peter Plessas wrote:
when i use the help patch for [value] and change/bang the first number box, the second [value] object (with identical name) should output this number right?
the second [value] needs to be banged?
i wish it was an option that [value] could auto-produce its value when the shared value is changing, or that it'd output bang on a second outlet whenever the shared value changes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hi,
yes, thought about this behavior as well today :-) and figured that [value] is meant to be combined with a global [r update] which lets all objects output at a change. But somehow this seems complicated, well... On the other side one rarely uses [value] anyway.
lgP
Mathieu Bouchard wrote:
On Fri, 19 May 2006, Peter Plessas wrote:
when i use the help patch for [value] and change/bang the first number box, the second [value] object (with identical name) should output this number right?
the second [value] needs to be banged?
i wish it was an option that [value] could auto-produce its value when the shared value is changing, or that it'd output bang on a second outlet whenever the shared value changes.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Hallo, Peter Plessas hat gesagt: // Peter Plessas wrote:
yes, thought about this behavior as well today :-) and figured that [value] is meant to be combined with a global [r update] which lets all objects output at a change. But somehow this seems complicated, well... On the other side one rarely uses [value] anyway.
[value] is like a detached, remote right inlet of [float] and [value] is like a one-element [table]. However it's not a send/receive. It could be made to act like one with a little abstraction, but then you soon realize, that maybe you don't want to restrict yourself to just sharing one float, but want to store lists and symbols and then you start wrapping [list] with send/receive instead of decorating [value] and then finally you end up with where I also ended with [ssssad]. ;)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Sat, 20 May 2006, Georg Holzmann wrote:
i wish it was an option that [value] could auto-produce its value when the shared value is changing, or that it'd output bang on a second outlet whenever the shared value changes.
for that you can use send/receive pairs ...
now i'm not sure what's the value of [value] anymore... who uses it? why?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Quoting Mathieu Bouchard matju@artengine.ca:
On Sat, 20 May 2006, Georg Holzmann wrote:
i wish it was an option that [value] could auto-produce its value when the shared value is changing, or that it'd output bang on a second outlet whenever the shared value changes.
for that you can use send/receive pairs ...
now i'm not sure what's the value of [value] anymore... who uses it? why?
Perhaps it's value is that it is easier to use then using a
[s val]
[0] [r val] | / [f ]
And it is like a send/recieve all wrapped into one, but I never have used it.
-thewade
On Sat, 20 May 2006, thewade wrote:
Perhaps it's value is that it is easier to use then using a [s val]
[0] [r val] | / [f ]
And it is like a send/recieve all wrapped into one, but I never have used it.
excuse me, what's the [0], how is it used here, and how does it help emulate the behaviour of [value] ?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Quoting Mathieu Bouchard matju@artengine.ca:
On Sat, 20 May 2006, thewade wrote:
Perhaps it's value is that it is easier to use then using a [s val]
[0] [r val] | / [f ]
And it is like a send/recieve all wrapped into one, but I never have used it.
excuse me, what's the [0], how is it used here, and how does it help emulate the behaviour of [value] ?
Sorry, that is the bang gui object, the circle in the square. [value] object seems to be a lot like a [float] tied into a [send] or [recieve]. If you merged [float], [send] and [recieve] you would have [value] is what I was trying to say.
I didn't know that about [line]. Thanks for the info! I always thought [line] was just [line~] except at the control rate. I learn somethin' new every day.
-wade
On Sat, 20 May 2006, thewade wrote:
Sorry, that is the bang gui object, the circle in the square. [value] object seems to be a lot like a [float] tied into a [send] or [recieve]. If you merged [float], [send] and [recieve] you would have [value] is what I was trying to say.
Yes, now that I think of it, you are right.
I didn't know that about [line]. Thanks for the info! I always thought [line] was just [line~] except at the control rate. I learn somethin' new every day.
What's "control rate"? the messagesystem doesn't have a "rate". Its rate is whichever speed individual messages are fired at, which is very much varying, as you can select any rate you want using [metro] or the second argument of [line] or a setting in [gemwin] or whatever else that use "pd clocks" to work. In addition to that, it's possible to remove messages from a stream, duplicate them, etc.
This is what makes the messagesystem completely different from the DSP, in which everything happens at fixed rate (one fixed rate per subpatch).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
"control rate" is the Csound version of block size, but the other way around. Instead of saying how many audio samples per pass, you specify how many control passes per second. Guess that makes it the inverse of block size.
On 5/21/06, Mathieu Bouchard matju@artengine.ca wrote:
On Sat, 20 May 2006, thewade wrote:
Sorry, that is the bang gui object, the circle in the square. [value] object seems to be a lot like a [float] tied into a [send] or [recieve]. If you merged [float], [send] and [recieve] you would have [value] is what I was trying to say.
Yes, now that I think of it, you are right.
I didn't know that about [line]. Thanks for the info! I always thought [line] was just [line~] except at the control rate. I learn somethin' new every day.
What's "control rate"? the messagesystem doesn't have a "rate". Its rate is whichever speed individual messages are fired at, which is very much varying, as you can select any rate you want using [metro] or the second argument of [line] or a setting in [gemwin] or whatever else that use "pd clocks" to work. In addition to that, it's possible to remove messages from a stream, duplicate them, etc.
This is what makes the messagesystem completely different from the DSP, in which everything happens at fixed rate (one fixed rate per subpatch).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 5/21/06, Mathieu Bouchard matju@artengine.ca wrote:
On Sat, 20 May 2006, thewade wrote:
Sorry, that is the bang gui object, the circle in the square. [value] object seems to be a lot like a [float] tied into a [send] or [recieve]. If you merged [float], [send] and [recieve] you would have [value] is what I was trying to say.
Yes, now that I think of it, you are right.
I didn't know that about [line]. Thanks for the info! I always thought [line] was just [line~] except at the control rate. I learn somethin' new every day.
What's "control rate"? the messagesystem doesn't have a "rate". Its rate is whichever speed individual messages are fired at, which is very much varying, as you can select any rate you want using [metro] or the second argument of [line] or a setting in [gemwin] or whatever else that use "pd clocks" to work. In addition to that, it's possible to remove messages from a stream, duplicate them, etc.
This is what makes the messagesystem completely different from the DSP, in which everything happens at fixed rate (one fixed rate per subpatch).
Oh. Nevermind. I never knew they were independent. But still, the audio can't respond to control changes mid-block, so for real-time audio control there is a rate.... right?
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
I never knew they were independent. But still, the audio can't respond to control changes mid-block, so for real-time audio control there is a rate.... right?
The audio *can* respond to control changes mid-block, if the control information is derived from Pd's clock (e.g. with metro, pipe, del) and if the audio object does handle it, which for example [vline~] does.
See attached.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On 5/21/06, Frank Barknecht fbar@footils.org wrote:
Hallo, Chuckk Hubbard hat gesagt: // Chuckk Hubbard wrote:
I never knew they were independent. But still, the audio can't respond to control changes mid-block, so for real-time audio control there is a rate.... right?
The audio *can* respond to control changes mid-block, if the control information is derived from Pd's clock (e.g. with metro, pipe, del) and if the audio object does handle it, which for example [vline~] does.
See attached.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
That makes sense. Very cool that it can do that, I suspected it would. So I guess this attached is about the only way there would be a problem, though an easily solved one.
Quoting Mathieu Bouchard matju@artengine.ca:
On Sat, 20 May 2006, thewade wrote:
I didn't know that about [line]. Thanks for the info! I always thought [line] was just [line~] except at the control rate. I learn somethin' new every day.
What's "control rate"? the messagesystem doesn't have a "rate". Its rate is whichever speed individual messages are fired at, which is very much varying, as you can select any rate you want using [metro] or the second argument of [line] or a setting in [gemwin] or whatever else that use "pd clocks" to work. In addition to that, it's possible to remove messages from a stream, duplicate them, etc.
This is what makes the messagesystem completely different from the DSP, in which everything happens at fixed rate (one fixed rate per subpatch).
I thought the non-tilde objects got computed at the samplerate/blocksize rate. So for example if you used [line] instead of [line~] as a signal rate envelope you get stair-steps in your signal with each stair width being one block size.
[osc~]
| [line]
| / [*~]
|
[dac~]
In Csound this is what the control rate was, and you could set this rate using the ksmps value in your .sco file I think. I bet that if you made the block size 1 sample then [line] and [line~] would behave exactly the same, right? Again I am no expert.
My understanding is that the control rate objects have an upper bound of samplerate/blocksize and has no apparent lower bound, but in actuality are computed at samplerate/blocksize.
I could very easily be wrong.
-thewade
I tried using it before and got warning messages constantly. I got rid of it. It SEEMS like it should be useful, sort of a static variable holder that doesn't trigger unless you want it. But I dont' miss it.
On 5/21/06, Mathieu Bouchard matju@artengine.ca wrote:
On Sat, 20 May 2006, Georg Holzmann wrote:
i wish it was an option that [value] could auto-produce its value when the shared value is changing, or that it'd output bang on a second outlet whenever the shared value changes.
for that you can use send/receive pairs ...
now i'm not sure what's the value of [value] anymore... who uses it? why?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
On Sat, 20 May 2006, Georg Holzmann wrote:
i wish it was an option that [value] could auto-produce its value when the shared value is changing, or that it'd output bang on a second outlet whenever the shared value changes.
for that you can use send/receive pairs ...
now i'm not sure what's the value of [value] anymore... who uses it? why?
As I wrote somewhere else, [value] is like a remote "cold" inlet of [float] and I've seen people to use the cold inlet of [float] sometimes.
I don't use [value] very often, but it is used in the [singleton] patch that is part of the "sssad" state saving system to keep track of the number of instances of another patch, that is autocreated. Here together with the creation of an object's instance with an internal message, a [value] is incremented. As soon as the [value] isn't zero anymore, no new object is created, so we only get a single instance of that new object. (Yes, this doesn't catch deletion of objects, but that's hard anyways because there's no [unloadbang]. But if you have a better singleton with core objects, I'd be happy to replace the sssad-singleton.)
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Mathieu Bouchard wrote:
On Sat, 20 May 2006, Georg Holzmann wrote:
i wish it was an option that [value] could auto-produce its value when the shared value is changing, or that it'd output bang on a second outlet whenever the shared value changes.
for that you can use send/receive pairs ...
now i'm not sure what's the value of [value] anymore... who uses it? why?
honestly, i also use [value] not on a regular basis; however, it is one of the objects that can make patches very elegant (just like the [singleton]) so i am starting to use it more and more.
mfg.asd.r IOhannes
-
Chuckk Hubbard -
Frank Barknecht -
Georg Holzmann -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Mathieu Bouchard -
Max Neupert -
Peter Plessas -
sven -
thewade