On 09/02/14 16:34, Jonathan Wilkes wrote:
On 02/08/2014 11:44 PM, Simon Wise wrote:
...
It would be nice to be able to do this natively, especially since many Pd programmers are not that familiar with procedural programming. It is certainly practical and worthwhile to extend Pd for this but that requires some of the things that have been long put off till later for a very very long time. Meanwhile the Lua external provides the way to do what remains problematic natively (as much due to policy as anything else) and anyone capable of adding functionality to Pd will find it much much easier to use Lau than to engage in a huge and perhaps fruitless effort to push it into Pd.
It sounds like you are rationalizing and encouraging non-development.
More pointing out the frustrations that have been experienced in the past, and noting that decisions about what is added to Pd core are very consistent and are very careful, cautious and slow in these areas in particular. As you pointed out adding something like a string type without introducing it to [print] is not good, so ... you use clumsy workarounds that don't actually allow strings in messages, perhaps just pointers to stings with arcane results in [print] ... or write a bunch of replacement core objects that recognise strings to use within the library such as [stringprint] etc ... or use a fork with enhanced types and core objects that may or may not be compatible with some eventual core string type.
It may be worth enhancing pd-l2ork this way as it has already departed considerably from pd, their choice has been to speed up development by bypassing these issues and pushing ahead without integration with core Pd, but I think adding strings confined to a small set of string-aware objects which remain otherwise compatible with vanilla the way gridflow added matrices isn't worth it, there is a much greater pay-off with matrices ... gridflow is a huge project with a very substantial library of matrix operations, while the authors long ago abandoned hope of their efforts being included in vanilla and develop in parallel. Development effort on a smaller scale is probably better spent in ways that will integrate with core pd, and there are plenty of those ... including your own solid efforts.
But it also sounds like we agree that there is nothing about boxes of text connected with lines that makes string manipulation more difficult than lines of text.
Absolutely, just the absence of a well defined string type that can be sent down those lines. Arguments advancing the addition of a string selector to Pd core are very worthwhile, I guess probably on pd-dev? it ultimately is a discussion with Miller. There was a link to something being worked on currently, earlier in this thread.
Simon