I entirely disagree,
#1 its in the menu of PD:
One starts PD, then changes the settings, if s/he wants to use the new setting (if s/he does not want to, why is s/he changing them?) so s/he quits PD and starts it again.
#2 its a separate program:
(a) Changes settings One starts the launcher, changes the settings, and hits the "launch PD" button.
(b) Using the default settings One clicks on the shortcut or runs the script (created by the launcher) for the default options.
One the user has created a number of config sets, then they don't use the launcher except to tinker with the settings.
At worst having it in the start is an extra click. (the PD launch button) At worst having it in the menu is quiting and waiting for PD to start again (anoying if it has lots of libs, on slower machine)
I'm failing to see a strong counter argument to having it a separate program. perhaps I'm missing a point, I really want the software to be as clean to the user as possible, restarting PD to change settings is simply a pain.
Thanks for the thinking and critisism, keep it coming!
Ben
----- Original Message ----- From: Frank Barknecht fbar@footils.org Date: Saturday, May 31, 2003 1:28 pm Subject: Re: [PD-dev] External Manager - Load my Externals
Hallo, bbogart@ryerson.ca hat gesagt: // bbogart@ryerson.ca wrote:
I think a home on the PD menu would be a great place for this project, IF PD could load externals and change flags on the fly. (without restarting) without this having it the menu would make little sense, if It is to be integrated into PD without the ability to do this then it would be a kind of splash page, starting up before PD, but then how to deal with loading and saving multiple configuration sets? I think the most elegant solution would be to run it seperate from PD. Mind you I think it would be amazing if PD would load/remove libs and change audio settings on the fly, is this even possible?
Even without this - i.e. with restarting Pd - this would be best placed into a Pd-window menu. The reason is mostly usability. An external launcher would be another program to run.
ciao
Frank Barknecht _ ______footils.org__
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, bbogart@ryerson.ca hat gesagt: // bbogart@ryerson.ca wrote:
I entirely disagree,
I'm failing to see a strong counter argument to having it a separate program. perhaps I'm missing a point, I really want the software to be as clean to the user as possible, restarting PD to change settings is simply a pain.
My main point is, that users of graphical software simply *expect* a menu entry "Preferences" or "Options". I agree, that currently Pd doesn't provide all the hooks that make such an entry comfortable so there's work to do inside Pd.
But maybe we're talking about different things. An external LME can only set things up for Pd startup. So in the end it is just a simplyfied text editor, not a launcher in the first place - like most developers' editors also are launchers and can for example start "make", but in general they are editors.
What I'd envision is a real preferences system that in the end can also change things at runtime and where only some changes require a restart. Like for example in Mozilla: setting another proxy doesn't require a restart, but changing the GUI-theme does. And yes, restarting Mozilla is a pain.
For some of the Pd options I could think of internal solutions.
- Turn on and off flags
- Add flag options
As these are mostly *startup* flags, several of the options actually don't make sense inside Pd, for example "-nogui". These would only be useful in an external config- or script-file editor. But others would make sense at runtime. Setting the path for example should be possible at runtime by calling "sys_addpath(new_path)" without requiring a restart.
- Add Lib(s)
Also possible at runtime, just like creating an object named as the lib loads the lib.
- Remove Lib(s)
Don't know if this could work at runtime...
- Configure (edit conf file) [ where is PD, where to scan for libs, etc.. ]
- Load Config Set [ Config sets will be executable without the manager! sh scripts in Linux,
.commands in OSX, and shortcuts in Windows ]
- Save Config Set
Loading and saving configs really should be made possible from inside Pd, I strongly believe. For different configs ("-nogui") I'm not sure, but e.g. nogui is an advanced option, that IMO can be left a command line option.
- Launch PD with Open Set
Of course launching Pd from inside Pd isn't feasible. This would be a case for another config option: the already mentioned "-loadconfig (-rc) <conffile>" But Pd could be changed to startup like Mozilla (again) and present a list of profiles, from which to choose. I don't know if that would be so useful, because I believe, that different config sets are actually more useful for "advanced" users, who might not fear editing config files directly. I think, the "normal" user most of the time uses a highly personalized, but seldom changing setup.
- Quit
We have that ;)
Please don't misunderstand me: I'm not at all against the idea of an external config editor like your proposed LME. I just hope, that in the end most of this can be incorporated into Pd itself, the way most other software handles it. But changing Pd is more difficult.
ciao
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
On Sunday 01 June 2003 04:49, Frank Barknecht wrote:
But maybe we're talking about different things. An external LME can> only
Yes! We should have an LME!
What the #$^& are you talking about???
Read the #$^?&§$ subject! ;)
ciao
On Mon, 2 Jun 2003, Frank Barknecht wrote:
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
On Sunday 01 June 2003 04:49, Frank Barknecht wrote:
But maybe we're talking about different things. An external LME can> only
Yes! We should have an LME!
What the #$^& are you talking about???
Read the #$^?&�$ subject! ;)
:)
Ok, some (critical) thoughts:
* Preferences: again, a launcher is a bad idea IMO, it should be a preference dialog. Don't think about software being written once and then its done. If you have the launcher, you will want to have preferences sooner or later, ...
* External loader comes from the concept of having libraries. I have mentioned several times that this is not a good way how to write externals, because it merely adds complexity in the build processes and uses up more RAM.
We should get rid of the concept of libraries. (Hide the "external loader" in a "advanced" tab if you like, but don't write a program that is an "external loader" above all).
* Different configurations: I think this is a very good concept and should be easy to add by using different names for pd config files.
Last but not least, Miller is already thinking about preferences, expecially for audio settings, and changing them on the fly is not too far away ...
Guenter
hi Guenter,
btw, I wonder, are you going to merge cyclone with the cvs release system for externals?
And, after xeq&vex are imported, how about them?
Krzysztof
guenter geiger wrote:
External loader comes from the concept of having libraries. I have mentioned several times that this is not a good way how to write externals, because it merely adds complexity in the build processes and uses up more RAM.
We should get rid of the concept of libraries. (Hide the "external
On Mon, 2 Jun 2003, Krzysztof Czaja wrote:
hi Guenter,
btw, I wonder, are you going to merge cyclone with the cvs release system for externals?
And, after xeq&vex are imported, how about them?
Krzysztof
Well, I have to admit that I am not an extensive cyclone user, as I never programmed with MAX, and I am trying to reduce my pd programming to builting features.
So what do you think ? (I do not have any concrete plans yet, have to take a closer look first).
Afer all, one purpose of the CVS is to built a stronger external developer community, so everyone's opinion counts. The worst thing that can happen is if someone does not contribute because it seemed that I was imposing something.
Guenter
guenter geiger wrote:
External loader comes from the concept of having libraries. I have mentioned several times that this is not a good way how to write externals, because it merely adds complexity in the build processes and uses up more RAM.
We should get rid of the concept of libraries. (Hide the "external
I think that any objects that a developer puts into the CVS should be included in the packages. There are a a couple exceptions: when it would cause a name conflict and when that developer doesn't want it to be included.
So as long as the cyclone objects don't have any library dependencies, then they should be part of the main package.
.hc
On Monday, Jun 2, 2003, at 11:58 America/New_York, guenter geiger wrote:
On Mon, 2 Jun 2003, Krzysztof Czaja wrote:
hi Guenter,
btw, I wonder, are you going to merge cyclone with the cvs release system for externals?
And, after xeq&vex are imported, how about them?
Krzysztof
Well, I have to admit that I am not an extensive cyclone user, as I never programmed with MAX, and I am trying to reduce my pd programming to builting features.
So what do you think ? (I do not have any concrete plans yet, have to take a closer look first).
Afer all, one purpose of the CVS is to built a stronger external developer community, so everyone's opinion counts. The worst thing that can happen is if someone does not contribute because it seemed that I was imposing something.
Guenter
guenter geiger wrote:
External loader comes from the concept of having libraries. I have mentioned several times that this is not a good way how to write externals, because it merely adds complexity in the build processes and uses up more RAM.
We should get rid of the concept of libraries. (Hide the "external
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
btw, I wonder, are you going to merge cyclone with the cvs release system for externals?
Another advantage of single over libraries of externals is that name conflicts are easier to spot.
The build-system, Guenther installed, is actually rather simple for single externals. Just put a file into "build", that C-include's the real file.
ciao
On Mon, 2 Jun 2003, Frank Barknecht wrote:
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
btw, I wonder, are you going to merge cyclone with the cvs release system for externals?
Another advantage of single over libraries of externals is that name conflicts are easier to spot.
The build-system, Guenther installed, is actually rather simple for single externals. Just put a file into "build", that C-include's the real file.
Yes, and actually this should be documented somewhere, because it is an easy way to "release" externals into the the "approved" folder.
Hum, time to write some more developer docs.
I think we have to come up with a procedure that is more strict sooner or later, for documentation as well.
Guenter
hi Guenter, Frank,
no doubt, the central repository for externals is great idea.
No doubt, loading externals on demand is better than using -lib option. Any cyclone object may be loaded on demand, except for operators (talking about linux build, which is what I use).
Not sure, though, what is your expected target installation -- do you expect everybody would have all externs from cvs installed? This is going to be huge...
If not, how would one make the selection?
guenter geiger wrote:
On Mon, 2 Jun 2003, Frank Barknecht wrote:
...
Another advantage of single over libraries of externals is that name conflicts are easier to spot.
but are not they harder to resolve that way?
The build-system, Guenther installed, is actually rather simple for single externals. Just put a file into "build", that C-include's the real file.
do you mean one should simply #include all the shared code? or maybe one should not use shared code at all?
Krzysztof
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
no doubt, the central repository for externals is great idea.
No doubt, loading externals on demand is better than using -lib option. Any cyclone object may be loaded on demand, except for operators (talking about linux build, which is what I use).
Not sure, though, what is your expected target installation -- do you expect everybody would have all externs from cvs installed? This is going to be huge...
Why not? I have almost all of the externals in my path, at least all on the CVS plus iemlib,... I normally don't load Gem, but I would it make any difference if it was in my path as single externals?
guenter geiger wrote:
On Mon, 2 Jun 2003, Frank Barknecht wrote:
...
Another advantage of single over libraries of externals is that name conflicts are easier to spot.
but are not they harder to resolve that way?
If all externals are in one directory, it is solved automatically ;)
The build-system, Guenther installed, is actually rather simple for single externals. Just put a file into "build", that C-include's the real file.
do you mean one should simply #include all the shared code? or maybe one should not use shared code at all?
Just look into one file: You just include one external per file. For example prepend.c in build/src looks like this: // --- start --- #include "../../somecollection/prepend.c" // --- end -----
ciao
On Tue, 3 Jun 2003, Krzysztof Czaja wrote:
hi Guenter, Frank,
no doubt, the central repository for externals is great idea.
No doubt, loading externals on demand is better than using -lib option. Any cyclone object may be loaded on demand, except for operators (talking about linux build, which is what I use).
Not sure, though, what is your expected target installation -- do you expect everybody would have all externs from cvs installed? This is going to be huge...
Yes, but considering that there are only useful externals there, it makes sense to install them all (hard disk space is cheap, and pd with externals is still small in comparison to other software)
If not, how would one make the selection?
I was thinking that we could work on that together.
guenter geiger wrote:
On Mon, 2 Jun 2003, Frank Barknecht wrote:
...
Another advantage of single over libraries of externals is that name conflicts are easier to spot.
but are not they harder to resolve that way?
no, they are not harder to resolve. They finally get resolved.
The build-system, Guenther installed, is actually rather simple for single externals. Just put a file into "build", that C-include's the real file.
do you mean one should simply #include all the shared code? or maybe one should not use shared code at all?
No, the #include thing is they way how "links" are implemented in CVS.
Another topic is shared code. I think shared code could go into a dll. A standard dll gets automatically loaded when the first external that uses it gets loaded.
Greetings,
Guenter
hi Guenter, thanks for answering my stupid questions!
guenter geiger wrote: ...
Yes, but considering that there are only useful externals there, it makes sense to install them all (hard disk space is cheap, and pd with externals is still small in comparison to other software)
well... there are likely a few thousand Pd externals that are more or less useful, in a couple of years. That could be too much for my brain space. I also fear the older patches will gradually stop working, if their abstraction names are stolen by new externals that will be introduced.
...
Another advantage of single over libraries of externals is that name conflicts are easier to spot.
but are not they harder to resolve that way?
no, they are not harder to resolve. They finally get resolved.
I meant getting people to agree on what is good for all of them is usually harder than letting every self choose what it wants.
Of course, if there is a standard set of externals, there should be a corresponding standard set of names. So, for example, I have been annoying everybody, many times, with the ``standard max/msp names should be reserved'' theme.
But the non-standard externals, i.e. most of them, would have been easier to maintain, if there was a name resolution scheme based on the combination of per-user configuration and dependencies stored in .pd files.
No, the #include thing is they way how "links" are implemented in CVS.
I have not given it much thinking yet, but I would start with what seems like a more natural way of building a collection of externals: run make on every directory in the list, then consult another list to pick the needed binaries from wherever they went to. Just two files to maintain for every platform: linux.dirs and linux.binaries, etc.
Another topic is shared code. I think shared code could go into a dll. A standard dll gets automatically loaded when the first external that uses it gets loaded.
do you mean loading by a stub, or by some yet-to-implement magic in the Pd loader?
Krzysztof
On Wed, 4 Jun 2003, Krzysztof Czaja wrote:
hi Guenter, thanks for answering my stupid questions!
guenter geiger wrote: ...
Yes, but considering that there are only useful externals there, it makes sense to install them all (hard disk space is cheap, and pd with externals is still small in comparison to other software)
well... there are likely a few thousand Pd externals that are more or less useful, in a couple of years. That could be too much for my brain space. I also fear the older patches will gradually stop working, if their abstraction names are stolen by new externals that will be introduced.
with single externals it will be easy to prevent that scenario. E.g., you put the externals you need in your specific pd project folder, this way abstractions and externals are treated the same way, you can even distribute the projects platform independent, without having to tell people to install/compile the externals themselves.
...
Another advantage of single over libraries of externals is that name conflicts are easier to spot.
but are not they harder to resolve that way?
no, they are not harder to resolve. They finally get resolved.
I meant getting people to agree on what is good for all of them is usually harder than letting every self choose what it wants.
Of course, if there is a standard set of externals, there should be a corresponding standard set of names. So, for example, I have been annoying everybody, many times, with the ``standard max/msp names should be reserved'' theme.
Which is definitely an important topic, can't remember all the issues, but some of them where pd internal (which should be resolved inside pd).
But the non-standard externals, i.e. most of them, would have been easier to maintain, if there was a name resolution scheme based on the combination of per-user configuration and dependencies stored in .pd files.
That is the point I am trying to make with single externals. It is already there, nothing to implement, we only need to tell people. The name resolution can be arbitrarily configured by the person who writes the patch. This way abstractions and externals are naturally treated the same way.
You can even make collections of externals by putting them in a subfolder and instantiating with <subfolder>/externalname.
I can not think of a name resolution system that is more flexible.
No, the #include thing is they way how "links" are implemented in CVS.
I have not given it much thinking yet, but I would start with what seems like a more natural way of building a collection of externals: run make on every directory in the list, then consult another list to pick the needed binaries from wherever they went to. Just two files to maintain for every platform: linux.dirs and linux.binaries, etc.
One goal of the setup was to have only (simple) one makefile per platform. I wanted the build process to be controllable and if something changes fixable. You are right that it might not be the most natural way, but it works out well until now.
With the scheme we have now it is easy to add a new platform, compiler, whatever.
Another topic is shared code. I think shared code could go into a dll. A standard dll gets automatically loaded when the first external that uses it gets loaded.
do you mean loading by a stub, or by some yet-to-implement magic in the Pd loader?
It gets loaded because it is a dll.
If you link your external against libogg, libogg gets loaded. If you link it against "myext.dll" myext.dll gets loaded.
Of course if you have to execute some code during loading it gets slightly more complicated. But no additions to pd needed.
Greetings Guenter
thanks again Guenter,
great to have someone so patient to explain everything I need...
Krzysztof
On Wed, 4 Jun 2003, Krzysztof Czaja wrote:
thanks again Guenter,
great to have someone so patient to explain everything I need...
Krzysztof
:) you're welcome. But you know, everything is relative .... The main problem is that it is only theory, we still have to wait if the scenario works out in practice too.
Guenter
On Mon, 2 Jun 2003, Frank Barknecht wrote:
Hallo, Larry Troxler hat gesagt: // Larry Troxler wrote:
On Sunday 01 June 2003 04:49, Frank Barknecht wrote:
But maybe we're talking about different things. An external LME can> only
Yes! We should have an LME!
What the #$^& are you talking about???
Read the #$^?&§$ subject! ;)
Naw, that would be too easy ;-)
Ben, this project is a HUGE deal for lowering the entrance bar for new PD users to users, thanks.
bbogart@ryerson.ca wrote:
I entirely disagree,
#1 its in the menu of PD:
One starts PD, then changes the settings, if s/he wants to use the new setting (if s/he does not want to, why is s/he changing them?) so s/he quits PD and starts it again.
it should be possible to have a preferences menu automatically restart pd for you in the situatoins when that is strictly nessesary, sort of how mozilla used to deal with "dynamic" theme switches or how it currently deals with switching user profiles on the fly. for instance, you wouldnt need to restart to just add libraries and paths, but removing them or changing the audio hardware preferences would cause a restart. maybe in the future pd would allow you to do both of these dynamically, and you could remobe the restart function and keep the user experience/interface the same.
i think having your project behave as an integrated pref's panel within the program is a more consistant and expected idea for the user. most newbies will unzip pd, and instinctively run the pd.exe or what-have-you and look for a pref's meny rather that looking for a separate configurator application.
i'm planning on really learning tcl/tk in the next few months, so i might be able to help out a little, no promises though :)
thanks for taking this on!!
-josh
-
bbogart＠ryerson.ca -
Frank Barknecht -
guenter geiger -
Hans-Christoph Steiner -
Josh Steiner -
Krzysztof Czaja -
Larry Troxler