what i think would be genuinely useful is a method for passing arguments to the parser *before* creation, or at least before the loadbang. currently the -send "receive-obj message", allows a method to communicate with a patch using runtime specific arguments, but as this message is only sent after the loadbang it is not much use for initialisation. i am thinking of something like #ifdef, which could perhaps behave like a [switch] for enabling execution of directives in a subpatch/abstraction, or a [spigot] blocking access to a chain..
this way the 'distro' specific directions are handled by distributing a .pdsettings file or something similar and anything 'distro' specific would be defined with a macro inside the patch. this would assure that necessary libs are loaded and any runtime execution can occur using such a -send replacement.. perhaps i am talking about the same thing hans, but i have misinterpreted you proposal?
on a similar note, i was wondering if there is an object that stores loaded class namespaces and which could be checked against with boolean output, so that i could gracefully provide fallback mechanisms if an object doesn't exist, or alternatively, provide extra functionality when an object does exist. for example, i have some work that uses the vasp lib extensively for non-realtime computation of sample buffers, but i have also written a fallback that can produce similar with vanilla objects. i would prefer use of vasp, but the patch still runs without, currently i am having to redirect using a spigot which is called using a '-send "VASP 0"', which really is not ideal.
dmotd
On Thursday 19 March 2009 10:23:19 Hans-Christoph Steiner wrote:
On Mar 18, 2009, at 8:06 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Then there could be also something like a 'maxmsp' distro for a compatibility mode. So I was thinking there could be a "#X declare -distro vanilla" that each distro saves into every file. It would be safely ignored for Pd versions that didn't support the -distro flag.
what would e.g. Pd-vanilla that supported a "-distro" flag do if it encountered a [declare -distro maxmsp]?
That would be up to Miller. Ignoring it would be one possibility.
furthermore: i don't think that it is good design to have [declare] accept _any_ arguments and ignore them at will (e.g. if it decides to not support "-distro", then it could either explicitely ignore "- distro" or accept any argument and only use those that it knows about.
I am not sure I follow what you are asking. The behavior of this would be dependent on the distro. So someone could quietly ignore all - distro flags, they could through warnings or errors, or do a little dance.
This distro flag would then setup the canvas-local namespace with the libraries as they are loaded for that distro.
in general, i think the idea tobe able to load named library-bundles is not such a bad idea. i imagine it (right now; but this could be total nonsense) to load snippets of preference-files (that are stored somewhere in the path).
e.g.
<snip> % cat ~/.pd/moko.prefs path: ~/pd/mokolib stdlib: rjdj
</snip>
and using [declare -loadbundle moko] would then add the path and lib to the canvas-local namespace.
gmsft IOhannes
I think that there should be some distro file format that could be placed in a folder to be installed and used. That way people could freely create and distribution their own.
I am thinking this isn't like a library, I think there would only be a handful of distros defined. I don't think this functionality would work so well with many, many distros but perhaps.
.hc
I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev