Hello Hans-Christoph,
I think the first version will assume external binaries have already been extracted/built.
The packaging thing makes me a little nervous because I was hoping the system would be a single tcl script that would run on all platforms. Only problem is the availibility of different packaging systems (tgz, dpkg, zip etcc) and dealing with them from inside the launcher.
Cotributions would be great, how are/were you envisioning the project?
Ben
----- Original Message ----- From: Hans-Christoph Steiner hans@eds.org Date: Friday, May 16, 2003 1:39 pm Subject: Re: [PD] PD Launcher/External Manager
This is a great idea, something I was planning on working on this summer. I'd like to contribute if possible. Perhaps we can put it in the CVS and collaborate.
As for distributing the externals, I think rather than building our own distribution system, we should use what's out there for each OS.
Debian and RedHat have very nice existing methods, and the externals in the SourceForge CVS can be compiled into a set of Debian packages right now. They just need to be submitted to the Debian and/or DeMuDi repository. It shouldn't be too hard to add RedHat/PlanetCCRMA to that, but currently Nando at CCRMA does that outside of the CVS.For Windows and OS X, if we make installer packages for the same sets of externals as the Debian packages, that will greatly simplify things. But the biggest thing that would improve the situation would be to have all of the externals in the CVS. Then they would be included in the existing packages, or if necessary, they can be made into their own package.
Think of it this way: if we had all of the externals that didn't have lib dependencies in the CVS, they could all be included in the main externals package in the CVS and they would all be installed with that package. The key omissions that I can think of off the top of my head are the collections of Olaf Matthes, Krzysztof Czaja, Thomas Musil, Dave Sabine, and Yves Degoyon; there are others as well, who's objects are an important addition to anyone's pd install, and I hope that anyone who writes externals for pd will contribute them to the CVS.
So to encourage others to join the CVS, I am going to configure access control lists in the CVS so that devs who choose to can restrict write access to their code in the CVS. I am also willing to upload people's code and help with setting up CVS access.
.hc
On Tuesday, May 13, 2003, at 13:00 America/New_York, bbogart@ryerson.ca wrote:
If someone wanted to upload built versions of the stable
externals in
CVS, as tgz and zip files, for all platforms to a ftp server,
then
that would be a LOT easier for the tool to do. (download and
extract,
but then you depend on extraction tools, whats the average size
of the
externals? (for all platforms?)
I'm thinking the double pane idea would work better from a
usability
standpoint, opinions?
B.
----- Original Message ----- From: Marc Lavallée odradek@videotron.ca Date: Tuesday, May 13, 2003 9:51 am Subject: Re: [PD] PD Launcher/External Manager
David McCallum wrote :
My Pd launcher's no more than a custom DOS .bat file that let's you turn Framestein and ASIO drivers on/off at runtime.
I use the same technique in Linux with a shell script.
And as a windows user I have to ask this, how cross-platform are you intending this to be?
Tcl/Tk. The launcher would list the externals with their
descriptions,>> and checkboxes would activate them. If an internet source is
provided it would first download and install the externals. Isn't there a
Windows>> mechanism to install softwares from the network?
-- Marc
"L'homme n'est pas fait pour travailler, la preuve c'est que
cela le
fatigue." (Voltaire)
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
On Sunday, May 18, 2003, at 09:49 America/New_York, bbogart@ryerson.ca wrote:
Hello Hans-Christoph,
I think the first version will assume external binaries have already been extracted/built.
The packaging thing makes me a little nervous because I was hoping the system would be a single tcl script that would run on all platforms. Only problem is the availibility of different packaging systems (tgz, dpkg, zip etcc) and dealing with them from inside the launcher.
I think that making a system to track down various installers and install them is basically duplicating the effort to have pd developers use the CVS. If the vast majority of developers use the CVS, then there would not be a compelling need to have an elaborate system to track down externals since most of them would already be included in the installer. So I think working making the CVS as accessible as possible to all Pd developers, and encouraging people to use the CVS is more important.
In my vision of the launcher I think it would be great that it gets integrated into PD somehow. I don't think inside PD would be the place to do this though, since the libs have to be loaded before that. (load PD, change prefs, then load PD again to load the libs/options) Also functionality not possible with .pdrc would be managing different sets of options. I do this with aliases on my linux machine, with often 3 lines of flags, all loading the same PD, but with different options. I think it would be very useful to have sets of these options.
In terms of windows I don't think it makes any sense to write an ugly .bat file when this stuff can be managed within tcl itself.
I think this should all be in Tcl since its cross-platform and already
there when using pd. As for doing it 'inside' pd, it would easy enough
to have a Tcl script handle all of the startup options, then launch pd.
So basically, it would be like a GUI .bat launcher written in Tcl.
But I think we should also start moving towards a 'Preferences' idea,
so that you can change these settings while pd is running. For now,
you could just have the Preferences panel just rewrite the .pdrc, then
you'd need to restart for the changes to take effect. But then, as
developers are willing to dig deeper into pd, the Preferences could be
made to change this stuff in realtime. That's my vision of how this
should work.
But a related question is, what is preventing Windows from having a .pdrc? Anybody know? Having .pdrc be standard across all platforms would simplify this effort.
.hc
Cotributions would be great, how are/were you envisioning the project?
Ben
----- Original Message ----- From: Hans-Christoph Steiner hans@eds.org Date: Friday, May 16, 2003 1:39 pm Subject: Re: [PD] PD Launcher/External Manager
This is a great idea, something I was planning on working on this summer. I'd like to contribute if possible. Perhaps we can put it in the CVS and collaborate.
As for distributing the externals, I think rather than building our own distribution system, we should use what's out there for each OS. Debian and RedHat have very nice existing methods, and the externals in the SourceForge CVS can be compiled into a set of Debian packages right now. They just need to be submitted to the Debian and/or DeMuDi repository. It shouldn't be too hard to add RedHat/PlanetCCRMA to that, but currently Nando at CCRMA does that outside of the CVS.
For Windows and OS X, if we make installer packages for the same sets of externals as the Debian packages, that will greatly simplify things. But the biggest thing that would improve the situation would be to have all of the externals in the CVS. Then they would be included in the existing packages, or if necessary, they can be made into their own package.
Think of it this way: if we had all of the externals that didn't have lib dependencies in the CVS, they could all be included in the main externals package in the CVS and they would all be installed with that package. The key omissions that I can think of off the top of my head are the collections of Olaf Matthes, Krzysztof Czaja, Thomas Musil, Dave Sabine, and Yves Degoyon; there are others as well, who's objects are an important addition to anyone's pd install, and I hope that anyone who writes externals for pd will contribute them to the CVS.
So to encourage others to join the CVS, I am going to configure access control lists in the CVS so that devs who choose to can restrict write access to their code in the CVS. I am also willing to upload people's code and help with setting up CVS access.
.hc
On Tuesday, May 13, 2003, at 13:00 America/New_York, bbogart@ryerson.ca wrote:
If someone wanted to upload built versions of the stable
externals in
CVS, as tgz and zip files, for all platforms to a ftp server,
then
that would be a LOT easier for the tool to do. (download and
extract,
but then you depend on extraction tools, whats the average size
of the
externals? (for all platforms?)
I'm thinking the double pane idea would work better from a
usability
standpoint, opinions?
B.
----- Original Message ----- From: Marc Lavallée odradek@videotron.ca Date: Tuesday, May 13, 2003 9:51 am Subject: Re: [PD] PD Launcher/External Manager
David McCallum wrote :
My Pd launcher's no more than a custom DOS .bat file that let's you turn Framestein and ASIO drivers on/off at runtime.
I use the same technique in Linux with a shell script.
And as a windows user I have to ask this, how cross-platform are you intending this to be?
Tcl/Tk. The launcher would list the externals with their
descriptions,>> and checkboxes would activate them. If an internet source is
provided it would first download and install the externals. Isn't there a
Windows>> mechanism to install softwares from the network?
-- Marc
"L'homme n'est pas fait pour travailler, la preuve c'est que
cela le
fatigue." (Voltaire)
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Just a few quick questions, I am curious to find out what makes the most efficient Pd patches? So my first question is, is a sub-patch more efficient than an abstraction?, and secondly is a simple external much more efficient than implementing the object in Pd itself? For instance is using a Âmetro object more efficient than building a metro yourself? Obviously the later will take you a lot more time but just for example sake?
It's Samaritans' Week. Help Samaritans help others. Call 08709 000032 to give or donate online now at http://www.samaritans.org/support/donations.shtm
you can do some efficiency tests on your own using nqpoly or clone. make an object that contains the thing you want to test, and instantiate a few hundred of copies of it, it will give you a good idea of cpu usage etc.
but, i can't imagine why making your own metro would be more efficient.
re subpatches/abstractions, i'd assume that the only difference would be at load time. once it's loaded and built in pd, there should be no difference.
i personally don't like sub-patches, because 1) i'm always accidentally deleting them (which was a real drag pre-undo functionality) and 2) i prefer to make general abstractions that i can use in other patches (which is a different take on "efficiency").
pix.
On Tue, 27 May 2003 14:20:12 +0100 (BST) Rory Walsh rorytheroar@yahoo.com wrote:
Just a few quick questions, I am curious to find out what makes the most efficient Pd patches? So my first question is, is a sub-patch more efficient than an abstraction?, and secondly is a simple external much more efficient than implementing the object in Pd itself? For instance is using a _metro_ object more efficient than building a metro yourself? Obviously the later will take you a lot more time but just for example sake?
It's Samaritans' Week. Help Samaritans help others. Call 08709 000032 to give or donate online now at http://www.samaritans.org/support/donations.shtm
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But a related question is, what is preventing Windows from having a .pdrc? Anybody know? Having .pdrc be standard across all platforms would simplify this effort.
Windows doesn't have the notion of a HOME-directory (it doesn't even have a real "bin" or "PATH", like we're used to on Linux or OS-X).
So we would need to make a personal HOME dir for Pd on Windwows. Mozilla is a good example of how this could work. Just let the user create a Pd-Home like Mozilla lets them create a "Profile"-directory. Into that, we could then put the .pdrc and also some standard locations for externals and so on there.
Frank Barknecht _ ______footils.org__
Windows XP (and I think 2000?) has a kind of a "home" folder for each user. On XP at least, within the "Documents and Settings" folder, there is a folder corresponding the each user's name. I've used the gaim (chat client) windows port on windows xp, and it generates a .gaimrc file in the user folder I described above. I think that's where a .pdrc file could go.
Chad
-----Original Message----- From: pd-list-admin@iem.kug.ac.at [mailto:pd-list-admin@iem.kug.ac.at]On Behalf Of Frank Barknecht Sent: Tuesday, May 27, 2003 11:53 AM To: pd-list Subject: Re: [PD] PD Launcher/External Manager
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
But a related question is, what is preventing Windows from having a .pdrc? Anybody know? Having .pdrc be standard across all platforms would simplify this effort.
Windows doesn't have the notion of a HOME-directory (it doesn't even have a real "bin" or "PATH", like we're used to on Linux or OS-X).
So we would need to make a personal HOME dir for Pd on Windwows. Mozilla is a good example of how this could work. Just let the user create a Pd-Home like Mozilla lets them create a "Profile"-directory. Into that, we could then put the .pdrc and also some standard locations for externals and so on there.
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Chad A. Wood hat gesagt: // Chad A. Wood wrote:
Windows XP (and I think 2000?) has a kind of a "home" folder for each user. On XP at least, within the "Documents and Settings" folder, there is a folder corresponding the each user's name.
Do you know, if this is consistent accross the world? I know, that at work (at home I only run Linux) I also have this on W2000, but its called in german "Dokumente und Einstellungen". So we'd need something more general than just a path name. Maybe there is a registry setting for that? On Unix, one can get this info from the file /etc/passwd or the environment settings.
Frank Barknecht _ ______footils.org__
At a dos prompt if you type "set home" it shows you the homepath variable, which on my system points to the home-type folder I was talking about... that would probably work, right?
Chad
-----Original Message----- From: pd-list-admin@iem.kug.ac.at [mailto:pd-list-admin@iem.kug.ac.at]On Behalf Of Frank Barknecht Sent: Tuesday, May 27, 2003 4:48 PM To: PD List Subject: Re: [PD] PD Launcher/External Manager
Hallo, Chad A. Wood hat gesagt: // Chad A. Wood wrote:
Windows XP (and I think 2000?) has a kind of a "home" folder
for each user.
On XP at least, within the "Documents and Settings" folder, there is a folder corresponding the each user's name.
Do you know, if this is consistent accross the world? I know, that at work (at home I only run Linux) I also have this on W2000, but its called in german "Dokumente und Einstellungen". So we'd need something more general than just a path name. Maybe there is a registry setting for that? On Unix, one can get this info from the file /etc/passwd or the environment settings.
ciao
Frank Barknecht _ ______footils.org__
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Hallo, Chad A. Wood hat gesagt: // Chad A. Wood wrote:
At a dos prompt if you type "set home" it shows you the homepath variable, which on my system points to the home-type folder I was talking about... that would probably work, right?
Ah, wonderful. Then we indeed do have Home at least on XP, NT and 2000, and that's, where the pdrc can go.
Frank Barknecht _ ______footils.org__