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
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
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:
I think, you should just put these as feature requests into the Bug Tracker. Then if someone (Miller, others) is looking for ideas to improve Pd, one could just go through the tracker and take whatever seems doable ATM.
- [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).
I already added a bug report regarding declare, however not for the behaviour you describe now. I don't necessarily think, that [declare] instructions should dive down into abstractions that are used in a patch. As I understand it [declare] is only applied for the current patch or even canvas.
The bug I reported was, that declare doesn't work correctly when used inside an abstraction.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2007-05-28 at 16:49 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
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:
I think, you should just put these as feature requests into the Bug Tracker. Then if someone (Miller, others) is looking for ideas to improve Pd, one could just go through the tracker and take whatever seems doable ATM.
aha, ok. i'll do that. thanks for the hint.
- [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).
I already added a bug report regarding declare, however not for the behaviour you describe now. I don't necessarily think, that [declare] instructions should dive down into abstractions that are used in a patch. As I understand it [declare] is only applied for the current patch or even canvas.
The bug I reported was, that declare doesn't work correctly when used inside an abstraction.
hm... then obviously we misunderstood each other in the previous thread. anyway, you found a bug and it is in the tracker now. i hoped, that i can get rid of the startup options with [declare], so that pd doesn't need additional flags for running netpd. but this means, that it is not possible (or i need to add a [declare] in every patch and every abs, which is a bit awkward).
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i hoped, that i can get rid of the startup options with [declare], so that pd doesn't need additional flags for running netpd. but this means, that it is not possible (or i need to add a [declare] in every patch and every abs, which is a bit awkward).
Recursive declares could be a problem, if you'd use an abstraction, that in turn needs a different declare, possibly with a nameclash.
Say you'd want to use Cyclone's counter and "declare -lib cyclone". An abstraction you use may want to use cxc's counter. With recursive declares, this could generate a nameclash in that abstraction.
A way out would be a hierarchical system for declares, but that's even farther.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Mon, 2007-05-28 at 20:30 +0200, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
i hoped, that i can get rid of the startup options with [declare], so that pd doesn't need additional flags for running netpd. but this means, that it is not possible (or i need to add a [declare] in every patch and every abs, which is a bit awkward).
Recursive declares could be a problem, if you'd use an abstraction, that in turn needs a different declare, possibly with a nameclash.
Say you'd want to use Cyclone's counter and "declare -lib cyclone". An abstraction you use may want to use cxc's counter. With recursive declares, this could generate a nameclash in that abstraction.
A way out would be a hierarchical system for declares, but that's even farther.
Ciao
hm, it's not that i wanted to use [declare]'s inside abstractions and it turned out, that it is not necessary at all (at least for what i want). but every patch needs a [declare -path], whereas only one (the first loaded) patch needs a [declare -lib]. i find that inconsistent.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Roman Haefeli wrote:
Ciao
hm, it's not that i wanted to use [declare]'s inside abstractions and it turned out, that it is not necessary at all (at least for what i want). but every patch needs a [declare -path], whereas only one (the first loaded) patch needs a [declare -lib]. i find that inconsistent.
apart from the fact, that it IS inconsistant, i cannot follow your arguing.
you are correct that only the "first loaded" patch MUST contain the [declare -lib]. but since you do not know which patch is loaded first (at least you should not assume that you do know), i would suggest that all patches depending on a library SHOULD contain the [declare -lib].
and hopefully(?) in the future there will be some more locality...
mfg.sdft IOhannes
On Tue, 2007-05-29 at 09:54 +0200, IOhannes m zmoelnig wrote:
you are correct that only the "first loaded" patch MUST contain the [declare -lib]. but since you do not know which patch is loaded first (at least you should not assume that you do know), i would suggest that all patches depending on a library SHOULD contain the [declare -lib].
and hopefully(?) in the future there will be some more locality...
i was thinking about projects, that have kind of a main patch. from that 'main' patch all other patches are opened dynamically (there are such projects besides netpd, afaik). with such a structure, you reliably know, which patch was opened first (maybe it just doesn't make sense to open another patch first, because all patches are dependent on the 'main' patch).
anyway, this might be already a too 'specialized' (read: too less general) application.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
Frank Barknecht -
IOhannes m zmoelnig -
Roman Haefeli