hi all, hi miller
i just had a look at src/notes.txt and many of my longterm desires are mentioned there (especially [vthreshold~], [vreadsf~], [closebang], disabling scrollbars and menus, and many other things...)
but there are still things left, which i consider to be (even more) essential for pd and for which i strongly hope that they make it into src/notes.txt. here a short list, where i also try to explain, why i think, these issues are essential:
- new object [symbol2list] (maybe called differently?)
since the introduction of [list], pd's message and string handling became much stronger, even more since the behaviour of messageboxes changed, that made it possible to use dollargs within a string. since then, basic string handling seems to be a task, that can be done fully inside of pd, without having to use externals, BUT there is still no way to split symbols into lists. if that would be implemented into pd, one could claim without bad conscious, that basic string handling could be fully done with pure internals. so for completeness' sake, it would be nice, if such functionality would make it into pd.
- [open(-msg to pd needs an option to set path relative to patch
the situation now is, that the path (second argument) to the open-message is relative to the start location. since there is no way to get the start-location path in pd, i can't see, in which case this behaviour could be useful. in contrary: this behaviour makes it difficult to distribute pd-projects (set of patches), that do use the [; pd open(-message, since the pd's start location is different on each system, and even if it would be the same on every system, a user would be forced to put the pd-files to certain location, so that the hardcoded relative path is valid. if the path would be relative to the parent patch, pd-projects would work out of the box, independently from pd's start location. afaik, netpd is not the only project, that suffers from this problem. now, a (in my eyes) quite ugly workaround needs to be used: an external config-file to set absolute path of the project folder, that needs to be edited by the user.
- [declare]: '-path' does affect only parent patch, not all patches
i don't know, if this behaviour is intended (frank barknecht declared it to be a bug once). anyway, for projects consisting of a set of patches and abstractions, it would seem to make sense, if the [declare]d abstraction would be available to all patches, that are openend subsequently, so that such projects could be shared easily.
i know, i am repeating myself, but the above things are important to me (and, i think, to pd-projects in general) and i never got an answer yet, if they are planned to be implemented in future versions of pd. i consider the ability to distribute pd-projects to be one of the strong and important points of pd (besides the compatibility across os') and therefore it would be nice, if at least the last two points could make it into pd. i'd really appreciate to get a feedback on these proposals. if i know, that [open(-message with a path relative to path never will make it into pd, i can start thinking about using a standardized set of externals ([getdir] and maybe others) in my projects to overcome these issues.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de