Hello again list,
What do y'all think of the idea of releasing Pd-extended both as a "core" pd with no libraries added except maybe the libdir and hex loaders and as a version with multiple libraries (2 release stages)? Perhaps it's been discussed. the thing I enjoy about Extended is the features it adds to pd-vanilla, and this way people can just keep the same libraries installed in the same places and switch between vanilla and extended easier. In my experience I never need/want to use most of the arbitrary libraries included and/or loaded on startup and could easily download and install the ones I do want. I also see the appeal/logic of using a standardized set of libs though.
seems like a reasonable way to develop it too... everyone focusing on the core and then working on their own libs for a bundled release.
Also about import/saving libraries to load on startup: wouldn't it make more sense if either the list were editable or there were no list? Strange that users get this arbitrary list to load on startup, (not even all the libs included in PdX) without being able to edit it, a set of libs that they never have to [import], but then they're expected to [import] everything else unless they manually edit the preferences file (quite confusing for most users)?
Btw I also have a bit of time and know a little bit of c and tcl, i'd be glad to pitch in where i can when there is a concrete plan (list of to-do's) of how to move forward with Pd-extended.
-Sebastian
On 09/29/2014 06:10 PM, Seb Shader via Pd-list wrote:
Hello again list,
What do y'all think of the idea of releasing Pd-extended both as a "core" pd with no libraries added except maybe the libdir and hex loaders and as a version with multiple libraries (2 release stages)? Perhaps it's been discussed. the thing I enjoy about Extended is the features it adds to pd-vanilla, and this way people can just keep the same libraries installed in the same places and switch between vanilla and extended easier. In my experience I never need/want to use most of the arbitrary libraries included and/or loaded on startup and could easily download and install the ones I do want. I also see the appeal/logic of using a standardized set of libs though.
seems like a reasonable way to develop it too... everyone focusing on the core and then working on their own libs for a bundled release.
Also about import/saving libraries to load on startup: wouldn't it make more sense if either the list were editable or there were no list? Strange that users get this arbitrary list to load on startup, (not even all the libs included in PdX) without being able to edit it, a set of libs that they never have to [import], but then they're expected to [import] everything else unless they manually edit the preferences file (quite confusing for most users)?
Arbitrary or not, the users who learned Pd by using Pd-extended exclusively assumed that these default loaded classes were the "standard" libs that were available in Pd. So you have an enormous number of patches and abstractions out there which do not use [import] or [declare] to load libs (nor do they prefix the objects with the libdir like [zexy/time] or [hcs/canvas_name].)
If you throw those default loaded libs down the memory hole, you end up making all kinds of work for the user who wants to use an arbitrary patch or abstraction-- maybe one from Pd forum, the mailing list, an individual's website, a tutorial, or somewhere else. That user very likely doesn't care about the "right" way to load libs, or more sensible default behavior in the next release of Pd-extended. They just want a patch or abstraction to load without broken objects.
On the other hand-- I'm pretty sure you can edit the list, either in the preferences file (named something like .pdsettings on a Linux distro) or in the path and startup dialogs.
-Jonathan
Btw I also have a bit of time and know a little bit of c and tcl, i'd be glad to pitch in where i can when there is a concrete plan (list of to-do's) of how to move forward with Pd-extended.
-Sebastian
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi all,
I have created a page on http://puredata.info/dev/pdextended listing
the people interested (or the people that can help but are busy). I
will keep this page updated. Anyone with c / tlc / build farm /
continuous integration / ideas / time please chime in (create an
account https://puredata.info/join_form and edit the page or let me
know).
It is not much for now, but it's a starting point. Cheers~
Some questions about the bullet points on the page:
- update the libraries to the latest version, and test them
Aren't they updated by virtue of pulling from the latest svn? If I can get Pd-extended to compile, what else do I need to do in order to update the libs?
- pull in relevant commits from pd-vanilla (you can't just pull them all in because vanilla does the GUI stuff differently, and Pd-extended
has promised pixel-exact sizing on all platforms for a few releases now).
Does this refer to the single-line change in pd-gui.tcl pertaining to the font scaling, or something bigger? If it's something bigger then that's a real drag.
- fix platform-specific bugs
Are the auto-builds still around? If not, is there a guide to setting up a nightly build environment?
- finish splitting out all the core objects into standalone library
(this is mostly done, that makes it a lot easier to keep pd-extended's core updated with pd-vanilla commits since all of the objects are a separate library that is taken directly from vanilla).
How is this easier than not doing any work splitting out the internal objects? (The fact that it is not finished leads me to believe it is not easier.)
-Jonathan
On Tuesday, September 30, 2014 6:49 AM, "puredata@11h11.com" puredata@11h11.com wrote:
Hi all,
I have created a page on http://puredata.info/dev/pdextended listing
the people interested (or the people that can help but are busy). I
will keep this page updated. Anyone with c / tlc / build farm /
continuous integration / ideas / time please chime in (create an
account https://puredata.info/join_form and edit the page or let me
know).
It is not much for now, but it's a starting point. Cheers~
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-09-30 04:39, Jonathan Wilkes via Pd-list wrote:
- pull in relevant commits from pd-vanilla (you can't just pull
them all in because vanilla does the GUI stuff differently,
does it?
fgmasdr IOhannes
Those bullet points are from the webpage, not written by me. My questions about the bullet points were inline, e.g.:
Does this refer to the single-line change in pd-gui.tcl pertaining to
the font scaling, or something bigger? If it's something bigger then that's a real drag.
And by "font scaling" I mean "tk scaling 1" in pd-gui.tcl
-Jonathan
On Tuesday, September 30, 2014 3:43 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-09-30 04:39, Jonathan Wilkes via Pd-list wrote:
- pull in relevant commits from pd-vanilla (you can't just pull
them all in because vanilla does the GUI stuff differently,
does it?
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-09-30 15:32, Jonathan Wilkes via Pd-list wrote:
Those bullet points are from the webpage, not written by me. My questions about the bullet points were inline, e.g.:
ah sorry.
my email client seems to have messed up with quoting (at least it wasn't clear to me which was the quote and which was your comment/question).
fgmasdr IOhannes
I don't remember the details on the differences. Pd-extended guarantees pixel
sizes of boxes across platforms and releases (if not, its a bug). One way it
does that is using tk scaling 1. I believe that was removed in vanilla.
There are probably other details like this, like related to support Tcl/Tk 8.5
and 8.6, and supporting Tk/Cocoa/64-bit.
.hc
Jonathan Wilkes via Pd-list wrote:
Those bullet points are from the webpage, not written by me. My questions about the bullet points were inline, e.g.:
Does this refer to the single-line change in pd-gui.tcl pertaining to
the font scaling, or something bigger? If it's something bigger then that's a real drag.
And by "font scaling" I mean "tk scaling 1" in pd-gui.tcl
-Jonathan
On Tuesday, September 30, 2014 3:43 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
On 2014-09-30 04:39, Jonathan Wilkes via Pd-list wrote:
- pull in relevant commits from pd-vanilla (you can't just pull
them all in because vanilla does the GUI stuff differently,
does it?
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
N�n�r����)em�h�yhiם�w^��
Those bullet points are from the webpage, not written by me. My questions about the bullet points were inline, e.g.:
Does this refer to the single-line change in pd-gui.tcl pertaining to
the font scaling, or something bigger? If it's something bigger then that's a real drag.
And by "font scaling" I mean "tk scaling 1" in pd-gui.tcl
-Jonathan
On Tuesday, September 30, 2014 3:43 AM, IOhannes m zmoelnig zmoelnig@iem.at wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-09-30 04:39, Jonathan Wilkes via Pd-list wrote:
- pull in relevant commits from pd-vanilla (you can't just pull
them all in because vanilla does the GUI stuff differently,
does it?
fgmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Jonathan Wilkes via Pd-list wrote:
Some questions about the bullet points on the page:
- update the libraries to the latest version, and test them
Aren't they updated by virtue of pulling from the latest svn? If I can get Pd-extended to compile, what else do I need to do in order to update the libs?
Pd-extended releases do not automatically pull in everything from the latest SVN. In terms of the included library, a Pd-extended release starts with the previous release. Then individual libraries must be updated based on a new release of that library. This kind of process is key to having a stable, reliable set of libraries. More info here:
http://puredata.info/docs/developer/GettingIntoPdextended
.hc
Seb Shader via Pd-list wrote:
Hello again list,
What do y'all think of the idea of releasing Pd-extended both as a "core" pd with no libraries added except maybe the libdir and hex loaders and as a version with multiple libraries (2 release stages)? Perhaps it's been discussed. the thing I enjoy about Extended is the features it adds to pd-vanilla, and this way people can just keep the same libraries installed in the same places and switch between vanilla and extended easier. In my experience I never need/want to use most of the arbitrary libraries included and/or loaded on startup and could easily download and install the ones I do want. I also see the appeal/logic of using a standardized set of libs though.
seems like a reasonable way to develop it too... everyone focusing on the core and then working on their own libs for a bundled release.
That is definitely the goal of Pd-extended, I couldn't have said it better myself. :-) It is purely a matter of someone doing the work. With two little kids and full time programming work, I have little spare cycles for programming these days. But I'll happily help anyone who wants to take on part of all of making this happen.
Also about import/saving libraries to load on startup: wouldn't it make more sense if either the list were editable or there were no list? Strange that users get this arbitrary list to load on startup, (not even all the libs included in PdX) without being able to edit it, a set of libs that they never have to [import], but then they're expected to [import] everything else unless they manually edit the preferences file (quite confusing for most users)?
The libraries that are loaded by default are an oooold legacy of the beginning of Pd-extended. It should be removed, but it needs to be done in a way that is transparent when people update. Or maybe it makes sense now to just start fresh. When I get back to it, I won't be working that arrangement of crufty old libraries loaded by default. Instead the way forward is to make a new standard library that does things consistently and correctly across the whole library, while only maintaining backward compatibility when it doesn't get in the way of the primary goal.
Btw I also have a bit of time and know a little bit of c and tcl, i'd be glad to pitch in where i can when there is a concrete plan (list of to-do's) of how to move forward with Pd-extended.
Excellent! Here is the page that I maintained for release goals:
http://puredata.info/dev/NextRelease
.hc
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
puredata＠11h11.com -
sebfumaster＠aol.com