there is no .pdrc for windows at this time. The only way to get libs loaded on windows is to run pd as a .bat file.
m.
-----Original Message----- From: pd-list-admin@iem.at [mailto:pd-list-admin@iem.at]On Behalf Of [·] Sent: Monday, March 29, 2004 5:49 AM To: cyrille henry Cc: pd-list@iem.at Subject: Re: [PD] pd 0.37.1 Windows installer release candidate
On Mon, 29 Mar 2004, cyrille henry wrote:
I'm on windows, I changed the pd.bat command line to load pmpd lib. it's ok when I strat pd with this .bat but when I double click on a pd file, the lib is not load. so, what should I change, to add differents flag while double click on pd file?
if there's something like the .pdrc file in windos, i would use this. it works like a config file, to load libs and stuff and set parameters at startup.
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Scanned on 29 Mar 2004 13:53:30 Scanning by http://erado.com
Scanned on 29 Mar 2004 16:26:43 Scanning by http://erado.com
On Mon, 29 Mar 2004, Matthew Allen wrote:
there is no .pdrc for windows at this time. The only way to get libs loaded on windows is to run pd as a .bat file.
On Mon, 29 Mar 2004, Hans-Christoph Steiner wrote:
Windows has no .pdrc unfortunately. Anyone know why the .pdrc file is disabled on Windows? I know my .emacs file works fine with Emacs NT, so Windows can do files that start with a ".".
Okay, I'm a bit tired of seeing that Windows doesn't have pdrc support... so here's one fix for that. In the IMPD branch I have patched s_main.c and s_path.c so that it looks for .pdrc in one additional directory, which is the main directory of Pd.
For example: Linux default: /usr/local/lib/pd/ Other common default: /usr/lib/pd/ My setup: /home/matju/lib/pd/ Windows: c:/program/pd/
Essentially I am using the value of sys_libdir.
This could (and probably should) be ported over to the devel_0_37 branch.
The #ifdef UNIX part is down to two lines, and I guess a similar #ifdef MSW could be added, which would check for both $HOMEPATH and $HOME, using GetEnvironmentVariable instead of getenv, but I don't have any win32 to test, so I will let someone else do it, if anyone feels a need for it.
Mathieu Bouchard http://artengine.ca/matju
On Monday, Mar 29, 2004, at 22:41 America/New_York, Mathieu Bouchard wrote:
On Mon, 29 Mar 2004, Matthew Allen wrote:
there is no .pdrc for windows at this time. The only way to get libs loaded on windows is to run pd as a .bat file.
On Mon, 29 Mar 2004, Hans-Christoph Steiner wrote:
Windows has no .pdrc unfortunately. Anyone know why the .pdrc file is disabled on Windows? I know my .emacs file works fine with Emacs NT, so Windows can do files that start with a ".".
Okay, I'm a bit tired of seeing that Windows doesn't have pdrc support... so here's one fix for that. In the IMPD branch I have patched s_main.c and s_path.c so that it looks for .pdrc in one additional directory, which is the main directory of Pd.
For example: Linux default: /usr/local/lib/pd/ Other common default: /usr/lib/pd/ My setup: /home/matju/lib/pd/ Windows: c:/program/pd/
Essentially I am using the value of sys_libdir.
This could (and probably should) be ported over to the devel_0_37 branch.
The #ifdef UNIX part is down to two lines, and I guess a similar #ifdef MSW could be added, which would check for both $HOMEPATH and $HOME, using GetEnvironmentVariable instead of getenv, but I don't have any win32 to test, so I will let someone else do it, if anyone feels a need for it.
I don't think that that's necessary in order to get .pdrc files working on Windows. Windows can have a home dir set like UNIX, so it could just as easily go there. But it would probably make sense to have a .pdrc file in the App dir, but perhaps it should then have a different name, like pd.rc or pd.conf.
.hc
I don't think that that's necessary in order to get .pdrc files working on Windows. Windows can have a home dir set like UNIX, so it could just as easily go there. But it would probably make sense to have a .pdrc file in the App dir, but perhaps it should then have a different name, like pd.rc or pd.conf.
it now checks for .pdrc in ~/My Documents/ on windows as well as the base app dir it could just as easily be stored in User/Application Data/pd/pd.ini but until the gui pdrc editor works its proably better to not make users have to track down such a nasty dir...
.hc
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Monday, Mar 29, 2004, at 23:45 America/New_York, carmen wrote:
I don't think that that's necessary in order to get .pdrc files working on Windows. Windows can have a home dir set like UNIX, so it could just as easily go there. But it would probably make sense to have a .pdrc file in the App dir, but perhaps it should then have a different name, like pd.rc or pd.conf.
it now checks for .pdrc in ~/My Documents/ on windows as well as the base app dir it could just as easily be stored in User/Application Data/pd/pd.ini but until the gui pdrc editor works its proably better to not make users have to track down such a nasty dir...
This is great, thanks for doing this. But I have one small question.
Why not put .pdrc in ~ like it does on every other platform? I know
that its not a commonly used directory in Windows, but it is also where
your Desktop folder is, as well as My Documents, etc. Plus "My
Documents" is meant to be for the user's data, and .pdrc is more like a
config file. I suppose in the long run, pd could search a few
directories for .pdrc files, like the root of the Pd dir, or
"Application Data".
.hc
Zitiere Hans-Christoph Steiner hans@eds.org:
I don't think that that's necessary in order to get .pdrc files working
on Windows. Windows can have a home dir set like UNIX, so it could just
as easily go there. But it would probably make sense to have a .pdrc file in the App dir, but perhaps it should then have a different name,
like pd.rc or pd.conf.
i fully agree with having another pdrc-file that can be used system-wide. e.g: our setting is a s follows: ew have tons of computers (with different hardware) and tons of students (with "different software"). home-directories are shared between all the computers. so it would ease maintainance if there was some system-specific pdrc-file (on unix systems i would vote for /etc/pdrc or /etc/pd/pdrc) and user-specific files in there home (btw: i always thought that there is some "home"-directory on windows; at least there is some "Applications and Settings" directory (on
=w2k); is this not available t opd somehow due to the "DOS"-mode of pd ?)
the users-preferences should overwrite the system defaults. (but why ? it just makes more sense to me), but they should really be merged.
and being at this, we would like a command flag "-rcfile <file>" to solely use another rcfile.
mf.a.dr IOhannes
On Mon, 29 Mar 2004, Hans-Christoph Steiner wrote:
In the IMPD branch I have patched s_main.c and s_path.c so that it looks for .pdrc in one additional directory, which is the main directory of Pd. Essentially I am using the value of sys_libdir.
I don't think that that's necessary in order to get .pdrc files working on Windows. Windows can have a home dir set like UNIX, so it could just as easily go there.
There's a difference between necessary and convenient. I'm not sure Windows users should be required to set HOME themselves, and I don't think it's set by default, but then, what do I know about win32.
but perhaps it should then have a different name, like pd.rc or pd.conf.
Yeah, I recommended "pd.ini" when Carmen told me win32 apps usually refuse to edit files named like ".pdrc"...
On Tue, 30 Mar 2004 zmoelnig@iem.at wrote:
the users-preferences should overwrite the system defaults. (but why ? it just makes more sense to me), but they should really be merged.
Can you be more clear on what you call overwrite (you probably mean override) and what's the difference with merged.
and being at this, we would like a command flag "-rcfile <file>" to solely use another rcfile.
That could be an interesting option, though I'm trying to keep in mind that there will be a pdrc editor dialog real soon now and what would be a good way for that dialog to handle -rcfile and defaults and fallbacks/merges/overrides/however-we-call-it, in a friendly manner...
Mathieu Bouchard http://artengine.ca/matju
On Thu, 1 Apr 2004, Mathieu Bouchard wrote:
and being at this, we would like a command flag "-rcfile <file>" to solely use another rcfile.
That could be an interesting option, though I'm trying to keep in mind that there will be a pdrc editor dialog real soon now and what would be a good way for that dialog to handle -rcfile and defaults and fallbacks/merges/overrides/however-we-call-it, in a friendly manner...
Actually I was thinking of -rcfile as "including" another rcfile, which would be doable from inside another rcfile, just like all other options can be put in an rcfile (though I admit it's weird to put -listdev or -help in an rcfile... heh)
I wasn't exactly thinking of the possibility of using a given rcfile _instead_ of the default rcfile lookup, and actually, both behaviours seem to be useful in some way... so would we need two options for that or...?
Mathieu Bouchard http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Yeah, I recommended "pd.ini" when Carmen told me win32 apps usually refuse to edit files named like ".pdrc"...
That's because it doesn't have a file suffix. I would suggest "pd.rc" on Windos as rc-filename, which is more similar to its unix name. It also has another syntax then the .ini files common on Win.
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
Yeah, I recommended "pd.ini" when Carmen told me win32 apps usually refuse to edit files named like ".pdrc"...
That's because it doesn't have a file suffix. I would suggest "pd.rc" on Windos as rc-filename, which is more similar to its unix name. It also has another syntax then the .ini files common on Win.
I would suggest keeping it simple and having a pd.bat file as is currently the case. There is nothing you can do in .pdrc that you can't do in pd.bat, right? The code for .pdrc simply parses .pdrc as a command line.
Martin
On Thu, 1 Apr 2004, Martin Peach wrote:
I would suggest keeping it simple and having a pd.bat file as is currently the case. There is nothing you can do in .pdrc that you can't do in pd.bat, right? The code for .pdrc simply parses .pdrc as a command line.
Sure, us Linux/OSX users can have the Pdrc editor working, while retro dudes on Losedows can edit PD.BAT in NotePad.
BDSM types can replace NotePad by EDLIN.COM and wear black leather underwear while doing it.
Right?
Mathieu Bouchard http://artengine.ca/matju
Mathieu Bouchard wrote:
On Thu, 1 Apr 2004, Martin Peach wrote:
I would suggest keeping it simple and having a pd.bat file as is currently the case. There is nothing you can do in .pdrc that you can't do in pd.bat, right? The code for .pdrc simply parses .pdrc as a command line.
Sure, us Linux/OSX users can have the Pdrc editor working, while retro dudes on Losedows can edit PD.BAT in NotePad.
BDSM types can replace NotePad by EDLIN.COM and wear black leather underwear while doing it.
Right?
...or else make a dll for the dozerz that intercepts directx calls to the graphics card and decides if the mouse is clicking on a file called .pdrc. Then add a bunch of cryptically enhanced entries to the registry that specify which directories this works in and also how long the feature lasts before the default user's credit card is automagically debited for the upgrade.
Martin
On Thu, 1 Apr 2004, Martin Peach wrote:
...or else make a dll for the dozerz that intercepts directx calls to the graphics card and decides if the mouse is clicking on a file called .pdrc. Then add a bunch of cryptically enhanced entries to the registry that specify which directories this works in and also how long the feature lasts before the default user's credit card is automagically debited for the upgrade.
Oh, back to serious stuff, now, here's a prototype of whatever PD.BAT fans will be avoiding:
http://artengine.ca/matju/impd/gallery/pdrc_1.gif
Mathieu Bouchard http://artengine.ca/matju
Mathieu Bouchard wrote:
here's a prototype of whatever PD.BAT fans will be avoiding:
Very nice. This is also my preferred means of interacting with a preferences file that should also be a human-readable text file. I see no reason why the handler for your dialog couldn't write out a pd.bat file when the user clicks OK or Apply.
Martin
Hallo, Martin Peach hat gesagt: // Martin Peach wrote:
I see no reason why the handler for your dialog couldn't write out a pd.bat file when the user clicks OK or Apply.
Why a .bat file? This feels crude in my eyes. The natural thing would be, to start using a real config file instead of a list of command line options in a file or even a .bat file. With a .bat or .sh script you cannot start the Pd binary itself anymore using set options, with a command list, you cannot include the "-rcfile" command option because that would loop if used in pdrc.
A real config file (or registry or whatever) would even allow comments like in the old days of Pd 0.31 or so.
Maybe something like the .ini-file format, which is common on both Win and Unix (don't know Mac) would be appropriate, maybe extended by comments
[Audio] System: jack Channels: 4
[Paths] path1="/usr/lib/pd:/home/fbar/pd/" path2="/usr/lib/flext/"
Of course the "#"- and "="-format would be even more powerful:
# which audiosystem to use audiosystem = asio
# add paths: paths = /usr/lib/pd
# append another path paths = $(paths):/home/pd
libs = iemlib1:iemlib2
# use this only sometimes: # libs = $(libs):Gem
But a .bat or .sh file is not platform independent and thus not appropriate in the long run IMO.
Frank Barknecht _ ______footils.org__
Frank Barknecht wrote:
But a .bat or .sh file is not platform independent and thus not appropriate in the long run IMO.
In this case XML would be the way to go because it is entirely human-readable ascii text and totally platform independent.
Martin
On Fri, 2 Apr 2004, Martin Peach wrote:
Frank Barknecht wrote:
But a .bat or .sh file is not platform independent and thus not appropriate in the long run IMO.
In this case XML would be the way to go because it is entirely human-readable ascii text and totally platform independent.
If you want me to use XML, it'll cost you even more money than the .BAT, because the retro spin is cute, but the buzzword-compliancy is hip, and that's worth solid money.
Mathieu Bouchard http://artengine.ca/matju
Hallo, Mathieu Bouchard hat gesagt: // Mathieu Bouchard wrote:
If you want me to use XML, it'll cost you even more money than the .BAT, because the retro spin is cute, but the buzzword-compliancy is hip, and that's worth solid money.
Regarding "retro": I like how you spell out ".BAT" in uppercase. ;)
Frank Barknecht _ ______footils.org__
Mathieu Bouchard wrote:
On Fri, 2 Apr 2004, Martin Peach wrote:
Frank Barknecht wrote:
But a .bat or .sh file is not platform independent and thus not appropriate in the long run IMO.
In this case XML would be the way to go because it is entirely human-readable ascii text and totally platform independent.
If you want me to use XML, it'll cost you even more money than the .BAT, because the retro spin is cute, but the buzzword-compliancy is hip, and that's worth solid money.
Yes I could see that driving me into bankruptcy, since adding pd.bat support involves about one line of text in the .pdrc/pd.bat file, but XML has all those funny angle brackets that are probably about $100 a gram at least.;<
Martin
On Fri, 2 Apr 2004, Martin Peach wrote:
Mathieu Bouchard wrote:
here's a prototype of whatever PD.BAT fans will be avoiding:
Very nice. This is also my preferred means of interacting with a preferences file that should also be a human-readable text file. I see no reason why the handler for your dialog couldn't write out a pd.bat file when the user clicks OK or Apply.
Ok, if I am to add support for .BAT files for you, come to my place with a 149.99$ cheque. We can meet at Jarry station. I will wear a plaid flannel shirt for the occasion (or something fluo if you prefer). I will hand you a BONUS 5.25" disk of shareware.
Oh, and now that I think of it, if you don't have the money, then we can negotiate that in music records. I mean real records, the 33rpm vinyls... well, 45rpm UK singles/EP's also are interesting, of course. (Do you have any Dépêche Mode?)
Mathieu Bouchard http://artengine.ca/matju
hi.
Mathieu Bouchard wrote:
On Mon, 29 Mar 2004, Hans-Christoph Steiner wrote:
the users-preferences should overwrite the system defaults. (but why ? it just makes more sense to me), but they should really be merged.
Can you be more clear on what you call overwrite (you probably mean override) and what's the difference with merged.
of course i meant override.
and thinking of it, i don't know many conflicting options. i was just proposing that the system file was read before the users preferences.
and being at this, we would like a command flag "-rcfile <file>" to solely use another rcfile.
That could be an interesting option, though I'm trying to keep in mind that there will be a pdrc editor dialog real soon now and what would be a good way for that dialog to handle -rcfile and defaults and fallbacks/merges/overrides/however-we-call-it, in a friendly manner...
well i guess we could just set up a policy like: if you start pd with the "-rcfile"-option, then this file would be the only one included (and no default file would be used) if a preferences-file holds the "-rcflag"-line, then this line would be included at the very place.
this would make the system-wide rcfile simple, as any user just would (have to) include the same file (at the beginning of his/her rcfile of wherever it would be desired)
mfg.as.dr IOhannes
On Thursday, Apr 1, 2004, at 04:03 America/New_York, Mathieu Bouchard
wrote:
On Mon, 29 Mar 2004, Hans-Christoph Steiner wrote:
In the IMPD branch I have patched s_main.c and s_path.c so that it looks for .pdrc in one additional directory, which is the main directory of Pd. Essentially I am using the value of sys_libdir.
I don't think that that's necessary in order to get .pdrc files
working on Windows. Windows can have a home dir set like UNIX, so it could
just as easily go there.There's a difference between necessary and convenient. I'm not sure Windows users should be required to set HOME themselves, and I don't
think it's set by default, but then, what do I know about win32.
Its set automatically, its called %USERPROFILE%
but perhaps it should then have a different name, like pd.rc or pd.conf.
Yeah, I recommended "pd.ini" when Carmen told me win32 apps usually
refuse to edit files named like ".pdrc"...
I don't think it should be .ini because that means a specific type of
Windows file. It should be something like pdrc.txt. Then editors will
handle it correctly.
On Tue, 30 Mar 2004 zmoelnig@iem.at wrote:
the users-preferences should overwrite the system defaults. (but why ? it just makes more sense to me), but they should really be merged.
Can you be more clear on what you call overwrite (you probably mean override) and what's the difference with merged
For simplicity's sake, its probably best to have the system .pdrc
ignored if the user sets one.
and being at this, we would like a command flag "-rcfile <file>" to solely use another rcfile.
That could be an interesting option, though I'm trying to keep in mind that there will be a pdrc editor dialog real soon now and what would
be a good way for that dialog to handle -rcfile and defaults and fallbacks/merges/overrides/however-we-call-it, in a friendly manner...
I like this option as including another conf file, rather than
replacing the existing one.
As for the .bat files, I say ditch them. Then pd will behave the same
on all platforms. If people really want to continue using batch
files, they can write a bunch of pdrc.txt files, then in the batch file
put: pd --rcfile my-pdrc.txt This will make handling batch files
easier too.
.hc ________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to
realize his wishes.
Now that he can realize them, he must either change them, or perish.
-William Carlos Williams
Zitiere Hans-Christoph Steiner hans@eds.org:
the users-preferences should overwrite the system defaults. (but why
?
it just makes more sense to me), but they should really be merged.
Can you be more clear on what you call overwrite (you probably mean override) and what's the difference with merged
For simplicity's sake, its probably best to have the system .pdrc
ignored if the user sets one.
but that is just my point: of course it is not important to *you* when you are in a single-user single-host environment. but i am not and i am looking for a way to handle this correctly: multiple users have multiple preferences (mainly library and path settings) mutliple hosts have also multiple preferences (mainly based on their hardware) i *really* think there should be a way to handle both of these preferences (even in terms of simplicity)
looking at 2 very different operating systems i notice: a) linux (and i do think: most if not all unix-style os's including macOS): many applications share the users .rc file and an /etc/rc file to separate system and users preferences b) windows: in the system-registry there are 2 major branches: HKEY_LOCAL_USER and HKEY_LOCAL_MACHINE (or so) to represent these 2 preferences too
so i ask: why do we think that any known modern OS that can handle multiple users does separate user- and host-preferences ? do we have to be more clever than all those people who have written os's for years ? just for "simplicity".
I like this option as including another conf file, rather than
replacing the existing one.
hmm. i am not sure about this because i don't see the reason ("for simplicity" ;-)) if i'd wanted to include several rcfiles i could use several "-rcfile"-options. i just think it is more flexible. and it gives the user the power to ignore (say) the systemwide rcfile without having to know it.
and there are some options that cannot be undone with other options, so merging will not be very flexible in this way.
As for the .bat files, I say ditch them. Then pd will behave the same
on all platforms. If people really want to continue using batch
files, they can write a bunch of pdrc.txt files, then in the batch fileput: pd --rcfile my-pdrc.txt This will make handling batch files
easier too.
and of course they wouldn't even have to do it. they will still be able to use all the command-line arguments and create bat/sh files like "pd -lib /usr/local/lib/pd/extra -helppath /usr/local/lib/pd/doc/5.reference/ -inchannels 2 -outchannels 2" (or are we discussing about *removing* command-line arguments in favour of preference-files ? i am strongly agains this)
mfg.a.dr IOhannes
On Monday, Apr 5, 2004, at 02:36 America/New_York, zmoelnig@iem.at
wrote:
Zitiere Hans-Christoph Steiner hans@eds.org:
the users-preferences should overwrite the system defaults. (but why
?
it just makes more sense to me), but they should really be merged.
Can you be more clear on what you call overwrite (you probably mean override) and what's the difference with merged
For simplicity's sake, its probably best to have the system .pdrc ignored if the user sets one.
but that is just my point: of course it is not important to *you* when
you are in a single-user single-host environment. but i am not and i am looking for a way to handle this correctly: multiple users have multiple preferences (mainly library and path
settings) mutliple hosts have also multiple preferences (mainly based on their
hardware) i *really* think there should be a way to handle both of these
preferences (even in terms of simplicity)looking at 2 very different operating systems i notice: a) linux (and i do think: most if not all unix-style os's including
macOS): many applications share the users .rc file and an /etc/rc file to separate
system and users preferences b) windows: in the system-registry there are 2 major branches:
HKEY_LOCAL_USER and HKEY_LOCAL_MACHINE (or so) to represent these 2 preferences tooso i ask: why do we think that any known modern OS that can handle
multiple users does separate user- and host-preferences ? do we have to be more clever than all those people who have written
os's for years ? just for "simplicity".I like this option as including another conf file, rather than replacing the existing one.
hmm. i am not sure about this because i don't see the reason ("for
simplicity" ;-)) if i'd wanted to include several rcfiles i could use several
"-rcfile"-options. i just think it is more flexible. and it gives the user the power to ignore (say) the systemwide rcfile
without having to know it.and there are some options that cannot be undone with other options,
so merging will not be very flexible in this way.
Ok, so let's look at some examples of system vs. user conf files and
where they are merged or not. bash, tcsh, etc. do merging, but they
are hardly aimed at the general computer using population. But it does
work well in my experience.
As for Windows registry key, its my guess that they generally override
rather than merge. Or for the most part they are completely separated
into System-wide things (CLASSES_ROOT) or per-user things
(CURRENT_USER). Upon a quick glance I couldn't find any overlap
between LOCAL_MACHINE and CURRENT_USER. Do you know of any specific
examples?
In MacOS X, apps almost always only have per-user conf files
(~/Library/Preferences). There are some stored in
/Library/Preferences, but as far as I can tell, they are not in
~/Library/Preferences. (com.apple.soundpref.plist, for example).
So if we are going to attempt the merging behavior, then I think we
need to find a good example of where it is working well.
As for the .bat files, I say ditch them. Then pd will behave the same
on all platforms. If people really want to continue using batch files, they can write a bunch of pdrc.txt files, then in the batch
fileput: pd --rcfile my-pdrc.txt This will make handling batch files easier too.
and of course they wouldn't even have to do it. they will still be able to use all the command-line arguments and
create bat/sh files like "pd -lib /usr/local/lib/pd/extra -helppath
/usr/local/lib/pd/doc/5.reference/ -inchannels 2 -outchannels 2" (or are we discussing about *removing* command-line arguments in
favour of preference-files ? i am strongly agains this)
I think we are all in agreement here for sure.
.hc
There is no way to peace, peace is the way.
-A.J. Muste
re: HKLM/CLASSES_ROOT/CURRENT_USER/SOFTWARE/PURE-DATA/PD/USERDATA/PREFS/AUDIODEV
...and to tweak a setting, you open up regedit, do a search that takes 30 seconds to complete..and of course if you decide to reinstall windows or change machines, wave goodbye to your settings unless you manually exported it to a file..i think windows is great, but the registry is certainly not in the list of reasons...
so it seems everyone is particular to a certain flavour of storing user configuration data, but nobody has an opinion on storing data after the program is actually launched -- "pool" is great, but you dont get sick of cabling/sending/recieving stuff into it all the time ? the little clicky-box thing i remember from playing aroudn w/ max was quite cool, well that & the 'randomize parameters' feature in samplitude.. no idea on how difficult this would be to do, but it seems an app named 'pure data' should be able to take a snapshot of all the current numbers/control data (what, 10K of ram?) for later retrival, exporting to file, building up a sequence of snapshots to morph between in live situations, or storing for later analysis, etc...
On Monday, Apr 5, 2004, at 15:56 America/New_York, carmen wrote:
re:
HKLM/CLASSES_ROOT/CURRENT_USER/SOFTWARE/PURE-DATA/PD/USERDATA/PREFS/ AUDIODEV...and to tweak a setting, you open up regedit, do a search that takes
30 seconds to complete..and of course if you decide to reinstall
windows or change machines, wave goodbye to your settings unless you
manually exported it to a file..i think windows is great, but the
registry is certainly not in the list of reasons...
I really think we should avoid using the registry unless absolutely
necessary. It generally doesn't make things easier in a cross-platform
app like this, and its messy, and will break drag-n-drop installing.
Text files are much more flexible and easier to deal with, even on
Windows.
so it seems everyone is particular to a certain flavour of storing
user configuration data, but nobody has an opinion on storing data
after the program is actually launched -- "pool" is great, but you
dont get sick of cabling/sending/recieving stuff into it all the time
? the little clicky-box thing i remember from playing aroudn w/ max
was quite cool, well that & the 'randomize parameters' feature in
samplitude.. no idea on how difficult this would be to do, but it
seems an app named 'pure data' should be able to take a snapshot of
all the current numbers/control data (what, 10K of ram?) for later
retrival, exporting to file, building up a sequence of snapshots to
morph between in live situations, or storing for later analysis, > etc...
Have you checked out the [state] object? It does this, albeit it
doesn't save the state of every GUI obj. But its better than nothing.
.hc
http://at.or.at/hans/
On Mon, 5 Apr 2004, Hans-Christoph Steiner wrote:
Have you checked out the [state] object? It does this, albeit it doesn't save the state of every GUI obj. But its better than nothing.
It did save the state of GUI objects initially. This feature got lost during the inclusion of the GUI objects into pd itself. Yes, it would be easy to add it again, but we already discussed the drawbacks of such a system. Personally I use state a lot, because it saves me a lot of headaches. Its not perfect, but for me it does it's job perfectly. I am open for suggestions and additions.
Guenter
Have you checked out the [state] object? It does this, albeit it doesn't save the state of every GUI obj. But its better than nothing.
cool, had no idea about this object..if anything it should provide a basis for how to possibly make a v2.0...
It did save the state of GUI objects initially. This feature got lost during the inclusion of the GUI objects into pd itself. Yes, it would be easy to add it again, but we already discussed the drawbacks of such
searched the mail archive but couldnt find this... do you mean drawbacks of having state-saving handled by an external rather than the app itself, or something else?
Hallo, carmen hat gesagt: // carmen wrote:
searched the mail archive but couldnt find this... do you mean drawbacks of having state-saving handled by an external rather than the app itself, or something else?
It currently isn't clear how to handle hierarchical state saving of abstractions in use, there is a need for saving substates in memory and some of us (at least I) think that a state is not only made up of things that are kept in visible GUI objects. Also I want to be able to control the save file and what goes into it more than [state] or possibly Max' [preset] allows.
But [state] still is useful, and would be even more useful, if it: a) would include the GUIs again and b) would get an outlet that can be used to send state values somewhere else. This way state could be used free of its state-file features and for example just feed a [pool] object.
Just some thoughts...
Frank Barknecht _ ______footils.org__
But [state] still is useful, and would be even more useful, if it: a) would include the GUIs again and b) would get an outlet that can be used to send state values somewhere else. This way state could be used free of its state-file features and for example just feed a [pool] object.
is there an existing way to to recieve all active sends from a single object? pool's output channeled into a send13 does a fine job of recalling saved settings but is there a similar way to 'feed' it, ie the opposite of maxlib's "remote"...it would probably be a good intermediary solution...
Hi,
carmen ix@replic.net wrote:
is there an existing way to to recieve all active sends from a single object? pool's output channeled into a send13 does a fine job of recalling saved settings but is there a similar way to 'feed' it, ie the opposite of maxlib's "remote"...it would probably be a good intermediary solution...
I know neither send13 nor remote (but probably should take a look). I developed a state saving system for the RRADical project which I called Memento. It uses pool inside, but wraps it to get a consistent, easy to use and network transparent (OSC-enabled) was of setting, changing and restoring state. There is a tutorial available. The communication between the state manager - called [originator] - and the actuall objects whose state is to manage is done by an abstraction called [commun].
You can get the latest snapshot of the whole RRADical stuff by me here: http://footils.org/cms/pydiddy/wiki/RradicalPd
Frank Barknecht _ ___footils.org_
On Tue, 6 Apr 2004, Frank Barknecht wrote:
Hallo, carmen hat gesagt: // carmen wrote:
searched the mail archive but couldnt find this... do you mean drawbacks of having state-saving handled by an external rather than the app itself, or something else?
It currently isn't clear how to handle hierarchical state saving of abstractions in use, there is a need for saving substates in memory and some of us (at least I) think that a state is not only made up of things that are kept in visible GUI objects. Also I want to be able to control the save file and what goes into it more than [state] or possibly Max' [preset] allows.
But [state] still is useful, and would be even more useful, if it: a) would include the GUIs again and b) would get an outlet that can be used to send state values somewhere else. This way state could be used free of its state-file features and for example just feed a [pool] object.
It shouldn't be too hard to separate the state reading from state in order to have such functionality.
In order to summarize the discussions we had about state saving, the general problems are:
which object. This can partly be solved with the receives that GUI objects currently have. But how would this be handled in abstractions ? You will always have to use some explicit naming hacks.
the object state of each object. Implementing this would make it a lot easier to add the GUI objects again, and it would make it possible to add state saving to objects like float, spigot settings, etc.
maintain simplicity. Most users of pd are not programmers, keeping it simple is one of the main goals.
Guenter