[PD-dev] [ pure-data-Feature Requests-3561715 ] Why not %.. instead of $.. ?? ..and more..
SourceForge.net
noreply at sourceforge.net
Sat Aug 25 17:29:27 CEST 2012
Feature Requests item #3561715, was opened at 2012-08-25 08:29
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3561715&group_id=55736
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Why not %.. instead of $.. ?? ..and more..
Initial Comment:
Maybe it is too obvious, but not to me..
1. Why don't we use "%.." as in the [makefilename] in [msg('s as well?? Most new people seem to have problems with "$" inside and outside of [msg('s...
2. forget "1.": What's about a message-object?? I don't mean a "[message(" but a "[message]"!
It would have some advantages over the [msg(. E.g one could replace it with something else by rewriting the content instead of deleting the [msg( and it's connections and creating another object and it's connections at it's place.
Furthermore besides the actual message, the object could take one symbol as an argument. This would be a user-defined placeholder for inlets or something like this.. just as "$.." does in [msg('s or [expr].
The advantage is obviously that the user can choose a symbol that is not content of the message.
So in the end one would have something like this:
[it costs $1$( , would become
[%, it costs %1$]
I know it works with "external" symbols, too. But that's rather a workaround, isnt it?? ...e.g. [pack f s]--[it costs $1$2 ( etc...
Any opinions, whether pro or contra??
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478073&aid=3561715&group_id=55736
More information about the Pd-dev
mailing list