Test it out. http://msp.ucsd.edu/software.html
now, Miller, I haven't seen announcements from Pd-announce for the test versions as usual, how come?
I have some issues I have to report, by the way.
cheers
I think my e-mails aren't making it to pd-announce for some reason.
Anyway, yes, 0.52-0 test 2 is out :)
Miller
On Mon, Nov 22, 2021 at 11:20:16PM -0300, Alexandre Torres Porres wrote:
Test it out. http://msp.ucsd.edu/software.html
now, Miller, I haven't seen announcements from Pd-announce for the test versions as usual, how come?
I have some issues I have to report, by the way.
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Ok, as the first email to the list about it, here are some thoughts for starters :)
really gotten used to it, what's everyone else idea on this? Can we make this an optional feature to check/activate somewhere and leave the default as it were?
*Related to atoms/list boxes:*
instead, no shortcut is given for symbol and the next shortcut (cmd+5) is for comments as before. Why not have list as shortcut cmd+5 and comments get cmd+6?
shorter, who needs that big boxes most the time? can't we make the same as before?
to [float], float does not understand it and cannot convert it anymore to float.
I get '#0-x' when I reopen the preferences. This used to be something that happened for iemguis and we fixed it, but now these boxes have it.
ilegal) "," symbol.
cheers
Em ter., 23 de nov. de 2021 às 13:45, Miller Puckette msp@ucsd.edu escreveu:
I think my e-mails aren't making it to pd-announce for some reason.
Anyway, yes, 0.52-0 test 2 is out :)
Miller
On Mon, Nov 22, 2021 at 11:20:16PM -0300, Alexandre Torres Porres wrote:
Test it out. http://msp.ucsd.edu/software.html
now, Miller, I haven't seen announcements from Pd-announce for the test versions as usual, how come?
I have some issues I have to report, by the way.
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
--
Hey,
On 23.11.2021 18:06, Alexandre Torres Porres wrote:
Ok, as the first email to the list about it, here are some thoughts for starters :)
- Now connections get grayed out when making new connections. Haven't
really gotten used to it, what's everyone else idea on this? Can we make this an optional feature to check/activate somewhere and leave the default as it were?
Personally, I quite like it. Yes, it is a bit unsettling in the beginning, but I think it's one of those things that you get accustomed to very quickly.
*_Related to atoms/list boxes:_*
- The shortcut for symbol box (cmd+4) is gone, it now load the list
box instead, no shortcut is given for symbol and the next shortcut (cmd+5) is for comments as before. Why not have list as shortcut cmd+5 and comments get cmd+6?
I think *changing* existing shortcuts is a bad idea. So I think we should leave the shortcuts as they were and use cmd+6 for the new list atom. After all, a list atom is *not* a drop-in replacement for a symbol atom (numbers and spaces are handled differently!)
- the symbol box by default now is much wider, I always have to make
it shorter, who needs that big boxes most the time? can't we make the same as before?
I tend to agree. I think Miller just used the same default width for both list atoms and symbol atoms.
- something is funny on symbol boxes, if I type a number in it and
sendd it to [float], float does not understand it and cannot convert it anymore to float.
Actually, the problem is really this: when you type a number in symbol box and hit enter, the text just disappears and it outputs an empty symbol. Of course, [float] can't convert empty symbols :-)
- also float/symbol/list boxes. If I type '$0-x' as a send or receive
name, I get '#0-x' when I reopen the preferences. This used to be something that happened for iemguis and we fixed it, but now these boxes have it.
Confirmed! As a side note, we still can't have "#" in atom labels :-(
- if I type "hi, there" in a list box I get an unescaped (and
seemingly ilegal) "," symbol.
Generally, list atoms contain FUDI strings and colons, semicolons and dollars have special meanings. You have to escape them explicitly if you want them to part of a symbol.
"foo,bar" -> 3 atoms
"foo,bar" -> 1 symbol atom
However, you're right that the list atom forgets to bash those special to symbols, so you end up with A_SEMI, A_COMMA, A_DOLLAR and A_DOLLSYM atoms on the patch level - which is bad!
cheers
Em ter., 23 de nov. de 2021 às 13:45, Miller Puckette msp@ucsd.edu escreveu:
I think my e-mails aren't making it to pd-announce for some reason. Anyway, yes, 0.52-0 test 2 is out :) Miller On Mon, Nov 22, 2021 at 11:20:16PM -0300, Alexandre Torres Porres wrote: > Test it out. http://msp.ucsd.edu/software.html > > > now, Miller, I haven't seen announcements from Pd-announce for the test > versions as usual, how come? > > > I have some issues I have to report, by the way. > > > cheers > _______________________________________________ > Pd-list@lists.iem.at mailing list > UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=WQBvsjyf35crZlCHFnpwOUFo_ekvAAdS50J9713nfC8s5PCsPOUqFJXpwNINPLCi&s=MUcD-Z1CN-Y6NI4qF_iICTXRAiuMlU6eJKrbcRg3-KE&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwICAg&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=WQBvsjyf35crZlCHFnpwOUFo_ekvAAdS50J9713nfC8s5PCsPOUqFJXpwNINPLCi&s=MUcD-Z1CN-Y6NI4qF_iICTXRAiuMlU6eJKrbcRg3-KE&e=> --
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
and now for things we also usually ask in response to test release announcements :)
I'm just curious on why this feature has been held for so long since it's been flagged for inclusion back in the 0.49 release (and now 0.52), it's the addition of "$0" for messages, seems like there's something still "wrong" with it? => https://github.com/pure-data/pure-data/pull/347 I ask because I've been improving the documentation of handling "$0" in Pd, and it'd be much easier with it.
I also got a couple of new PRs that promote quick/minor changes to code that I consider 'bug fixes' from a documentation point of view: 1) Get rid of useless [bang~] inlet (https://github.com/pure-data/pure-data/pull/1471) cause I don't think it makes sense to document that it has no functionality (and this won't break any patches); 2) add bang method to [atan2] ( https://github.com/pure-data/pure-data/pull/1465), because all other similar math/binary operators do this and it's just harder and more confusing to document a special inconsistent case. This is specially needed now that I'm adding references subpatches with info on i/olets and methods.
cheers
Em ter., 23 de nov. de 2021 às 15:29, Antoine Rousseau antoine@metalu.net escreveu:
leave the shortcuts as they were and use cmd+6 for the new list atom
+1
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
And as for the 'long overdue', there's this fix that's been bugging me since Pd 0.46 when I first reported it that really complicates some patches with delay interactions https://github.com/pure-data/pure-data/pull/708
Em ter., 23 de nov. de 2021 às 17:10, Alexandre Torres Porres < porres@gmail.com> escreveu:
and now for things we also usually ask in response to test release announcements :)
I'm just curious on why this feature has been held for so long since it's been flagged for inclusion back in the 0.49 release (and now 0.52), it's the addition of "$0" for messages, seems like there's something still "wrong" with it? => https://github.com/pure-data/pure-data/pull/347 I ask because I've been improving the documentation of handling "$0" in Pd, and it'd be much easier with it.
I also got a couple of new PRs that promote quick/minor changes to code that I consider 'bug fixes' from a documentation point of view: 1) Get rid of useless [bang~] inlet (https://github.com/pure-data/pure-data/pull/1471) cause I don't think it makes sense to document that it has no functionality (and this won't break any patches); 2) add bang method to [atan2] ( https://github.com/pure-data/pure-data/pull/1465), because all other similar math/binary operators do this and it's just harder and more confusing to document a special inconsistent case. This is specially needed now that I'm adding references subpatches with info on i/olets and methods.
cheers
Em ter., 23 de nov. de 2021 às 15:29, Antoine Rousseau antoine@metalu.net escreveu:
leave the shortcuts as they were and use cmd+6 for the new list atom
+1
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
it's the addition of "$0" for messages, seems like there's something still "wrong" with it?
Personally, I think it would simplify so many patches and I would really like to see this happening.
This has been discussed at length in the mailing lists several times and it seems some people have a problem with it on a conceptual level (which I never quite understood). But on a practical level it seems like such a non-brainer... Dunno...
Anyway, I think a test release is the probably the wrong time to add features. We should rather focus on fixing the remaining regressions.
Let's hope for Pd 0.53 :-)
Christof
PS: there is also https://github.com/pure-data/pure-data/pull/627 which has been sitting idle for over 2 years now and I don't really know why... seems like a perfectly cromulent feature to me :-)
On 23.11.2021 21:10, Alexandre Torres Porres wrote:
and now for things we also usually ask in response to test release announcements :)
I'm just curious on why this feature has been held for so long since it's been flagged for inclusion back in the 0.49 release (and now 0.52), it's the addition of "$0" for messages, seems like there's something still "wrong" with it? => https://github.com/pure-data/pure-data/pull/347 I ask because I've been improving the documentation of handling "$0" in Pd, and it'd be much easier with it.
I also got a couple of new PRs that promote quick/minor changes to code that I consider 'bug fixes' from a documentation point of view:
- Get rid of useless [bang~] inlet
(https://github.com/pure-data/pure-data/pull/1471) cause I don't think it makes sense to document that it has no functionality (and this won't break any patches); 2) add bang method to [atan2] (https://github.com/pure-data/pure-data/pull/1465), because all other similar math/binary operators do this and it's just harder and more confusing to document a special inconsistent case. This is specially needed now that I'm adding references subpatches with info on i/olets and methods.
cheers
Em ter., 23 de nov. de 2021 às 15:29, Antoine Rousseau antoine@metalu.net escreveu:
leave the shortcuts as they were and use cmd+6 for the new list atom +1 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
Em ter., 23 de nov. de 2021 às 17:30, Christof Ressi info@christofressi.com escreveu:
it's the addition of "$0" for messages, seems like there's something still "wrong" with it?
(...) it seems some people have a problem with it on a conceptual level (which I never quite understood). But on a practical level it seems like such a non-brainer... Dunno
Let's hope for Pd 0.53 :-)
yeah, I'm mostly just curious here
I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...)
It would be interestnig to allow message boxes to access canvas creation arguments somehow, but not that way.
Meanwhile I adopted the atan2 fix but then had to fix a compileer error (old c compilers can't deal with declarations like "t_float f1" that occur after non-declaration statements). I'll leave the "bang~ inlet there - I think it doesn't need to be documented because it doesn't do anything :)
M On Tue, Nov 23, 2021 at 05:10:39PM -0300, Alexandre Torres Porres wrote:
and now for things we also usually ask in response to test release announcements :)
I'm just curious on why this feature has been held for so long since it's been flagged for inclusion back in the 0.49 release (and now 0.52), it's the addition of "$0" for messages, seems like there's something still "wrong" with it? => https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_... I ask because I've been improving the documentation of handling "$0" in Pd, and it'd be much easier with it.
I also got a couple of new PRs that promote quick/minor changes to code that I consider 'bug fixes' from a documentation point of view: 1) Get rid of useless [bang~] inlet (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_... ) cause I don't think it makes sense to document that it has no functionality (and this won't break any patches); 2) add bang method to [atan2] ( https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_... ), because all other similar math/binary operators do this and it's just harder and more confusing to document a special inconsistent case. This is specially needed now that I'm adding references subpatches with info on i/olets and methods.
cheers
Em ter., 23 de nov. de 2021 Ã s 15:29, Antoine Rousseau antoine@metalu.net escreveu:
leave the shortcuts as they were and use cmd+6 for the new list atom
+1
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Em sáb., 27 de nov. de 2021 às 21:29, Miller Puckette msp@ucsd.edu escreveu:
I'll leave the "bang~ inlet there - I think it doesn't need to be documented because it doesn't do anything :)
we should document it does nothing then :) otherwise people can think it does something that it was forgotten to document.
now, what if it did something? Like a toggle input to turn it on/off? => https://github.com/pure-data/pure-data/issues/1472
On 28.11.2021 01:29, Miller Puckette via Pd-list wrote:
I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...)
But the same is true for canvas creation arguments! $0 is not a creation argument after all, i.e. it is not part of "ce_argv". Also, it really has a different purpose. So I don't really see the problem allowing it in message boxes... $0 would be a special case either way.
But I'll stop now :-)
Meanwhile I adopted the atan2 fix but then had to fix a compileer error (old c compilers can't deal with declarations like "t_float f1" that occur after non-declaration statements). I'll leave the "bang~ inlet there - I think it doesn't need to be documented because it doesn't do anything :)
M On Tue, Nov 23, 2021 at 05:10:39PM -0300, Alexandre Torres Porres wrote:
and now for things we also usually ask in response to test release announcements :)
I'm just curious on why this feature has been held for so long since it's been flagged for inclusion back in the 0.49 release (and now 0.52), it's the addition of "$0" for messages, seems like there's something still "wrong" with it? => https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_... I ask because I've been improving the documentation of handling "$0" in Pd, and it'd be much easier with it.
I also got a couple of new PRs that promote quick/minor changes to code that I consider 'bug fixes' from a documentation point of view: 1) Get rid of useless [bang~] inlet (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_... ) cause I don't think it makes sense to document that it has no functionality (and this won't break any patches); 2) add bang method to [atan2] ( https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_pure-2Ddata_... ), because all other similar math/binary operators do this and it's just harder and more confusing to document a special inconsistent case. This is specially needed now that I'm adding references subpatches with info on i/olets and methods.
cheers
Em ter., 23 de nov. de 2021 às 15:29, Antoine Rousseau antoine@metalu.net escreveu:
leave the shortcuts as they were and use cmd+6 for the new list atom +1
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Em sáb., 27 de nov. de 2021 às 21:59, Christof Ressi info@christofressi.com escreveu:
On 28.11.2021 01:29, Miller Puckette via Pd-list wrote:
I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...)
But the same is true for canvas creation arguments! $0 is not a creation argument after all, i.e. it is not part of "ce_argv".
It was also never documented as an 'argument'. I understand there's an internal logical reason, but under a user perspective, we are never aware of it and really expect to be able to use it inside message boxes so they can communicate to local [receive] objects.
Another compelling reason is that Pd-L2ork and Purr Data allow this in their syntax and it would be beneficial to backport this to improve compatibility between patches.
Also, it really has a different purpose. So I don't really see the problem allowing it in message boxes... $0 would be a special case either way.
We also have unexpected and weird behaviour in other places. It's all a matter of documenting. Actually, now that I am more explicitly documenting "$0" in Pd, it's all just way more complicated to document that you can't use "$0" in messages as you'd expect. So it's like we're documenting unexpected behaviour now instead of otherwise.
But I'll stop now :-)
:(
Context: we have an open PR that allows us to expand '$0' in messages. I'd like to know if it's been officially rejected so we can close it for good and settle the debate. Then maybe think of something else.
Miller's response:
Em sáb., 27 de nov. de 2021 às 21:29, Miller Puckette msp@ucsd.edu escreveu:
I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...)
It would be interestnig to allow message boxes to access canvas creation
arguments somehow, but not that way.
To which me and Christoph argued things like
"ce_argv". Also, it really **has a different purpose. (...) $0 would be a special case either way.*
perspective, we are never aware of it and really expect to be able to use it inside message boxes so they can communicate to local [receive] objects (..) We also have unexpected and weird behaviour in other places. It's all a matter of documenting.*
Now, what I actually have come up as a solution for me, so far, was designing an external object named "message". It does all that messages do, they understand comma and semicolons (and act accordingly). The messages can be set via a right inlet (with commas and semicolons being possible by escaping with "") and the object also acts as a general message storage object. So the idea is to have something like this that acts like a message and is an object. Moreover, as an object, it can also deal with "$1" ... "$2" ... ect as expected, and as also has been considered here as something desired.
If this idea resonates well, I can try and open a PR for it and we can discuss the design details.
see screenshot of the object
cheers
I have an idea about $0
what if we introduce double dollar syntax to grab patch arguments? and then inside messages $$1 would be first abstraction argument, while $1 is the the first element of the list (as it already is)
this way, $$0 in a message would be what $0 is for an object, $$1 would be what $1 is for an object, and so on (this would be coherent)
this way we add the ability to access $0 from an object as $$0 in a message and as a bonus make easier to get the patch arguments inside a message too.. this makes sense? what do you think?
Em qua., 1 de dez. de 2021 16:44, Alexandre Torres Porres porres@gmail.com escreveu:
Context: we have an open PR that allows us to expand '$0' in messages. I'd like to know if it's been officially rejected so we can close it for good and settle the debate. Then maybe think of something else.
Miller's response:
Em sáb., 27 de nov. de 2021 às 21:29, Miller Puckette msp@ucsd.edu escreveu:
I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...)
It would be interestnig to allow message boxes to access canvas creation
arguments somehow, but not that way.
To which me and Christoph argued things like
- *$0 is not a creation argument after all, i.e. it is not part of
"ce_argv". Also, it really **has a different purpose. (...) $0 would be a special case either way.*
- *It was also never documented as an 'argument'. (...) under a user
perspective, we are never aware of it and really expect to be able to use it inside message boxes so they can communicate to local [receive] objects (..) We also have unexpected and weird behaviour in other places. It's all a matter of documenting.*
Now, what I actually have come up as a solution for me, so far, was designing an external object named "message". It does all that messages do, they understand comma and semicolons (and act accordingly). The messages can be set via a right inlet (with commas and semicolons being possible by escaping with "") and the object also acts as a general message storage object. So the idea is to have something like this that acts like a message and is an object. Moreover, as an object, it can also deal with "$1" ... "$2" ... ect as expected, and as also has been considered here as something desired.
If this idea resonates well, I can try and open a PR for it and we can discuss the design details.
see screenshot of the object
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I like the idea.
Em qua., 1 de dez. de 2021 às 17:14, José de Abreu abreubacelar@gmail.com escreveu:
I have an idea about $0
what if we introduce double dollar syntax to grab patch arguments? and then inside messages $$1 would be first abstraction argument, while $1 is the the first element of the list (as it already is)
this way, $$0 in a message would be what $0 is for an object, $$1 would be what $1 is for an object, and so on (this would be coherent)
this way we add the ability to access $0 from an object as $$0 in a message and as a bonus make easier to get the patch arguments inside a message too.. this makes sense? what do you think?
Em qua., 1 de dez. de 2021 16:44, Alexandre Torres Porres < porres@gmail.com> escreveu:
Context: we have an open PR that allows us to expand '$0' in messages. I'd like to know if it's been officially rejected so we can close it for good and settle the debate. Then maybe think of something else.
Miller's response:
Em sáb., 27 de nov. de 2021 às 21:29, Miller Puckette msp@ucsd.edu escreveu:
I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...)
It would be interestnig to allow message boxes to access canvas creation
arguments somehow, but not that way.
To which me and Christoph argued things like
- *$0 is not a creation argument after all, i.e. it is not part of
"ce_argv". Also, it really **has a different purpose. (...) $0 would be a special case either way.*
- *It was also never documented as an 'argument'. (...) under a user
perspective, we are never aware of it and really expect to be able to use it inside message boxes so they can communicate to local [receive] objects (..) We also have unexpected and weird behaviour in other places. It's all a matter of documenting.*
Now, what I actually have come up as a solution for me, so far, was designing an external object named "message". It does all that messages do, they understand comma and semicolons (and act accordingly). The messages can be set via a right inlet (with commas and semicolons being possible by escaping with "") and the object also acts as a general message storage object. So the idea is to have something like this that acts like a message and is an object. Moreover, as an object, it can also deal with "$1" ... "$2" ... ect as expected, and as also has been considered here as something desired.
If this idea resonates well, I can try and open a PR for it and we can discuss the design details.
see screenshot of the object
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
what if we introduce double dollar syntax to grab patch arguments?
Actually, I already thought about that. The problem is that "$" is only interpreted as a dollar or dollarsym if it is followed by a number. So currently "$$" is not a reserved token, meaning that "$$" is a valid symbol. We *could* reserve it, but we risk breaking some patches. Assuming that only very few patches will be affected by this change, we might decide that extending the functionality of message boxes is more important.
Christof
On 01.12.2021 21:22, Alexandre Torres Porres wrote:
I like the idea.
Em qua., 1 de dez. de 2021 às 17:14, José de Abreu abreubacelar@gmail.com escreveu:
I have an idea about $0 what if we introduce double dollar syntax to grab patch arguments? and then inside messages $$1 would be first abstraction argument, while $1 is the the first element of the list (as it already is) this way, $$0 in a message would be what $0 is for an object, $$1 would be what $1 is for an object, and so on (this would be coherent) this way we add the ability to access $0 from an object as $$0 in a message and as a bonus make easier to get the patch arguments inside a message too.. this makes sense? what do you think? Em qua., 1 de dez. de 2021 16:44, Alexandre Torres Porres <porres@gmail.com> escreveu: Context: we have an open PR that allows us to expand '$0' in messages. I'd like to know if it's been officially rejected so we can close it for good and settle the debate. Then maybe think of something else. Miller's response: Em sáb., 27 de nov. de 2021 às 21:29, Miller Puckette <msp@ucsd.edu> escreveu: I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...) It would be interestnig to allow message boxes to access canvas creation arguments somehow, but not that way. To which me and Christoph argued things like - /$0 is not a creation argument after all, i.e. it is not part of "ce_argv". Also, it really //has a different purpose. (...) $0 would be a special case either way./ - /It was also never documented as an 'argument'. (...) under a user perspective, we are never aware of it and really expect to be able to use it inside message boxes so they can communicate to local [receive] objects (..) We also have unexpected and weird behaviour in other places. It's all a matter of documenting./ Now, what I actually have come up as a solution for me, so far, was designing an external object named "message". It does all that messages do, they understand comma and semicolons (and act accordingly). The messages can be set via a right inlet (with commas and semicolons being possible by escaping with "\") and the object also acts as a general message storage object. So the idea is to have something like this that acts like a message and is an object. Moreover, as an object, it can also deal with "$1" ... "$2" ... ect as expected, and as also has been considered here as something desired. If this idea resonates well, I can try and open a PR for it and we can discuss the design details. see screenshot of the object cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
I think having a "message" object is a better idea. Only thing is, it does raise some interesting design questions of its own - like, what of sending more than one message; how to specify destination names without using the ';' separator, and what if we allowed expressions ...
cheers Miller
On Wed, Dec 01, 2021 at 09:34:15PM +0100, Christof Ressi wrote:
what if we introduce double dollar syntax to grab patch arguments?
Actually, I already thought about that. The problem is that "$" is only interpreted as a dollar or dollarsym if it is followed by a number. So currently "$$" is not a reserved token, meaning that "$$" is a valid symbol. We *could* reserve it, but we risk breaking some patches. Assuming that only very few patches will be affected by this change, we might decide that extending the functionality of message boxes is more important.
Christof
On 01.12.2021 21:22, Alexandre Torres Porres wrote:
I like the idea.
Em qua., 1 de dez. de 2021 às 17:14, José de Abreu abreubacelar@gmail.com escreveu:
I have an idea about $0 what if we introduce double dollar syntax to grab patch arguments? and then inside messages $$1 would be first abstraction argument, while $1 is the the first element of the list (as it already is) this way, $$0 in a message would be what $0 is for an object, $$1 would be what $1 is for an object, and so on (this would be coherent) this way we add the ability to access $0 from an object as $$0 in a message and as a bonus make easier to get the patch arguments inside a message too.. this makes sense? what do you think? Em qua., 1 de dez. de 2021 16:44, Alexandre Torres Porres <porres@gmail.com> escreveu: Context: we have an open PR that allows us to expand '$0' in messages. I'd like to know if it's been officially rejected so we can close it for good and settle the debate. Then maybe think of something else. Miller's response: Em sáb., 27 de nov. de 2021 às 21:29, Miller Puckette <msp@ucsd.edu> escreveu: I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...) It would be interestnig to allow message boxes to access canvas creation arguments somehow, but not that way. To which me and Christoph argued things like - /$0 is not a creation argument after all, i.e. it is not part of "ce_argv". Also, it really //has a different purpose. (...) $0 would be a special case either way./ - /It was also never documented as an 'argument'. (...) under a user perspective, we are never aware of it and really expect to be able to use it inside message boxes so they can communicate to local [receive] objects (..) We also have unexpected and weird behaviour in other places. It's all a matter of documenting./ Now, what I actually have come up as a solution for me, so far, was designing an external object named "message". It does all that messages do, they understand comma and semicolons (and act accordingly). The messages can be set via a right inlet (with commas and semicolons being possible by escaping with "\") and the object also acts as a general message storage object. So the idea is to have something like this that acts like a message and is an object. Moreover, as an object, it can also deal with "$1" ... "$2" ... ect as expected, and as also has been considered here as something desired. If this idea resonates well, I can try and open a PR for it and we can discuss the design details. see screenshot of the object cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwIDaQ&c=-35OiAkTchMrZOngvJPOeA&r=XprZV3Fxus2L1LCw80hE4Q&m=X356gE987R4-v6hM70lWkol4S4SaaoMN6K1GUTwzVOs6vXy64pXeuaSvufiKEdaj&s=oaiog5acgrgvYre_RpIYhOmR4kXfCAvk6whITQhJnyU&e=
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Em qua., 1 de dez. de 2021 às 17:44, Miller Puckette via Pd-list < pd-list@lists.iem.at> escreveu:
I think having a "message" object is a better idea. Only thing is, it does raise some interesting design questions of its own - like, what of sending more than one message; how to specify destination names without using the ';' separator
Hmm, I don't understand the questions :)
I am using the ";" separator in my external object. It all works inside the object box just exactly like a message box. So you can also use commas and separate more than one message.
Now, the idea for my object is that it also works as a message storage object, that is, like a "float" or "symbol" object, but one that can store any kinda of message. Then, it can receive messages from messages in the cold and hot inlet. And we can set ";" and "," by escaping them with "".
So sending *1 , 2 , 3* *1 , 2 \ , 3* to its hot inler makes it output 3 messages ("1", "2" and "3") and this gets stored.
By the way, I can also escape "$", so if I send it * ; $0-x 8 *it sends "8" to a [receive $0-x] object. If you want to specify a literal "$0", you can send it "\$0"...
A "bang" in the left inlet outputs the message, but I also made the objcct clickable, so clicking on it sends the message.
But then, of course this can be simpler, and just have one inlet, for a bang, no click, no cold inlet, for starters, what do. you people think?
and what if we allowed expressions ...
what do you mean?
cheers
cheers Miller
On Wed, Dec 01, 2021 at 09:34:15PM +0100, Christof Ressi wrote:
what if we introduce double dollar syntax to grab patch arguments?
Actually, I already thought about that. The problem is that "$" is only interpreted as a dollar or dollarsym if it is followed by a number. So currently "$$" is not a reserved token, meaning that "$$" is a valid
symbol.
We *could* reserve it, but we risk breaking some patches. Assuming that
only
very few patches will be affected by this change, we might decide that extending the functionality of message boxes is more important.
Christof
On 01.12.2021 21:22, Alexandre Torres Porres wrote:
I like the idea.
Em qua., 1 de dez. de 2021 às 17:14, José de Abreu abreubacelar@gmail.com escreveu:
I have an idea about $0 what if we introduce double dollar syntax to grab patch arguments? and then inside messages $$1 would be first abstraction argument, while $1 is the the first element of the list (as it already is) this way, $$0 in a message would be what $0 is for an object, $$1 would be what $1 is for an object, and so on (this would be
coherent)
this way we add the ability to access $0 from an object as $$0 in a message and as a bonus make easier to get the patch arguments inside a message too.. this makes sense? what do you think? Em qua., 1 de dez. de 2021 16:44, Alexandre Torres Porres <porres@gmail.com> escreveu: Context: we have an open PR that allows us to expand '$0' in messages. I'd like to know if it's been officially rejected so we can close it for good and settle the debate. Then maybe think of something else. Miller's response: Em sáb., 27 de nov. de 2021 às 21:29, Miller Puckette <msp@ucsd.edu> escreveu: I disagree with the "$0" in message box idea. Why not $1 then? (Oh, because it already does something different...) It would be interestnig to allow message boxes to access canvas creation arguments somehow, but not that way. To which me and Christoph argued things like - /$0 is not a creation argument after all, i.e. it is not part of "ce_argv". Also, it really //has a different purpose. (...) $0 would be a special case either way./ - /It was also never documented as an 'argument'. (...) under a user perspective, we are never aware of it and really expect to be able to use it inside message boxes so they can communicate to local [receive] objects (..) We also have unexpected and weird behaviour in other places. It's all a matter of documenting./ Now, what I actually have come up as a solution for me, so far, was designing an external object named "message". It does all that messages do, they understand comma and semicolons (and act accordingly). The messages can be set via a right inlet (with commas and semicolons being possible by escaping with "\") and the object also acts as a general message storage object. So the idea is to have something like this that acts like a message and is an object. Moreover, as an object, it can also deal with "$1" ... "$2" ... ect as expected, and as also has been considered here as something desired. If this idea resonates well, I can try and open a PR for it and we can discuss the design details. see screenshot of the object cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Imo it still seems to me that $0 in message boxes should get the selector since $1 etc. in message boxes are positional elements in messages at "msg-passing time" and $1 etc. are positional elements (arguments) in objects at load-time. - seb
Sent from the all new AOL app for Android
- *$0 is not a creation argument after all, i.e. it is not part of
"ce_argv".*
I don't know... Can't we consider $0 as an "unconditional" creation argument?...
case either way.*
I'm not sure either. To me, both $0 and $1 etc. can be used to identify an instance of an abstraction. IMO $0 is the quick way, but has the limitation to make it (nearly) impossible to access members from the outside. That's why it often happened to me to rename an instance [myAbs] to e.g [myAbs myabs1], then to replace $0 in [myAbs] with $1, so I can easily access [myAbs]'s members from the parent - from anywhere in fact (Actually, nowadays I tend to use as few $0 as possible). If we could use $0 in messages, then the last operation would be more complicated (cause you couldn't simply substitute $0 with e.g $1). So I think it's better to keep the $0/$n symmetry.
I think having a "message" object is a better idea [than $$'s one]
What I like with the $$ idea, is that it would provide a simple way to merge creation arguments with variable arguments, i.e compose a message with both the abstraction arguments and the incoming message elements.
So I think it's better to keep the $0/$n symmetry.
I think having a "message" object is a better idea [than $$'s one]
What I like with the $$ idea, is that it would provide a simple way to merge creation arguments with variable arguments, i.e compose a message with both the abstraction arguments and the incoming message elements.
I have to say I quite like the "$$" idea as well, assuming that we can take the risk of breaking a few patches (if any).
I don't think it's a good idea to add a new object just for this functionality. For me this would create unnecessary complexity (you have to learn yet another object).
I'm not sure either. To me, both $0 and $1 etc. can be used to identify an instance of an abstraction. IMO $0 is the quick way, but has the limitation to make it (nearly) impossible to access members from the outside. That's why it often happened to me to rename an instance [myAbs] to e.g [myAbs myabs1], then to replace $0 in [myAbs] with $1, so I can easily access [myAbs]'s members from the parent - from anywhere in fact (Actually, nowadays I tend to use as few $0 as possible). If we could use $0 in messages, then the last operation would be more complicated (cause you couldn't simply substitute $0 with e.g $1).
I agree that if we get the "$$" syntax, then it makes more sense to use "$$0" for the $0 argument! Without the "$$" syntax, I wouldn't see the problem...
One downside of using "$$0" is that it wouldn't be compatible with Pd-L2Ork / PurrData.If they have already diverged significantly, we probably don't have to care, but otherwise...
I don't think that's really useful. I think it's really bug that message boxes accept "anything" messages and I would opt for removing it:
https://github.com/pure-data/pure-data/issues/1491 (I remember I had brought this issue up somewhere, but apparantly didn't open a ticket on GitHub until now.)
Then the only selectors you could possible get are "float", "symbol", "list" and "pointer", which is not too useful I guess :-)
On 02.12.2021 09:02, Sebastian Shader via Pd-list wrote:
Imo it still seems to me that $0 in message boxes should get the selector since $1 etc. in message boxes are positional elements in messages at "msg-passing time" and $1 etc. are positional elements (arguments) in objects at load-time.
- seb
Sent from the all new AOL app for Android https://play.google.com/store/apps/details?id=com.aol.mobile.aolapp
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
Em ter., 23 de nov. de 2021 às 14:59, Christof Ressi info@christofressi.com escreveu:
As a side note, we still can't have "#" in atom labels :-(
Can't confirm this, I can type "C#" or set it via label messages. Also tried "#-4" and it worked (tested in [cnv] and [bng]).
This is indeed fixed in IEM GUIs, but not in *gatom* labels.
IEM GUIs: can use # in labels and send/receive symbols
gatoms: # in labels and send/receive symbols are replaced by $. (Up to Pd 0.51-4 it worked in send/receive symbols at least...)
On 23.11.2021 21:24, Alexandre Torres Porres wrote:
Em ter., 23 de nov. de 2021 às 14:59, Christof Ressi info@christofressi.com escreveu:
As a side note, we still can't have "#" in atom labels :-(
Can't confirm this, I can type "C#" or set it via label messages. Also tried "#-4" and it worked (tested in [cnv] and [bng]).
Em ter., 23 de nov. de 2021 às 17:42, Christof Ressi info@christofressi.com escreveu:
This is indeed fixed in IEM GUIs, but not in *gatom* labels.
hmmm, I see, not a regression (same happened in 0.51-4), but definitely some worth fixing as long as we're at it. Now $0-x becoming #0-x is a regression. Well, I put it all into an issue: https://github.com/pure-data/pure-data/issues/1476
On 23.11.2021 21:54, Alexandre Torres Porres wrote:
Em ter., 23 de nov. de 2021 às 17:42, Christof Ressi info@christofressi.com escreveu:
This is indeed fixed in IEM GUIs, but not in *gatom* labels.
hmmm, I see, not a regression (same happened in 0.51-4), but definitely some worth fixing as long as we're at it. Now $0-x becoming #0-x is a regression. Well, I put it all into an issue: https://github.com/pure-data/pure-data/issues/1476
Yes, that's what I meant to say. I just phrased it badly :-)
Thanks for the issue!
Em ter., 23 de nov. de 2021 às 14:59, Christof Ressi info@christofressi.com escreveu:
- if I type "hi, there" in a list box I get an unescaped (and seemingly
ilegal) "," symbol.
Generally, list atoms contain FUDI strings and colons, semicolons and dollars have special meanings. You have to escape them explicitly if you want them to part of a symbol.
"foo,bar" -> 3 atoms
"foo,bar" -> 1 symbol atom
However, you're right that the list atom forgets to bash those special to symbols, so you end up with A_SEMI, A_COMMA, A_DOLLAR and A_DOLLSYM atoms on the patch level - which is bad!
It seems we need to force add "" like symbol boxes do in these cases (but not on adding a space, cause we usually want spaces in the list box).
In parallel, there's the idea to hide this force adding "" visually on the boxes, but this can be taken care further in both cases of list/symbol boxes.
It seems we need to force add "" like symbol boxes do in these cases
This would also be possible. Probably better than silently bashing to individual symbols.
(but not on adding a space, cause we usually want spaces in the list box).
We can't really automatically escape them anyway because the unescaped and escaped white space have different meanings.
On 23.11.2021 21:36, Alexandre Torres Porres wrote:
Em ter., 23 de nov. de 2021 às 14:59, Christof Ressi info@christofressi.com escreveu:
- if I type "hi, there" in a list box I get an unescaped (and seemingly ilegal) "," symbol.
Generally, list atoms contain FUDI strings and colons, semicolons and dollars have special meanings. You have to escape them explicitly if you want them to part of a symbol. "foo,bar" -> 3 atoms "foo\,bar" -> 1 symbol atom However, you're right that the list atom forgets to bash those special to symbols, so you end up with A_SEMI, A_COMMA, A_DOLLAR and A_DOLLSYM atoms on the patch level - which is bad!
It seems we need to force add "" like symbol boxes do in these cases (but not on adding a space, cause we usually want spaces in the list box).
In parallel, there's the idea to hide this force adding "" visually on the boxes, but this can be taken care further in both cases of list/symbol boxes.
On Tue, 2021-11-23 at 18:56 +0100, Christof Ressi wrote:
I think *changing* existing shortcuts is a bad idea. So I think we should leave the shortcuts as they were and use cmd+6 for the new list atom. After all, a list atom is *not* a drop-in replacement for a symbol atom (numbers and spaces are handled differently!)
+1
Roman
I don't know which way to go on this one... I think it's a bad idea to have a shortcut for "symbol" since it's more often hit by accident than on purpose - and it confuses people who make them thinking they're making floats.
cheers M
On Tue, Nov 23, 2021 at 10:00:47PM +0100, Roman Haefeli wrote:
On Tue, 2021-11-23 at 18:56 +0100, Christof Ressi wrote:
I think *changing* existing shortcuts is a bad idea. So I think we should leave the shortcuts as they were and use cmd+6 for the new list atom. After all, a list atom is *not* a drop-in replacement for a symbol atom (numbers and spaces are handled differently!)
+1
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em sáb., 27 de nov. de 2021 às 21:33, Miller Puckette via Pd-list < pd-list@lists.iem.at> escreveu:
I don't know which way to go on this one... I think it's a bad idea to have a shortcut for "symbol" since it's more often hit by accident than on purpose - and it confuses people who make them thinking they're making floats.
I think it's obvious it's a symbol box, cause at least up to 0.51-4 it got created with 'symbol' inside the box. I found myself trying to get symbol boxes by habit with the shortcut and getting frrustrated I got the list box instead. Maybe because I was doing all these documentation updates. One way or another, I don't see why this poor element should be the one without any shortcut whatsoever.
cheers
testing 0.52, I realize deken hides all but the latest release, and they all show when uncheck "hide foreign architecture".
looks like a bug, right?
Em dom., 28 de nov. de 2021 às 00:39, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sáb., 27 de nov. de 2021 às 21:33, Miller Puckette via Pd-list < pd-list@lists.iem.at> escreveu:
I don't know which way to go on this one... I think it's a bad idea to have a shortcut for "symbol" since it's more often hit by accident than on purpose - and it confuses people who make them thinking they're making floats.
I think it's obvious it's a symbol box, cause at least up to 0.51-4 it got created with 'symbol' inside the box. I found myself trying to get symbol boxes by habit with the shortcut and getting frrustrated I got the list box instead. Maybe because I was doing all these documentation updates. One way or another, I don't see why this poor element should be the one without any shortcut whatsoever.
cheers
Am 28. November 2021 05:59:55 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
testing 0.52, I realize deken hides all but the latest release, and they all show when uncheck "hide foreign architecture".
looks like a bug, right?
No. Looks like intended behaviour.
Or did you uncheck the "Only show the newest version of a library (treats other versions like foreign architectures)" checkbox and it still hides the newest version?
mfg.sfg.jfd IOhannes
Em dom., 28 de nov. de 2021 às 04:27, IOhannes m zmölnig zmoelnig@iem.at escreveu:
Am 28. November 2021 05:59:55 MEZ schrieb Alexandre Torres Porres < porres@gmail.com>:
testing 0.52, I realize deken hides all but the latest release, and they all show when uncheck "hide foreign architecture".
looks like a bug, right?
No. Looks like intended behaviour.
Or did you uncheck the "Only show the newest version of a library (treats other versions like foreign architectures)" checkbox and it still hides the newest version?
The newest version wasn't hidden. It was the only one that was shown. Hence, it treats ALL previous versions as foreign architectures. And you're right, there's no "*Only show the newest version of a library (treats other versions like foreign architectures)*" checkbox, so I consider this a bug. Again, besides the latest version, all the others show up when I uncheck uncheck "hide foreign architecture", and they don't show up highlighted, they are listed as if they were in fact foreign.
It took me some time to realize what was going on. I only saw one version of ELSE (beta44) and Cyclone (0.5-6), then I took the opportunity to release new versions (ELSE beta 45 / Cyclone 0.6.0) that were ready and just waiting for 0.52 final. Deken now only shows the newest ones and hides the others that were the only ones it was showing before.
Well, this really looks like unintended behaviour.
cheers
Am 28. November 2021 14:57:53 MEZ schrieb Alexandre Torres Porres porres@gmail.com:
Em dom., 28 de nov. de 2021 às 04:27, IOhannes m zmölnig zmoelnig@iem.at escreveu:
Am 28. November 2021 05:59:55 MEZ schrieb Alexandre Torres Porres
right, there's no "*Only show the newest version of a library (treats other versions like foreign architectures)*" checkbox, so I consider this a bug.
Could you post a screenshot of the drken settings?
mfg.sfg.jfd IOhannes
Am 28. November 2021 14:57:53 MEZ schrieb Alexandre Torres Porres < porres@gmail.com>: And you're right, there's no "*Only show the newest version of a library (treats other versions like foreign architectures)*" checkbox
Hey, I thought you were being ironic telling me about a new box that doesn't exist, and now I see in fact there is a new box that says "*Only show the newest version of a library (treats other versions like foreign architectures)*"... and yeah, it is checked by default. I think this kind of unwarned change can be really confusing, see my case here :) it's a cool option, but maybe not checked by default?
Could you post a screenshot of the drken settings?
Here it is anyway, and, by the way, I also notice something else funny. It keeps force checking the "User-defined-platform" selection with that weird thing. I changed to "default", but when I restart Pd, there it is again. Bug found?
[image: Screen Shot 2021-11-28 at 11.50.39.png]
mfg.sfg.jfd IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I think this kind of unwarned change can be really confusing, see my case here :) it's a cool option, but maybe not checked by default?
I also think that the option should be off by default. For example, let's say there is a stable "vstplugin~-0.5.2" package on Deken. Now, if I upload "vstplugin~-0.6-test" Deken would only show that and would hide the stable release...
Or should we rather stop uploading test releases to Deken?
Christof
On 28.11.2021 15:59, Alexandre Torres Porres wrote:
Am 28. November 2021 14:57:53 MEZ schrieb Alexandre Torres Porres <porres@gmail.com>: And you're right, there's no "_Only show the newest version of a library (treats other versions like foreign architectures)_" checkbox
Hey, I thought you were being ironic telling me about a new box that doesn't exist, and now I see in fact there is a new box that says "_Only show the newest version of a library (treats other versions like foreign architectures)_"... and yeah, it is checked by default. I think this kind of unwarned change can be really confusing, see my case here :) it's a cool option, but maybe not checked by default?
Could you post a screenshot of the drken settings?
Here it is anyway, and, by the way, I also notice something else funny. It keeps force checking the "User-defined-platform" selection with that weird thing. I changed to "default", but when I restart Pd, there it is again. Bug found?
Screen Shot 2021-11-28 at 11.50.39.png
mfg.sfg.jfd IOhannes _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
Em dom., 28 de nov. de 2021 às 12:07, Christof Ressi info@christofressi.com escreveu:
Or should we rather stop uploading test releases to Deken?
don't think so :/
On Tue, 2021-11-23 at 14:06 -0300, Alexandre Torres Porres wrote:
- the symbol box by default now is much wider, I always have to make
it shorter, who needs that big boxes most the time? can't we make the same as before?
I like it bigger. I usually make the number boxes bigger for them to display the full available precision. So it's only fair you have to make symbol boxes smaller from now on... na na na naaa na...
But then, no need to fight over it, since these days it is so easy to drag them small/big.
Roman
Em ter., 23 de nov. de 2021 às 18:30, Roman Haefeli reduzent@gmail.com escreveu:
But then, no need to fight over it, since these days it is so easy to drag them small/big.
I forget