I was just thinking about loading libraries and namespaces. One thing that a lot of people want to do is have a default set of libraries loaded so that they are already in the global namespace and don't need declare/import or a namespace prefix. If you think of the included objectclasses and abstractions as objectclasses that are no different than any other, then we have something like this for a list of existing distros:
vanilla pd-externals (Debian package) pd-extended pure:dyne? (does this load some libs by default?) rjdj
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. This distro flag would then setup the canvas-local namespace with the libraries as they are loaded for that distro.
Just an idea that I wanted to through out there.
.hc
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
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]?
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.
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
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.
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
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.
ok. so what would Pd-extended do if it encountered a [declare -distro puredata] since this is up to you, what would you actually do? ignore it as well?
and if so, what would be the purpose of this little exercise?
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.
i was not asking for something.
but i thought the idea of this would be to make projects more portable, rather than generate error messages.
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.
this should have read: "in general, i think the idea tobe able to load named library-bundles is not a good idea."
though now i am not so sure about this anymore. if the only purpose of my suggestion was to have a named shorthand for loading libraries in a specific way, then it is rather useless. it should be possible to do this with [declare] as it is now. the benefit for having a single shortcut for a collection of libs seems to be rather small.
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.
what exactly do you mean with "distro"? is it the collection of objects it comes with? does it include modifications to the Pd-core as well?
I am thinking this isn't like a library, I think there would only be a handful of distros defined.
hmm, do i understand it correctly that by "a handful distros defined" you mean a fixed enumeration? i'm rather glad that Pd has an open plugin-concept, and miller did not decide a one time that [expr], [fiddle~] and [bonk~] were enough. (but then there would be no problems with nameclashes and distros and such)
just kidding of course.
but anyhow, how does it relate to "people could freely create"?
I don't think this functionality would work so well with many, many distros but perhaps.
if it does not work so well, then it's probably badly designed. so let's improve it's desgin.
and imagine: nameclashing distros!
fgamdsr IOhannes
#N canvas 303 243 775 513 10; #X declare -lib zexy; #X obj 157 115 operating_system; #X obj 189 182 select linux; #X obj 125 66 loadbang; #X obj 285 5 import zexy; #X obj 147 5 declare -lib zexy; #X obj 189 353 print [linux_mode]; #X text 18 5 depends on zexy:; #X obj 125 92 t b b; #X obj 125 194 i 0; #X obj 157 134 t b a; #X msg 270 204 ERROR: linux-mode is currently unsupported on $1; #X msg 157 153 1; #X obj 125 218 select 0; #X msg 125 292 ERROR: no zexy detected: refusing to switch to linux-mode ; #X connect 0 0 9 0; #X connect 1 1 10 0; #X connect 2 0 7 0; #X connect 7 0 8 0; #X connect 7 1 0 0; #X connect 8 0 12 0; #X connect 9 0 11 0; #X connect 9 1 1 0; #X connect 10 0 5 0; #X connect 11 0 8 1; #X connect 12 0 13 0; #X connect 13 0 5 0;
#N canvas 318 266 586 383 10; #X declare -lib zexy; #X obj 163 278 linux_mode; #X text 37 69 [linux_mode] will execute the current patch on a virtual machine running linux.; #X text 40 141 this allows you to use the powers of Linux on any platform. ; #X text 40 165 this object is still under develepment and should be considered "experimental". not all features are implemented yet.; #X text 50 240 useage:; #X text 122 238 put the object in your patch and re-load the patch. the patch will now run within a linux-environment.; #X text 34 101 for performance reasons , the patch will not be run within a VM , if you are already running linux.;
"puredata" doesn't seem like the best name for a distro, but I'd guess I say this distro would set up the environment to limit the libs to the Pd-vanilla objects. "pd-extended" would set up the default libs that are loaded in the current Pd-extended. For example, if you created [pow~] with the "pd-extended" distro, you'd get [cyclone/ pow~]. Maybe there could be something like "vanilla-0.41.4", then [pow~] would fail to create, but with "vanilla" you'd get the new [pow~].
The aim is to make for more compatibility across distros while allowing each distro to have its own default set of objects in the global namespace. Throwing error messages would just be one option as a response. I think that Pd-extended (Pd in general really) should be structured so that the vanilla objects are a library like any other library. But its nice having a common set of objects pre-loaded in the global namespace. That's what Pd/Max users are used to, so ideally we can find a way to support that as well as multiple distros, and keep things compatible.
.hc
On Mar 19, 2009, at 9:26 AM, IOhannes m zmoelnig wrote:
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.
ok. so what would Pd-extended do if it encountered a [declare -distro puredata] since this is up to you, what would you actually do? ignore it as well?
and if so, what would be the purpose of this little exercise?
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.
i was not asking for something.
but i thought the idea of this would be to make projects more portable, rather than generate error messages.
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.
this should have read: "in general, i think the idea tobe able to load named library-bundles is not a good idea."
though now i am not so sure about this anymore. if the only purpose of my suggestion was to have a named shorthand for loading libraries in a specific way, then it is rather useless. it should be possible to do this with [declare] as it is now. the benefit for having a single shortcut for a collection of libs seems to be rather small.
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.
what exactly do you mean with "distro"? is it the collection of objects it comes with? does it include modifications to the Pd-core as well?
I am thinking this isn't like a library, I think there would only be a handful of distros defined.
hmm, do i understand it correctly that by "a handful distros defined" you mean a fixed enumeration? i'm rather glad that Pd has an open plugin-concept, and miller did not decide a one time that [expr], [fiddle~] and [bonk~] were enough. (but then there would be no problems with nameclashes and distros and such)
just kidding of course.
but anyhow, how does it relate to "people could freely create"?
I don't think this functionality would work so well with many, many distros but perhaps.
if it does not work so well, then it's probably badly designed. so let's improve it's desgin.
and imagine: nameclashing distros!
fgamdsr IOhannes #N canvas 303 243 775 513 10; #X declare -lib zexy; #X obj 157 115 operating_system; #X obj 189 182 select linux; #X obj 125 66 loadbang; #X obj 285 5 import zexy; #X obj 147 5 declare -lib zexy; #X obj 189 353 print [linux_mode]; #X text 18 5 depends on zexy:; #X obj 125 92 t b b; #X obj 125 194 i 0; #X obj 157 134 t b a; #X msg 270 204 ERROR: linux-mode is currently unsupported on $1; #X msg 157 153 1; #X obj 125 218 select 0; #X msg 125 292 ERROR: no zexy detected: refusing to switch to linux- mode ; #X connect 0 0 9 0; #X connect 1 1 10 0; #X connect 2 0 7 0; #X connect 7 0 8 0; #X connect 7 1 0 0; #X connect 8 0 12 0; #X connect 9 0 11 0; #X connect 9 1 1 0; #X connect 10 0 5 0; #X connect 11 0 8 1; #X connect 12 0 13 0; #X connect 13 0 5 0; #N canvas 318 266 586 383 10; #X declare -lib zexy; #X obj 163 278 linux_mode; #X text 37 69 [linux_mode] will execute the current patch on a virtual machine running linux.; #X text 40 141 this allows you to use the powers of Linux on any platform. ; #X text 40 165 this object is still under develepment and should be considered "experimental". not all features are implemented yet.; #X text 50 240 useage:; #X text 122 238 put the object in your patch and re-load the patch. the patch will now run within a linux-environment.; #X text 34 101 for performance reasons , the patch will not be run within a VM , if you are already running linux.;
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-
dmotd -
Hans-Christoph Steiner -
IOhannes m zmoelnig