Hi,
2007/7/3, Mathieu Bouchard matju@artengine.ca:
On Mon, 2 Jul 2007, Thomas O Fredericks wrote:
I have been using the pmdtl folder namespaces for a year now and have NEVER had a similar problem. I tried replicating the example in a practical context, but I cannot. This issue is a theoretical problem that never happens in a practical context.
No, it's not theoretical, it's just false. There are problems that are similar to that, but knowing pd's implementation, I should've known better. See my mail to Patrice Colet today about this.
When inside an abstraction, let says foo/bar.pd, if you want to use an external that is named [bar], Pd complains : "error: bar: can't load abstraction within itself bar ... couldn't create"
And then, let say there is a "foo/counter.pd" in the same directory and that you wan to create a [counter], it will instanciate the "counter.pd" that is in that folder, and not the external that is in /usr/lib/pd/extra, for instance.
So yes, such a design is neither problems-free, nor a panacea, but so far our abstractions development has been overall facilitated a lot by the use of categories like these, and the Subversion repository that goto10.org is providing us.
Now, we'll change a few more things, and make it (finally) part of pd-extended. Don't hesitate to suggest a better suffix than "_" for the abstractions that provide a Graph-on-parent GUI, as we would like to change for a better one, if one exists. (maybe "$". "|", or "+", such as in "rgb$" or "rgb+" ?) Also, feel free to suggest some of your abstractions to be part of this.
By the way (regarding $args and $), I wrote a [flow/pak] that is a [pack] with all inlets hot ! (using dynamic patching)