I am thinking for the next release of Pd-extended, that the preferences panels for loading libs and adding paths should be removed. [import] and [declare] cover all it can do in a better way, and people who really want to have libs and paths loaded globally on start-up can use either a manually written preferences file or the command line flags.
I could see maybe keeping the paths GUI, but I don't see any good reasons to keep the startup libs GUI. Anyone have objections?
.hc
you'll have lots of newbies complaining that their objects don't load? (it's a good way to force everyone to use namespaces)
I am thinking for the next release of Pd-extended, that the preferences panels for loading libs and adding paths should be removed. [import] and [declare] cover all it can do in a better way, and people who really want to have libs and paths loaded globally on start-up can use either a manually written preferences file or the command line flags.
I could see maybe keeping the paths GUI, but I don't see any good reasons to keep the startup libs GUI. Anyone have objections?
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
For next Pd-extended release, the same set of libraries that have been loading automatically at start-up would continue to be loaded as usual. It is just that there wouldn't be a GUI for people to modify that list of libraries that are loaded at startup. I think most Pd-extended users don't use the startup libs preference already, so I am guessing most people wouldn't notice.
.hc
On Sunday, September 18, 2011 8:09 PM, "João Pais" jmmmpais@googlemail.com wrote:
you'll have lots of newbies complaining that their objects don't load? (it's a good way to force everyone to use namespaces)
I am thinking for the next release of Pd-extended, that the preferences panels for loading libs and adding paths should be removed. [import] and [declare] cover all it can do in a better way, and people who really want to have libs and paths loaded globally on start-up can use either a manually written preferences file or the command line flags.
I could see maybe keeping the paths GUI, but I don't see any good reasons to keep the startup libs GUI. Anyone have objections?
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Hi Hans -
Perhaps better would be to make it read-only so one can query it.
I'm not sure, but there still might be complications for people switching back and forth between vanilla and extended, for example, which would be easiest to resolve if the GUI tools were there :)
M
On Sun, Sep 18, 2011 at 03:31:41PM -0400, Hans-Christoph Steiner wrote:
For next Pd-extended release, the same set of libraries that have been loading automatically at start-up would continue to be loaded as usual. It is just that there wouldn't be a GUI for people to modify that list of libraries that are loaded at startup. I think most Pd-extended users don't use the startup libs preference already, so I am guessing most people wouldn't notice.
.hc
On Sunday, September 18, 2011 8:09 PM, "João Pais" jmmmpais@googlemail.com wrote:
you'll have lots of newbies complaining that their objects don't load? (it's a good way to force everyone to use namespaces)
I am thinking for the next release of Pd-extended, that the preferences panels for loading libs and adding paths should be removed. [import] and [declare] cover all it can do in a better way, and people who really want to have libs and paths loaded globally on start-up can use either a manually written preferences file or the command line flags.
I could see maybe keeping the paths GUI, but I don't see any good reasons to keep the startup libs GUI. Anyone have objections?
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
To see which libraries Pd-extended is loading at startup, you can switch to the 'debug' view in the log, and you'll see:
libdir loader 1.9 compiled on Sep 19 2011 at 03:25:20 compiled against Pd version 0.43.1.extended-20110919 libdir_loader: added 'vanilla' to the global objectclass path libdir_loader: added 'extra' to the global objectclass path GEM: Graphics Environment for Multimedia GEM: ver: 0.93.SVN rev4516 GEM: compiled: Sep 19 2011 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: Cyrille Henry GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage http://gem.iem.at/ GEM: bug-tracker http://sourceforge.net/projects/pd-gem/ GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/ GEM: compiled for SIMD architecture: SSE2 MMX GEM: using SSE2 optimization libdir_loader: added 'cyclone' to the global objectclass path libdir_loader: added 'zexy' to the global objectclass path
.hc
On Sep 19, 2011, at 1:26 PM, Miller Puckette wrote:
Hi Hans -
Perhaps better would be to make it read-only so one can query it.
I'm not sure, but there still might be complications for people switching back and forth between vanilla and extended, for example, which would be easiest to resolve if the GUI tools were there :)
M
On Sun, Sep 18, 2011 at 03:31:41PM -0400, Hans-Christoph Steiner wrote:
For next Pd-extended release, the same set of libraries that have been loading automatically at start-up would continue to be loaded as usual. It is just that there wouldn't be a GUI for people to modify that list of libraries that are loaded at startup. I think most Pd-extended users don't use the startup libs preference already, so I am guessing most people wouldn't notice.
.hc
On Sunday, September 18, 2011 8:09 PM, "João Pais" jmmmpais@googlemail.com wrote:
you'll have lots of newbies complaining that their objects don't load? (it's a good way to force everyone to use namespaces)
I am thinking for the next release of Pd-extended, that the preferences panels for loading libs and adding paths should be removed. [import] and [declare] cover all it can do in a better way, and people who really want to have libs and paths loaded globally on start-up can use either a manually written preferences file or the command line flags.
I could see maybe keeping the paths GUI, but I don't see any good reasons to keep the startup libs GUI. Anyone have objections?
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-- Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
Just a silly idea... (attached)
Andras
On Mon, Sep 19, 2011 at 19:32, Hans-Christoph Steiner hans@at.or.at wrote:
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
To see which libraries Pd-extended is loading at startup, you can switch to the 'debug' view in the log, and you'll see:
libdir loader 1.9 compiled on Sep 19 2011 at 03:25:20 compiled against Pd version 0.43.1.extended-20110919 libdir_loader: added 'vanilla' to the global objectclass path libdir_loader: added 'extra' to the global objectclass path GEM: Graphics Environment for Multimedia GEM: ver: 0.93.SVN rev4516 GEM: compiled: Sep 19 2011 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: Cyrille Henry GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage http://gem.iem.at/ GEM: bug-tracker http://sourceforge.net/**projects/pd-gem/http://sourceforge.net/projects/pd-gem/ GEM: mailing-list http://lists.puredata.info/**listinfo/gem-dev/http://lists.puredata.info/listinfo/gem-dev/ GEM: compiled for SIMD architecture: SSE2 MMX GEM: using SSE2 optimization libdir_loader: added 'cyclone' to the global objectclass path libdir_loader: added 'zexy' to the global objectclass path
.hc
On Sep 19, 2011, at 1:26 PM, Miller Puckette wrote:
Hi Hans -
Perhaps better would be to make it read-only so one can query it.
I'm not sure, but there still might be complications for people switching back and forth between vanilla and extended, for example, which would be easiest to resolve if the GUI tools were there :)
M
On Sun, Sep 18, 2011 at 03:31:41PM -0400, Hans-Christoph Steiner wrote:
For next Pd-extended release, the same set of libraries that have been loading automatically at start-up would continue to be loaded as usual. It is just that there wouldn't be a GUI for people to modify that list of libraries that are loaded at startup. I think most Pd-extended users don't use the startup libs preference already, so I am guessing most people wouldn't notice.
.hc
On Sunday, September 18, 2011 8:09 PM, "João Pais" jmmmpais@googlemail.com wrote:
you'll have lots of newbies complaining that their objects don't load? (it's a good way to force everyone to use namespaces)
I am thinking for the next release of Pd-extended, that the preferences panels for loading libs and adding paths should be removed. [import] and [declare] cover all it can do in a better way, and people who really want to have libs and paths loaded globally on start-up can use either a manually written preferences file or the command line flags.
I could see maybe keeping the paths GUI, but I don't see any good reasons to keep the startup libs GUI. Anyone have objections?
.hc
That would be one approach...
.hc
On Sep 19, 2011, at 8:02 PM, András Murányi wrote:
Just a silly idea... (attached)
Andras
On Mon, Sep 19, 2011 at 19:32, Hans-Christoph Steiner hans@at.or.at wrote:
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
To see which libraries Pd-extended is loading at startup, you can switch to the 'debug' view in the log, and you'll see:
libdir loader 1.9 compiled on Sep 19 2011 at 03:25:20 compiled against Pd version 0.43.1.extended-20110919 libdir_loader: added 'vanilla' to the global objectclass path libdir_loader: added 'extra' to the global objectclass path GEM: Graphics Environment for Multimedia GEM: ver: 0.93.SVN rev4516 GEM: compiled: Sep 19 2011 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: Cyrille Henry GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage http://gem.iem.at/ GEM: bug-tracker http://sourceforge.net/projects/pd-gem/ GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/ GEM: compiled for SIMD architecture: SSE2 MMX GEM: using SSE2 optimization libdir_loader: added 'cyclone' to the global objectclass path libdir_loader: added 'zexy' to the global objectclass path
.hc
On Sep 19, 2011, at 1:26 PM, Miller Puckette wrote:
Hi Hans -
Perhaps better would be to make it read-only so one can query it.
I'm not sure, but there still might be complications for people switching back and forth between vanilla and extended, for example, which would be easiest to resolve if the GUI tools were there :)
M
On Sun, Sep 18, 2011 at 03:31:41PM -0400, Hans-Christoph Steiner wrote:
For next Pd-extended release, the same set of libraries that have been loading automatically at start-up would continue to be loaded as usual. It is just that there wouldn't be a GUI for people to modify that list of libraries that are loaded at startup. I think most Pd-extended users don't use the startup libs preference already, so I am guessing most people wouldn't notice.
.hc
On Sunday, September 18, 2011 8:09 PM, "João Pais" jmmmpais@googlemail.com wrote: you'll have lots of newbies complaining that their objects don't load? (it's a good way to force everyone to use namespaces)
I am thinking for the next release of Pd-extended, that the preferences panels for loading libs and adding paths should be removed. [import] and [declare] cover all it can do in a better way, and people who really want to have libs and paths loaded globally on start-up can use either a manually written preferences file or the command line flags.
I could see maybe keeping the paths GUI, but I don't see any good reasons to keep the startup libs GUI. Anyone have objections?
.hc
<Startup...disable- plugin.tcl>_______________________________________________ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
News is what people want to keep hidden and everything else is publicity. - Bill Moyers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
so the idea is to have tons of error messages when using pd-vanilla, of the kind: "import zexy... couldn't create" so that the user knows that they have to load the "zexy" library and henceforth ignore the "import zexy" line and only check the remaining "import foobar...couldn't create"?
i seem to remember that there was a recent email saying that "a patch relying on an error" was not to be considered as correct.
fgmasdr IOhannes
Whenever I see the words "this would _make_ people"... alarm bells start ringing for me.
Yes, the proposed behaviour is perfectly correct, logical, and consistent. And utterly the wrong thing to do IMHO.
It would frighten off newcomers and disorientate students.
It's why we create the cushion of fairy stories for kids, to soften the harsh realities of the _actual_ world. Later on you learn that there isn't a magic library fairy that loads everything, but it helps you cope with the first steps.
If anybody made PD that broken out of the box it would require lots of work to fix in order to make it fit to teach with again.
On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
Please give an example of how this would make this more confusing. My experience is the exact opposite and it is exactly this problem that leads me to want to remove those preferences. The are a big source of confusion and problems, and most Pd-extended users do not use them. I am not proposing removing them from Pd-vanilla, only Pd-extended. I think globally loading libraries is a broken idea.
If you remember in the days before Pd-extended, patches that relied on external libraries were mostly unsharable. It could take a long time to track down all the dependencies, etc. and you couldn't be sure which [wrap], [split], [prepend], [scale], etc. the patch needed. Having the configuration in the patch means at worst you know what you need to get it running.
At this point I've taught Pd to 10 year olds, high school kids, college kids, masters students, and all sorts of people in workshops, college courses, and patching circles. I also answer a lot of questions on email, on forums, and on IRC. It is from this experience that I am coming from on this issue. I have no desire to control people, I do have a strong desire to make Pd-extended very user friendly to newbies and a excellent editing experience for advanced users.
And those that like the Pd-vanilla way are welcome to use it, Pd-extended will remain compatible with patches from Pd-vanilla as long as I work on it. Of course, it is not possible to maintain 100% compatibility when going from Pd-extended to Pd-vanilla since extended includes many more objects. There is also pd-l2ork, desiredata, etc. for those who want different approaches.
.hc
On Tue, 2011-09-20 at 13:02 +0100, Andy Farnell wrote:
Whenever I see the words "this would _make_ people"... alarm bells start ringing for me.
Yes, the proposed behaviour is perfectly correct, logical, and consistent. And utterly the wrong thing to do IMHO.
It would frighten off newcomers and disorientate students.
It's why we create the cushion of fairy stories for kids, to soften the harsh realities of the _actual_ world. Later on you learn that there isn't a magic library fairy that loads everything, but it helps you cope with the first steps.
If anybody made PD that broken out of the box it would require lots of work to fix in order to make it fit to teach with again.
On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
I'm not sure this really happens but... if you add startup loads to preferences through Pd venilla, then if they don't load or crash for Pd extended, this would be made more confusing if the libraries weren't visible from a dialog somewhere.
On the other hand, you could fix fix Pd extended actually to ignore "lib" preferences altogether (although respect them on the command line for 'experts' -- then it would mke sense to get rid of the dialog and perhaps people would be very grateful for the simplification.
cheers Miller
On Tue, Sep 20, 2011 at 11:58:47AM -0400, Hans-Christoph Steiner wrote:
Please give an example of how this would make this more confusing. My experience is the exact opposite and it is exactly this problem that leads me to want to remove those preferences. The are a big source of confusion and problems, and most Pd-extended users do not use them. I am not proposing removing them from Pd-vanilla, only Pd-extended. I think globally loading libraries is a broken idea.
If you remember in the days before Pd-extended, patches that relied on external libraries were mostly unsharable. It could take a long time to track down all the dependencies, etc. and you couldn't be sure which [wrap], [split], [prepend], [scale], etc. the patch needed. Having the configuration in the patch means at worst you know what you need to get it running.
At this point I've taught Pd to 10 year olds, high school kids, college kids, masters students, and all sorts of people in workshops, college courses, and patching circles. I also answer a lot of questions on email, on forums, and on IRC. It is from this experience that I am coming from on this issue. I have no desire to control people, I do have a strong desire to make Pd-extended very user friendly to newbies and a excellent editing experience for advanced users.
And those that like the Pd-vanilla way are welcome to use it, Pd-extended will remain compatible with patches from Pd-vanilla as long as I work on it. Of course, it is not possible to maintain 100% compatibility when going from Pd-extended to Pd-vanilla since extended includes many more objects. There is also pd-l2ork, desiredata, etc. for those who want different approaches.
.hc
On Tue, 2011-09-20 at 13:02 +0100, Andy Farnell wrote:
Whenever I see the words "this would _make_ people"... alarm bells start ringing for me.
Yes, the proposed behaviour is perfectly correct, logical, and consistent. And utterly the wrong thing to do IMHO.
It would frighten off newcomers and disorientate students.
It's why we create the cushion of fairy stories for kids, to soften the harsh realities of the _actual_ world. Later on you learn that there isn't a magic library fairy that loads everything, but it helps you cope with the first steps.
If anybody made PD that broken out of the box it would require lots of work to fix in order to make it fit to teach with again.
On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hey Miller,
If I follow what you are saying, that you can create preferences in the Pd-vanilla preferences GUI that Pd-extended will then load, that is no longer true. Pd-extended has a different preferences file from Pd-vanilla (~/.pdextended, ~/Library/Pd/org.puredata.pdextended.plist, etc).
It is a bit confusing that Pd-extended is loading libraries globally at startup, you can see those in the debug output in the Pd window. Ultimately, I think Pd-extended should not load any libraries by default. That will be a big transition that will take more prep work, so I think we should defer that to a later release.
.hc
On Tue, 2011-09-20 at 11:16 -0700, Miller Puckette wrote:
I'm not sure this really happens but... if you add startup loads to preferences through Pd venilla, then if they don't load or crash for Pd extended, this would be made more confusing if the libraries weren't visible from a dialog somewhere.
On the other hand, you could fix fix Pd extended actually to ignore "lib" preferences altogether (although respect them on the command line for 'experts' -- then it would mke sense to get rid of the dialog and perhaps people would be very grateful for the simplification.
cheers Miller
On Tue, Sep 20, 2011 at 11:58:47AM -0400, Hans-Christoph Steiner wrote:
Please give an example of how this would make this more confusing. My experience is the exact opposite and it is exactly this problem that leads me to want to remove those preferences. The are a big source of confusion and problems, and most Pd-extended users do not use them. I am not proposing removing them from Pd-vanilla, only Pd-extended. I think globally loading libraries is a broken idea.
If you remember in the days before Pd-extended, patches that relied on external libraries were mostly unsharable. It could take a long time to track down all the dependencies, etc. and you couldn't be sure which [wrap], [split], [prepend], [scale], etc. the patch needed. Having the configuration in the patch means at worst you know what you need to get it running.
At this point I've taught Pd to 10 year olds, high school kids, college kids, masters students, and all sorts of people in workshops, college courses, and patching circles. I also answer a lot of questions on email, on forums, and on IRC. It is from this experience that I am coming from on this issue. I have no desire to control people, I do have a strong desire to make Pd-extended very user friendly to newbies and a excellent editing experience for advanced users.
And those that like the Pd-vanilla way are welcome to use it, Pd-extended will remain compatible with patches from Pd-vanilla as long as I work on it. Of course, it is not possible to maintain 100% compatibility when going from Pd-extended to Pd-vanilla since extended includes many more objects. There is also pd-l2ork, desiredata, etc. for those who want different approaches.
.hc
On Tue, 2011-09-20 at 13:02 +0100, Andy Farnell wrote:
Whenever I see the words "this would _make_ people"... alarm bells start ringing for me.
Yes, the proposed behaviour is perfectly correct, logical, and consistent. And utterly the wrong thing to do IMHO.
It would frighten off newcomers and disorientate students.
It's why we create the cushion of fairy stories for kids, to soften the harsh realities of the _actual_ world. Later on you learn that there isn't a magic library fairy that loads everything, but it helps you cope with the first steps.
If anybody made PD that broken out of the box it would require lots of work to fix in order to make it fit to teach with again.
On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
OK .... that assuages most of my doubts. I hadn't realized Pd extended has separate preferences; this is excellent news (preferences carrying over between the 2 was a major headache for me at one point in the past :)
I'd still suggest that, if you wnt to not have "startup lib loading" in the GUI it should get cleaned out of the preferences too - but I suspect you've already thought of that.
cheers Miller
On Tue, Sep 20, 2011 at 02:37:32PM -0400, Hans-Christoph Steiner wrote:
Hey Miller,
If I follow what you are saying, that you can create preferences in the Pd-vanilla preferences GUI that Pd-extended will then load, that is no longer true. Pd-extended has a different preferences file from Pd-vanilla (~/.pdextended, ~/Library/Pd/org.puredata.pdextended.plist, etc).
It is a bit confusing that Pd-extended is loading libraries globally at startup, you can see those in the debug output in the Pd window. Ultimately, I think Pd-extended should not load any libraries by default. That will be a big transition that will take more prep work, so I think we should defer that to a later release.
.hc
On Tue, 2011-09-20 at 11:16 -0700, Miller Puckette wrote:
I'm not sure this really happens but... if you add startup loads to preferences through Pd venilla, then if they don't load or crash for Pd extended, this would be made more confusing if the libraries weren't visible from a dialog somewhere.
On the other hand, you could fix fix Pd extended actually to ignore "lib" preferences altogether (although respect them on the command line for 'experts' -- then it would mke sense to get rid of the dialog and perhaps people would be very grateful for the simplification.
cheers Miller
On Tue, Sep 20, 2011 at 11:58:47AM -0400, Hans-Christoph Steiner wrote:
Please give an example of how this would make this more confusing. My experience is the exact opposite and it is exactly this problem that leads me to want to remove those preferences. The are a big source of confusion and problems, and most Pd-extended users do not use them. I am not proposing removing them from Pd-vanilla, only Pd-extended. I think globally loading libraries is a broken idea.
If you remember in the days before Pd-extended, patches that relied on external libraries were mostly unsharable. It could take a long time to track down all the dependencies, etc. and you couldn't be sure which [wrap], [split], [prepend], [scale], etc. the patch needed. Having the configuration in the patch means at worst you know what you need to get it running.
At this point I've taught Pd to 10 year olds, high school kids, college kids, masters students, and all sorts of people in workshops, college courses, and patching circles. I also answer a lot of questions on email, on forums, and on IRC. It is from this experience that I am coming from on this issue. I have no desire to control people, I do have a strong desire to make Pd-extended very user friendly to newbies and a excellent editing experience for advanced users.
And those that like the Pd-vanilla way are welcome to use it, Pd-extended will remain compatible with patches from Pd-vanilla as long as I work on it. Of course, it is not possible to maintain 100% compatibility when going from Pd-extended to Pd-vanilla since extended includes many more objects. There is also pd-l2ork, desiredata, etc. for those who want different approaches.
.hc
On Tue, 2011-09-20 at 13:02 +0100, Andy Farnell wrote:
Whenever I see the words "this would _make_ people"... alarm bells start ringing for me.
Yes, the proposed behaviour is perfectly correct, logical, and consistent. And utterly the wrong thing to do IMHO.
It would frighten off newcomers and disorientate students.
It's why we create the cushion of fairy stories for kids, to soften the harsh realities of the _actual_ world. Later on you learn that there isn't a magic library fairy that loads everything, but it helps you cope with the first steps.
If anybody made PD that broken out of the box it would require lots of work to fix in order to make it fit to teach with again.
On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
I totally agree that the default prefs should not be loading libs globally. I think it'll be an easier transition if we do it in parts. I was thinking that we should remove all the global lib loading in this next Pd-extended release, but it seems like to much with all the new GUI changes as well.
.hc
On Tue, 2011-09-20 at 11:58 -0700, Miller Puckette wrote:
OK .... that assuages most of my doubts. I hadn't realized Pd extended has separate preferences; this is excellent news (preferences carrying over between the 2 was a major headache for me at one point in the past :)
I'd still suggest that, if you wnt to not have "startup lib loading" in the GUI it should get cleaned out of the preferences too - but I suspect you've already thought of that.
cheers Miller
On Tue, Sep 20, 2011 at 02:37:32PM -0400, Hans-Christoph Steiner wrote:
Hey Miller,
If I follow what you are saying, that you can create preferences in the Pd-vanilla preferences GUI that Pd-extended will then load, that is no longer true. Pd-extended has a different preferences file from Pd-vanilla (~/.pdextended, ~/Library/Pd/org.puredata.pdextended.plist, etc).
It is a bit confusing that Pd-extended is loading libraries globally at startup, you can see those in the debug output in the Pd window. Ultimately, I think Pd-extended should not load any libraries by default. That will be a big transition that will take more prep work, so I think we should defer that to a later release.
.hc
On Tue, 2011-09-20 at 11:16 -0700, Miller Puckette wrote:
I'm not sure this really happens but... if you add startup loads to preferences through Pd venilla, then if they don't load or crash for Pd extended, this would be made more confusing if the libraries weren't visible from a dialog somewhere.
On the other hand, you could fix fix Pd extended actually to ignore "lib" preferences altogether (although respect them on the command line for 'experts' -- then it would mke sense to get rid of the dialog and perhaps people would be very grateful for the simplification.
cheers Miller
On Tue, Sep 20, 2011 at 11:58:47AM -0400, Hans-Christoph Steiner wrote:
Please give an example of how this would make this more confusing. My experience is the exact opposite and it is exactly this problem that leads me to want to remove those preferences. The are a big source of confusion and problems, and most Pd-extended users do not use them. I am not proposing removing them from Pd-vanilla, only Pd-extended. I think globally loading libraries is a broken idea.
If you remember in the days before Pd-extended, patches that relied on external libraries were mostly unsharable. It could take a long time to track down all the dependencies, etc. and you couldn't be sure which [wrap], [split], [prepend], [scale], etc. the patch needed. Having the configuration in the patch means at worst you know what you need to get it running.
At this point I've taught Pd to 10 year olds, high school kids, college kids, masters students, and all sorts of people in workshops, college courses, and patching circles. I also answer a lot of questions on email, on forums, and on IRC. It is from this experience that I am coming from on this issue. I have no desire to control people, I do have a strong desire to make Pd-extended very user friendly to newbies and a excellent editing experience for advanced users.
And those that like the Pd-vanilla way are welcome to use it, Pd-extended will remain compatible with patches from Pd-vanilla as long as I work on it. Of course, it is not possible to maintain 100% compatibility when going from Pd-extended to Pd-vanilla since extended includes many more objects. There is also pd-l2ork, desiredata, etc. for those who want different approaches.
.hc
On Tue, 2011-09-20 at 13:02 +0100, Andy Farnell wrote:
Whenever I see the words "this would _make_ people"... alarm bells start ringing for me.
Yes, the proposed behaviour is perfectly correct, logical, and consistent. And utterly the wrong thing to do IMHO.
It would frighten off newcomers and disorientate students.
It's why we create the cushion of fairy stories for kids, to soften the harsh realities of the _actual_ world. Later on you learn that there isn't a magic library fairy that loads everything, but it helps you cope with the first steps.
If anybody made PD that broken out of the box it would require lots of work to fix in order to make it fit to teach with again.
On 2011-09-19 19:32, Hans-Christoph Steiner wrote: > > Hey Miller, > > I actually think this would make switching between vanilla and extended > easier because it would make people use [import] or [declare] to load > libs, then when using vanilla, you'll know which libraries the patch > needs. Can you think of examples where it would make things more > difficult?
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 2011-09-20 at 09:31 +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
Hey Miller,
I actually think this would make switching between vanilla and extended easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the patch needs. Can you think of examples where it would make things more difficult?
so the idea is to have tons of error messages when using pd-vanilla, of the kind: "import zexy... couldn't create" so that the user knows that they have to load the "zexy" library and henceforth ignore the "import zexy" line and only check the remaining "import foobar...couldn't create"?
i seem to remember that there was a recent email saying that "a patch relying on an error" was not to be considered as correct.
Either way, if you open a patch that uses zexy objects in Pd-vanilla, there will be "...couldn't create" errors. Having [import zexy] there at least gives a place to focus on. Or if people are interested in more portability, they are welcome to either use [declare] or "apt-get install puredata-import"
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: IOhannes m zmoelnig zmoelnig@iem.at Cc: pd-dev@iem.at Sent: Tuesday, September 20, 2011 11:46 AM Subject: Re: [PD-dev] removing path and libs from Pd-extended preferences GUI
On Tue, 2011-09-20 at 09:31 +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
Hey Miller,
I actually think this would make switching between vanilla and
extended
easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the
patch
needs. Can you think of examples where it would make things more difficult?
so the idea is to have tons of error messages when using pd-vanilla, of the kind: "import zexy... couldn't create" so that the user
knows that
they have to load the "zexy" library and henceforth ignore the
"import
zexy" line and only check the remaining "import
foobar...couldn't create"?
i seem to remember that there was a recent email saying that "a patch relying on an error" was not to be considered as correct.
Either way, if you open a patch that uses zexy objects in Pd-vanilla, there will be "...couldn't create" errors. Having [import zexy] there at least gives a place to focus on. Or if people are interested in more portability, they are welcome to either use [declare] or "apt-get install puredata-import"
A few questions:
* What's the difference between [import foo] and [declare -lib foo]? Both seem to load the library into the patch's local namespace. * Isn't there an issue between loading a lib in the patch's local namespace and the way the setup routine works globally for a library?
If I have
Patch #1 [import iemguts]
Patch #2 [sendcanvas] <- sendcanvas won't load, because its lib was only loaded for Patch #1
But if I have
Patch #1 [import iemguts] [sendcanvas]
Patch #2 [sendcanvas] <- this loads, because instantiating [sendcanvas] in Patch #1 loaded the lib globally
Finally: * why did you develop [import] instead of improving [declare]?
-Jonathan
.hc
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
On Tue, 2011-09-20 at 13:19 -0700, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: IOhannes m zmoelnig zmoelnig@iem.at Cc: pd-dev@iem.at Sent: Tuesday, September 20, 2011 11:46 AM Subject: Re: [PD-dev] removing path and libs from Pd-extended preferences GUI
On Tue, 2011-09-20 at 09:31 +0200, IOhannes m zmoelnig wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
Hey Miller,
I actually think this would make switching between vanilla and
extended
easier because it would make people use [import] or [declare] to load libs, then when using vanilla, you'll know which libraries the
patch
needs. Can you think of examples where it would make things more difficult?
so the idea is to have tons of error messages when using pd-vanilla, of the kind: "import zexy... couldn't create" so that the user
knows that
they have to load the "zexy" library and henceforth ignore the
"import
zexy" line and only check the remaining "import
foobar...couldn't create"?
i seem to remember that there was a recent email saying that "a patch relying on an error" was not to be considered as correct.
Either way, if you open a patch that uses zexy objects in Pd-vanilla, there will be "...couldn't create" errors. Having [import zexy] there at least gives a place to focus on. Or if people are interested in more portability, they are welcome to either use [declare] or "apt-get install puredata-import"
A few questions:
- What's the difference between [import foo] and [declare -lib foo]? Both
seem to load the library into the patch's local namespace.
Underneath, they are the same thing. I could never remember the [declare] syntax so I wrote [import] and [classpath].
- Isn't there an issue between loading a lib in the patch's local
namespace and the way the setup routine works globally for a library?
If I have
Patch #1 [import iemguts]
Patch #2 [sendcanvas] <- sendcanvas won't load, because its lib was only loaded for Patch #1
But if I have
Patch #1 [import iemguts] [sendcanvas]
Patch #2 [sendcanvas] <- this loads, because instantiating [sendcanvas] in Patch #1 loaded the lib globally
Yes this is true. The namespaces stuff isn't fully implemented yet. The way to guarantee you are getting a specific object is to use the namespace prefix, i.e. [iemguts/sendcanvas].
Finally:
- why did you develop [import] instead of improving [declare]?
Because what I wanted to do would have broken the syntax of [declare], and others wanted it the way it was.
.hc
-
András Murányi -
Andy Farnell -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Jonathan Wilkes -
João Pais -
Miller Puckette