Well, I've been trying to stay out of this, but here's a thing... someone could implement a "msg" object that you could invoke like [msg 1 $0 3] to get a message with a 'true' $0 built into it. This would also work for $1, etc, so would be much smarter than changing the message box semantics.
But then the question is, how would you allow message-box-style $ substitutions? OK, we can do this:
[msg $1 #1]
which would be the exact reverse of Max's #1 convention - #1 could be the message-box $1.
I've shrunk from actually doing this, not just because it makes my teeth hurt, but also because... shouldn't this be expanded into a full-on scripting language? And what then would be its relationship with the expr family? It quickly got too deep for me to figure out what would be a good, canonical solution.
cheers Miller
On Mon, Apr 02, 2018 at 08:55:58PM +0200, Roman Haefeli wrote:
yawn.....
On Son, 2018-04-01 at 17:42 -0300, Alexandre Torres Porres wrote:
Hi, currently, if you want to use $0, you need an object cause it becomes "0" when it's inside messages.
Pd-l2ork and Purr Data implemented a way that $0 works in the same way as in objects than in messages, and I think it is a great feature, as many patches can be significantly simplified. I guess most Pd users here know what I'm talking about.
By implementing that, you would once forever prohibit the proper way to expand $0 which is expanding to the selector of the message. That's why I oppose your proposition. (Actually, it doesn't matter whether I'm opposing it or not since I don't contribute any Pd code. But I can at least point to the fallacies.)
I absolutely see the convenience of your proposition, but there would be no good explanation for it. Consider it a bad coincidence that both kinds of variables use a dollar prefix, there is nothing in common between them (expanding to creation arguments versus expanding to atoms of messages). Personally, I would totally find it convenient if Pi was an integer number, it would make so many things so much easier.Â
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list