Dear PD-list .
I found that in PD-extended 42.5 - the $1 inside a message is not saving data. Is it a bug ? see patch below.
\\\\\
#N canvas 939 165 700 300 10; #X msg 139 127 0 $1; #X obj 139 175 print; #X floatatom 111 74 5 0 0 0 - - -; #X obj 181 73 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 117 48 1; #X text 183 52 2; #X text 216 112 Why message is not saving data in $1 ?; #X connect 0 0 1 0; #X connect 2 0 0 0; #X connect 3 0 0 0;
\\\\\\\\\
A message box $1 doesn't save the last value like other objects do.
Von: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] Im Auftrag von ?????? ???????? Gesendet: Sonntag, 6. Oktober 2013 13:13 An: pd-list@iem.at Betreff: [PD] $1 inside a message is not saving data ?
Dear PD-list .
I found that in PD-extended 42.5 - the $1 inside a message is not saving data. Is it a bug ? see patch below.
\\\\\ #N canvas 939 165 700 300 10; #X msg 139 127 0 $1; #X obj 139 175 print; #X floatatom 111 74 5 0 0 0 - - -; #X obj 181 73 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 117 48 1; #X text 183 52 2; #X text 216 112 Why message is not saving data in $1 ?; #X connect 0 0 1 0; #X connect 2 0 0 0; #X connect 3 0 0 0;
\\\\\\\\\
Le 06/10/2013 13:12, Фывапр Олджэвич a écrit :
#N canvas 939 165 700 300 10; #X msg 139 127 0 $1; #X obj 139 175 print; #X floatatom 111 74 5 0 0 0 - - -; #X obj 181 73 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 117 48 1; #X text 183 52 2; #X text 216 112 Why message is not saving data in $1 ?; #X connect 0 0 1 0; #X connect 2 0 0 0; #X connect 3 0 0 0;
Hello,
Maybe you are looking for something attached with this patch ? ++
Jack
Yes, absolutelly. Thankyou !
Воскресенье, 6 октября 2013, 14:47 +02:00 от Jack jack@rybn.org:
Le 06/10/2013 13:12, Фывапр Олджэвич a écrit :
#N canvas 939 165 700 300 10; #X msg 139 127 0 $1; #X obj 139 175 print; #X floatatom 111 74 5 0 0 0 - - -; #X obj 181 73 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X text 117 48 1; #X text 183 52 2; #X text 216 112 Why message is not saving data in $1 ?; #X connect 0 0 1 0; #X connect 2 0 0 0; #X connect 3 0 0 0;
Hello,
Maybe you are looking for something attached with this patch ? ++
Jack
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 10/06/13 13:12, Фывапр Олджэвич wrote:
Dear PD-list .
I found that in PD-extended 42.5 - the $1 inside a message is not saving data. Is it a bug ? see patch below.
no, it's expected behaviour and has been like this since forever.
a $arg in a messagebox will always be replaced according to the incoming message. it doesn't have a memory.
fgmasdr IOhannes
check float help too
2013/10/6 IOhannes m zmölnig zmoelnig@iem.at:
On 10/06/13 13:12, Фывапр Олджэвич wrote:
Dear PD-list .
I found that in PD-extended 42.5 - the $1 inside a message is not saving data. Is it a bug ? see patch below.
no, it's expected behaviour and has been like this since forever.
a $arg in a messagebox will always be replaced according to the incoming message. it doesn't have a memory.
fgmasdr IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I found that in PD-extended 42.5 - the $1 inside a message is not saving
data. Is it a bug ? see patch below.
no, it's expected behaviour and has been like this since forever.
a $arg in a messagebox will always be replaced according to the incoming message. it doesn't have a memory.
...
A programming language is a lot about being consistent, and as such it seems logical that a msg should retain its last known state, so that when receiving a bang it would output its last stored values. msg certainly stores the remainder of a non $arg list (if any) and even saves it with the patch, so I would argue that it very much has a kind of "memory" that can be altered with [set{.
On 10/06/13 20:34, Ivica Ico Bukvic wrote:
A programming language is a lot about being consistent,
yes
and as such it seems logical that a msg should retain its last known state,
no. that's totally unrelated to being consistent.
so that when receiving a bang it would output its last stored values.
why? i think the current behaviour is very consistent though probably less convenient than some would like to have it.
consistent and convienient are similar words but not very related.
msg certainly stores the remainder of a non $arg list (if any) and even saves it with the patch, so I would argue that it very much has a kind of "memory" that can be altered with [set{.
yes, i was inaccurate. a msgbox does have a memory, but $args in msgboxes only relate to the *current* message. since a message is a volatile event, the *last current* message is not longer current in any way, hence it's values are not remembered.
gfmser IOhannes
to save with the patch you could use:
[set $1( | [t b a] | / [<emty msg box>(
best
-Jonas
Am 06.10.2013 um 20:46 schrieb IOhannes m zmölnig:
On 10/06/13 20:34, Ivica Ico Bukvic wrote:
A programming language is a lot about being consistent,
yes
and as such it seems logical that a msg should retain its last known state,
no. that's totally unrelated to being consistent.
so that when receiving a bang it would output its last stored values.
why? i think the current behaviour is very consistent though probably less convenient than some would like to have it.
consistent and convienient are similar words but not very related.
msg certainly stores the remainder of a non $arg list (if any) and even saves it with the patch, so I would argue that it very much has a kind of "memory" that can be altered with [set{.
yes, i was inaccurate. a msgbox does have a memory, but $args in msgboxes only relate to the *current* message. since a message is a volatile event, the *last current* message is not longer current in any way, hence it's values are not remembered.
gfmser IOhannes
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 10/06/2013 02:46 PM, IOhannes m zmölnig wrote:
On 10/06/13 20:34, Ivica Ico Bukvic wrote:
A programming language is a lot about being consistent,
yes
and as such it seems logical that a msg should retain its last known state,
no. that's totally unrelated to being consistent.
so that when receiving a bang it would output its last stored values.
why? i think the current behaviour is very consistent though probably less convenient than some would like to have it.
As you said, it's consistent in terms of having been Pd's dollarsign behavior "forever". Outside of that specific type of consistency across time-- i.e., backwards compatibility-- I see no valid argument that either way is "more" consistent. Both approaches are self-consistent. They (presumably) work exactly the same regardless of the context in which they get used in a particular patch.
Nevertheless, I think backwards compatibility is important. Here, the
current
"argument out of range" error gives helpful clues to patching mistakes.
With
Ivica's system if you set that out-of-range argument a single time then
future
mistakes that result in too few args to the message box would go unnoticed.
(They'd get padded with the old value.)
-Jonathan
and as such it seems logical that a msg should retain its last known
state,
no. that's totally unrelated to being consistent.
so that when receiving a bang it would output its last stored values.
why? i think the current behaviour is very consistent though probably less convenient than some would like to have it.
...how is [$1] retains value and [msg] doesn't (except it does anything other than $n) consistent?
As you said, it's consistent in terms of having been Pd's dollarsign behavior "forever". Outside of that specific type of consistency across time--
i.e.,
backwards compatibility-- I see no valid argument that either way is
"more"
consistent. Both approaches are self-consistent. They (presumably) work exactly the same regardless of the context in which they get used in a particular patch.
Nevertheless, I think backwards compatibility is important. Here, the current "argument out of range" error gives helpful clues to patching mistakes. With Ivica's system if you set that out-of-range argument a single time then future mistakes that result in too few args to the message box would go
unnoticed.
(They'd get padded with the old value.)
Then, there are those situations where properly formed message is passed through the msg object with no reported errors but is still malformed according to the receiving object below msg. An error is thrown by the receiving object but one has no way of recreating and studying the offending message...
Another thought is that just like [$1] retains last data value during runtime, shouldn't [msg] too? After all [msg] retains the rest of the list inside it not only during runtime but also during save, so why would not it retain its last data during runtime?
Ico
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2013-10-07 03:13, Ivica Ico Bukvic wrote:
and as such it seems logical that a msg should retain its last known
state,
no. that's totally unrelated to being consistent.
so that when receiving a bang it would output its last stored values.
why? i think the current behaviour is very consistent though probably less convenient than some would like to have it.
...how is [$1] retains value and [msg] doesn't (except it does anything other than $n) consistent?
[$1] does not retain it's value. [$1] gets evaluated at instantation time, and it could evaluate to [print] in one patch and to [netreceive] in another patch. if you have an abstraction "foo" containing [blu $1 $2] and you call it once as [foo 10 20] and once as [foo 3], the latter will not have a [blu 3 20]. [*] the only thing that [$1] retains is, that it will evaluate to the first argument of the patch.
msgboxes (assuming this is what you mean by [msg]) retain their meaning in the same way: [$1( will always evaluate to the first list-element of the incoming message.
As you said, it's consistent in terms of having been Pd's dollarsign behavior "forever". Outside of that specific type of consistency across time--
i.e.,
backwards compatibility-- I see no valid argument that either way is
"more"
consistent. Both approaches are self-consistent. They (presumably) work exactly the same regardless of the context in which they get used in a particular patch.
i cannot recally having said that one of the two approaches is not consistent. i only argued that the current behaviour already is consistent (and thus consistency is a bad reason to change it)
Then, there are those situations where properly formed message is passed through the msg object with no reported errors but is still malformed according to the receiving object below msg. An error is thrown by the receiving object but one has no way of recreating and studying the offending message...
do you have examples for that?
Another thought is that just like [$1] retains last data value during runtime, shouldn't [msg] too? After all [msg] retains the rest of the list inside it not only during runtime but also during save, so why would not it retain its last data during runtime?
see above (and please clarify what the [msg] object is)
fgmasdr IOhannes
-
Ingo -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Ivica Ico Bukvic -
Jack -
Jonathan Wilkes -
Joson Android -
Py Fave -
Фывапр Олджэвич