Actually it occured to me that this is a silly argument, which I could
only bring up, because I'm living proof that creating non-trivial Pd
patches for 6 years is possible without ever using namecanvas once.
One could also create non-trivial Pd patches for 6 years and not use data structures once (or even DSP objects), this does not mean they are useless : ).
It's silly, because of course one would normally not want to clear the
main canvas of an abstraction altogether as that would also clear the
logic to fill the canvas again, and this logic generally would be in
the abstraction itself.
> This restriction leads to really ugly workarounds.
Second silly argument: dynamically patching an abstracion instance
would still be ugly even when namcanvas was a property, as you'd still
need to keep track of how many objects your logic (see above) contains
and you would not be allowed to change it.
Ugly it may be but we've established that there are certain things that are impossible without namecanvas, such as my most recent [msend]/[mreceive] with variable inlets/outlets, or Chris McCormick's patches that do dynamic GOP.
Not to mention, look at this!
That would make it a lot less painful. Even better would be allowing us to assign identifiers to objects or groups of objects for stable manipulation... but the above is a huge help.
So, I am very much in support of moving namecanvas to the canvas properties window, and I hope we can agree that it is an essential feature (rereading, maybe that is what you were trying to say after all, but I don't mind campaigning for it anyways : ) ).
