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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
