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 > [email protected] > http://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
