Hi,
when using an [+] object I find it most of the time counterproductive
that the right inlet is considered cold.
for example, if I want to use 2 different controls for 'coarse' and
'fine' tuning parameters it is necessary to add them together.
however when changing 'fine' value which for instance is connected to
the right inlet the new value is only taken into consideration once
the 'coarse' value connected to the left inlet is changed as well.
the only workaround I found was to [bang] the hot inlet form the cold
one as illustrated in the attached patch. but I don't find that elegant.
is there a better way to make both inlets hot?
Best Jurgen
no, they are hot and cold for a very good reason...the order of dataflow is often vital to how a patch runs.
it's not too hard to turn a cold inlet into a hot one though. [t b f] usually does it.
see attached patch
Hi,
look at the attachment, using [t b f] should be the easiest way doing it. Using no graphical bangs is also better for performance. The trigger object [t b f] or [trigger bang float] makes clear in which order your events are sent, contrary to the two graphical connections where you afterwards can't see the order in which they where patched. Have a look at help patch for more info...
PS: holding shift while modifying values in numboxes you also get (a predefined) fine tuning.
regards, Martin
Lao Yu wrote:
Hi,
when using an [+] object I find it most of the time counterproductive that the right inlet is considered cold.
for example, if I want to use 2 different controls for 'coarse' and 'fine' tuning parameters it is necessary to add them together. however when changing 'fine' value which for instance is connected to the right inlet the new value is only taken into consideration once the 'coarse' value connected to the left inlet is changed as well.
the only workaround I found was to [bang] the hot inlet form the cold one as illustrated in the attached patch. but I don't find that elegant.
is there a better way to make both inlets hot?
Best Jurgen
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
#N canvas 691 436 552 321 10; #X obj 177 160 +; #X floatatom 120 74 5 0 0 0 - - -; #X floatatom 187 62 5 0 0 0 - - -; #X obj 186 112 t b f; #X text 236 111 trigger sequences from right to left; #X floatatom 163 228 5 0 0 0 - - -; #X obj 188 90 / 10; #X connect 0 0 5 0; #X connect 1 0 0 0; #X connect 2 0 6 0; #X connect 3 0 0 0; #X connect 3 1 0 1; #X connect 6 0 3 0;
Hi Jurgen,
understanding hot and cold is essential to understanding the way Pd handles order of operations, so it's best to learn it right from the start. In your example, it is unclear/ambiguous whether the fine number gets sent to the add before or after the bang gets sent to the coarse number. (This is determined by creation order, which cannot be seen on the screen). This can lead to errors later.
The preferred way is to use [t b f], where the [f] outlet is connected to the cold side of the [+], and the [b] outlet is connected to the hot side of the [+]. A bang to the hot side of many objects tells it to do the same operation again with the information contained in the inlets. In this case, the hot inlet will have the previous number stored in it as well. All this is explained in Miller's HTML manual, the "control" documentation patches, and also in the in-progress Pd FLOSS Manual: http://en.flossmanuals.net/puredata
best! Derek
Lao Yu wrote:
Hi,
when using an [+] object I find it most of the time counterproductive that the right inlet is considered cold.
for example, if I want to use 2 different controls for 'coarse' and 'fine' tuning parameters it is necessary to add them together. however when changing 'fine' value which for instance is connected to the right inlet the new value is only taken into consideration once the 'coarse' value connected to the left inlet is changed as well.
the only workaround I found was to [bang] the hot inlet form the cold one as illustrated in the attached patch. but I don't find that elegant.
is there a better way to make both inlets hot?
Derek,
I went through M-P's patches, trust me. He talks a lot about looping
etc but not about trivial stuff that I mentioned.
I knew flossmanuals but the dat flow tut escaped my notice. there is
a very suitable example that is practical to me. Thank you very much
for pointing me there.
For the sake of replying one rather angry reaction (I guess he won't
read) - when incrementing a coarse / fine value of for instance
tuning it is totally irrelevant which parameter is changed first. the
point is to output a new value whenever either is changed. So
pointing out that the hot/cold logic is essential to pd's workings
doesn't even remotely give me a clue.
But that's ok, nobody is perfect.
Thanks again for the patient posters, I appreciate a lot.
Jurgen
On Nov 21, 2008, at 7:50 PM, Derek Holzer wrote:
Hi Jurgen,
understanding hot and cold is essential to understanding the way Pd handles order of operations, so it's best to learn it right from the start. In your example, it is unclear/ambiguous whether the fine
number gets sent to the add before or after the bang gets sent to the coarse number. (This is determined by creation order, which cannot be seen on the screen). This can lead to errors later.The preferred way is to use [t b f], where the [f] outlet is connected to the cold side of the [+], and the [b] outlet is connected to the
hot side of the [+]. A bang to the hot side of many objects tells it to do the same operation again with the information contained in the inlets. In this case, the hot inlet will have the previous number stored in it as well. All this is explained in Miller's HTML manual, the "control" documentation patches, and also in the in-progress Pd FLOSS Manual: http://en.flossmanuals.net/puredatabest! Derek
Lao Yu wrote:
Hi,
when using an [+] object I find it most of the time counterproductive that the right inlet is considered cold.
for example, if I want to use 2 different controls for 'coarse' and 'fine' tuning parameters it is necessary to add them together.
however when changing 'fine' value which for instance is connected to the
right inlet the new value is only taken into consideration once the
'coarse' value connected to the left inlet is changed as well.the only workaround I found was to [bang] the hot inlet form the cold one as illustrated in the attached patch. but I don't find that
elegant.is there a better way to make both inlets hot?
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 7: "Accept advice"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Lao Yu wrote:
For the sake of replying one rather angry reaction (I guess he won't
read)
whomever you are referring to here - it's very much likely that they will read your post.
you seem to be used to hostile mailinglists. even though i (personally) am often grumpy, i would not consider the Pd-list to be hostile in general.
- when incrementing a coarse / fine value of for instance
tuning it is totally irrelevant which parameter is changed first. the
this is not the point. the point is that if you do have control over execution via a hot/cold inlet model, you can very easily write all-hot objects that circumvent this. (as without doubt the numerous patches sent in this thread have demonstrated; i haven't had a look into them). on the other hand, it is impossible to build a hot/cold object if your system provides only all-hot objects.
point is to output a new value whenever either is changed. So
pointing out that the hot/cold logic is essential to pd's workings
doesn't even remotely give me a clue.
nobody said that hot/cold logic is essential to Pd's workings. what has been said is that understanding hot/cold logic is essential to work with Pd. since this was your problem, i don't know what other clue one could have given to you.
fgmasdr IOhannes
Who's angry? Arguing with strangers on the internet is about the biggest waste of time I can imagine! ;-)
In any case, [trigger] is the object you should investigate more, as it makes the situation you want possible: change on both sides of the [+] creates output.
See attached.
best! d.
Lao Yu wrote:
Derek,
I went through M-P's patches, trust me. He talks a lot about looping etc but not about trivial stuff that I mentioned.
I knew flossmanuals but the dat flow tut escaped my notice. there is a very suitable example that is practical to me. Thank you very much for pointing me there.
For the sake of replying one rather angry reaction (I guess he won't read) - when incrementing a coarse / fine value of for instance tuning it is totally irrelevant which parameter is changed first. the point is to output a new value whenever either is changed. So pointing out that the hot/cold logic is essential to pd's workings doesn't even remotely give me a clue.
But that's ok, nobody is perfect.
Thanks again for the patient posters, I appreciate a lot.
Jurgen
On Nov 21, 2008, at 7:50 PM, Derek Holzer wrote:
Hi Jurgen,
understanding hot and cold is essential to understanding the way Pd handles order of operations, so it's best to learn it right from the start. In your example, it is unclear/ambiguous whether the fine number gets sent to the add before or after the bang gets sent to the coarse number. (This is determined by creation order, which cannot be seen on the screen). This can lead to errors later.
The preferred way is to use [t b f], where the [f] outlet is connected to the cold side of the [+], and the [b] outlet is connected to the hot side of the [+]. A bang to the hot side of many objects tells it to do the same operation again with the information contained in the inlets. In this case, the hot inlet will have the previous number stored in it as well. All this is explained in Miller's HTML manual, the "control" documentation patches, and also in the in-progress Pd FLOSS Manual: http://en.flossmanuals.net/puredata
best! Derek
Lao Yu wrote:
Hi,
when using an [+] object I find it most of the time counterproductive that the right inlet is considered cold.
for example, if I want to use 2 different controls for 'coarse' and 'fine' tuning parameters it is necessary to add them together. however when changing 'fine' value which for instance is connected to the right inlet the new value is only taken into consideration once the 'coarse' value connected to the left inlet is changed as well.
the only workaround I found was to [bang] the hot inlet form the cold one as illustrated in the attached patch. but I don't find that elegant.
is there a better way to make both inlets hot?
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/macumbista ---Oblique Strategy # 7: "Accept advice"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I agree about the [trigger] object - from the demo patches the
significance didn't get through to me.
about the angriness, it is certainly my perception that tricked me -
communicating in the writing using just a few words skips the
niceness that we express with body language etc. this group is
incredible helpful - I just need to count my posts and constructive
replies received.
Best Jurgen
On Nov 22, 2008, at 7:21 PM, Derek Holzer wrote:
Who's angry? Arguing with strangers on the internet is about the
biggest waste of time I can imagine! ;-)In any case, [trigger] is the object you should investigate more,
as it makes the situation you want possible: change on both sides
of the [+] creates output.See attached.
best! d.
Lao Yu wrote:
Derek, I went through M-P's patches, trust me. He talks a lot about
looping etc but not about trivial stuff that I mentioned. I knew flossmanuals but the dat flow tut escaped my notice. there
is a very suitable example that is practical to me. Thank you very
much for pointing me there. For the sake of replying one rather angry reaction (I guess he
won't read) - when incrementing a coarse / fine value of for
instance tuning it is totally irrelevant which parameter is
changed first. the point is to output a new value whenever either
is changed. So pointing out that the hot/cold logic is essential
to pd's workings doesn't even remotely give me a clue. But that's ok, nobody is perfect. Thanks again for the patient posters, I appreciate a lot. Jurgen On Nov 21, 2008, at 7:50 PM, Derek Holzer wrote:Hi Jurgen,
understanding hot and cold is essential to understanding the way Pd handles order of operations, so it's best to learn it right from the start. In your example, it is unclear/ambiguous whether the fine
number gets sent to the add before or after the bang gets sent to the
coarse number. (This is determined by creation order, which cannot be
seen on the screen). This can lead to errors later.The preferred way is to use [t b f], where the [f] outlet is
connected to the cold side of the [+], and the [b] outlet is connected to
the hot side of the [+]. A bang to the hot side of many objects tells it
to do the same operation again with the information contained in the
inlets. In this case, the hot inlet will have the previous number stored
in it as well. All this is explained in Miller's HTML manual, the
"control" documentation patches, and also in the in-progress Pd FLOSS Manual: http://en.flossmanuals.net/puredatabest! Derek
Lao Yu wrote:
Hi,
when using an [+] object I find it most of the time
counterproductive that the right inlet is considered cold.for example, if I want to use 2 different controls for 'coarse' and 'fine' tuning parameters it is necessary to add them together.
however when changing 'fine' value which for instance is connected to
the right inlet the new value is only taken into consideration once the
'coarse' value connected to the left inlet is changed as well.the only workaround I found was to [bang] the hot inlet form the
cold one as illustrated in the attached patch. but I don't find that
elegant.is there a better way to make both inlets hot?
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 7: "Accept advice"
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 89: "Imagine the piece as a set of disconnected events" #N canvas 249 81 755 492 10; #X floatatom 44 142 5 0 0 0 - - -; #X floatatom 86 142 5 0 0 0 - - -; #X floatatom 44 203 5 0 0 0 - - -; #X obj 44 174 +; #X text 41 117 "hot"; #X text 81 117 "cold"; #X floatatom 144 142 5 0 0 0 - - -; #X floatatom 186 142 5 0 0 0 - - -; #X floatatom 144 243 5 0 0 0 - - -; #X obj 144 214 +; #X text 141 117 "hot"; #X text 181 117 "cold"; #X obj 186 169 trigger bang float; #X obj 45 343 trigger bang float; #X text 44 374 can be abbreviated with; #X obj 46 405 t b f; #X text 332 301 [trigger] can send an arbitrary number of things out: ; #X obj 335 343 trigger bang float anything bang bang float bang float ; #X obj 336 405 t b f a b b f b f; #X text 335 374 or:; #X text 174 452 derek@umatic.nl; #X text 330 167 [trigger] outputs according to its creation arguments in right to left order. In this case , when it receives input , it will first send out a "float" (i.e. a floating point number) from its right outlet , then it will send a "bang" out its left outlet.; #X text 26 20 The object [trigger] can be used to change the order of operations in a patch by sending a message "bang" to the "hot"
inlet of an object. "Bang" means "do it now!" , and will cause the object to output.; #X connect 0 0 3 0; #X connect 1 0 3 1; #X connect 3 0 2 0; #X connect 6 0 9 0; #X connect 7 0 12 0; #X connect 9 0 8 0; #X connect 12 0 9 0; #X connect 12 1 9 1;
-
Derek Holzer -
hard off -
IOhannes m zmoelnig -
Lao Yu -
Martin Schied