[PD] proposals for src/notes.txt

[Roman Haefeli]

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