"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