Sorry-I'm a bit confused as to the difference between libs and paths, at the moment.
Here's a situation where I like to have the path dialog: I download an archive of abstractions (like RJDJ), and I'd like to be able to put them anywhere, so if there's a couple different versions, I can just tell them apart from folders.
With the path dialog, I can just right away see what set of abstractions are on the path, change it, apply, and get to work.
How would I accomplish the same thing without it?
Chuck
On Tue, Sep 20, 2011 at 10:58 AM, Hans-Christoph Steiner hans@at.or.at 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
For this situation, I think there is no need for custom paths, you can use the built-in default paths, which are the default in pd-vanilla, pd-extended, and pd-l2ork.
For the rjlib, merely drop the 'rj' folder into the standard default install location: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
Then use the object by doing [rj/s_fm4] or whatever. Or you could you:
[import rj] [s_fm4]
or:
[declare -lib rj] [s_fm4]
The only use case for setting your own path that I know is like [declare -path lib/] where you set a folder within your project to load libs from. That is accomplished much better with [declare -path] than setting a global pref because it means the patch has the whole config included with it.
.hc
On Tue, 2011-09-20 at 13:30 -0500, Charles Henry wrote:
Sorry-I'm a bit confused as to the difference between libs and paths, at the moment.
Here's a situation where I like to have the path dialog: I download an archive of abstractions (like RJDJ), and I'd like to be able to put them anywhere, so if there's a couple different versions, I can just tell them apart from folders.
With the path dialog, I can just right away see what set of abstractions are on the path, change it, apply, and get to work.
How would I accomplish the same thing without it?
Chuck
On Tue, Sep 20, 2011 at 10:58 AM, Hans-Christoph Steiner hans@at.or.at 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
I don't actually *like* those solutions for the scenario I just described.
I think the path dialog has a distinct purpose of its own that is not shared by those options. (These aren't always advantages--just differences) --It's persistent across sessions. --I can use my own organization of abstractions in some far flung corner of my user directory. --It's always the full path.
For some types of work, the path dialog really makes sense to me. I work on it sporadically, I crash Pd frequently, and when I start it up, having those settings saved in the config will save me some time.
[declare] and [import] are really for sharing patches with other people--but maybe I'm not sharing anything and I'm just cooking up some buggy externals. Then, I want to be able to work quickly--*not* correctly.
Chuck
On Tue, Sep 20, 2011 at 1:44 PM, Hans-Christoph Steiner hans@at.or.at wrote:
For this situation, I think there is no need for custom paths, you can use the built-in default paths, which are the default in pd-vanilla, pd-extended, and pd-l2ork.
For the rjlib, merely drop the 'rj' folder into the standard default install location: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files
Then use the object by doing [rj/s_fm4] or whatever. Or you could you:
[import rj] [s_fm4]
or:
[declare -lib rj] [s_fm4]
The only use case for setting your own path that I know is like [declare -path lib/] where you set a folder within your project to load libs from. That is accomplished much better with [declare -path] than setting a global pref because it means the patch has the whole config included with it.
.hc
On Tue, 2011-09-20 at 13:30 -0500, Charles Henry wrote:
Sorry-I'm a bit confused as to the difference between libs and paths, at the moment.
Here's a situation where I like to have the path dialog: I download an archive of abstractions (like RJDJ), and I'd like to be able to put them anywhere, so if there's a couple different versions, I can just tell them apart from folders.
With the path dialog, I can just right away see what set of abstractions are on the path, change it, apply, and get to work.
How would I accomplish the same thing without it?
Chuck
Le 2011-09-20 à 13:30:00, Charles Henry a écrit :
Sorry-I'm a bit confused as to the difference between libs and paths, at the moment.
The libdir system introduced by pd-extended removed much of the difference.
Still, one can use Paths to specify default locations for looking for sound files and image files, and that is one reason why libs and paths still have to remain distinct and why paths have to be saved.
Here's a situation where I like to have the path dialog: I download an archive of abstractions (like RJDJ), and I'd like to be able to put them anywhere, so if there's a couple different versions, I can just tell them apart from folders.
With the path dialog, I can just right away see what set of abstractions are on the path, change it, apply, and get to work.
Libs that are folders are looked for in the Path, thus if you don't say «-lib /home/chenry/foo-4.2/foo», you can instead say «-path /home/chenry/foo-4.2 -lib foo», and then if you have «/home/chenry/foo-4.3/foo» as well, you only need replace the path item, not the lib item.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC
-
Charles Henry -
Hans-Christoph Steiner -
Mathieu Bouchard