Hans-Christoph Steiner wrote:
The settings in patches should override any of these settings, IMHO. I
would like to see more of that kind of stuff. For example, instead of a
single 'audio-dialog' message, it would be very handy to have individual
messages for each configuration item, like "pd sample-rate 48000", "pd
use-callbacks 1", "pd verbose 1", etc.
i fully agree.
though i would prefix every audio-dialog submessage with "audio" (e.g.
"pd audio-usecallbacks").
and i would use symbolic specifiers where possible, rather than numeric
enumerations (e.g. "pd audio-api 3" is so much harder to understand
compared to "pd audio-api MMIO" - though both messages are equally
likely to fail when switching OSs)
Here's what I know about embedded prefs files:
Pd-extended:
GNU/linux
default.pdsettings - overridden by user prefs
Mac OS X
org.puredata.pd.default.plist - overridden by any other prefs
org.puredata.pd.plist - overrides all other prefs
Windows
(nothing)
Pd-vanilla:
GNU/linux
default.pdsettings - overridden by user prefs
Mac OS X
org.puredata.pd.plist - overridden by user prefs
Windows
(nothing)
thanks for the info.
btw, what's the point of embedding a preferences file if it gets
overriden by the user prefs? esp since there is currently no way to only
specify "half" of the preferences (e.g. specify the sample-rate, but use
the users preferred audio-api)
Windows should have this too, IMHO, its just a question of how to
implement it. Maybe just a folder in the registry, like /Software/Pd
are the normal prefs and /Software/Pd/default are the default prefs.
hmm, setting the registry is not easily done (from a packagers point of
view) without an installer.
so i guess there is no additional benefit with respect to chosing
sensible defaults from within Pd.
anyhow, another idea along this lines: specifying an alternative
preference registry-path via a cmdline arg.
"pd -preferences /HKLU/Software/Pd/MyOtherPrefs"
on linux "pd -preferences ~/projects/MySuperPrefs" and likewise on osx.
but i am really afraid of the registry and would rather not have to
fuddle around there at all.
For Windows, I think it would be worthwhile having a file that overrides
all other settings so that people can bundle Pd into a standalone app
with its own prefs. Perhaps it could be like path/to/pd/pdsettings.txt
and just be a pdsettings file.
yep.
or as said in the other mail: make it /path/to/pd/pdsettings.pd
which is way more flexible.
I suppose the same code/idea could be used for GNU/Linux, but I think it
would be cooler to have Pd generate .debs.
while it might be cool to have Pd generate .debs (actually i doubt it
would be feasible; it would also be cool to have Pd generate .msi
installers; but i guess both are beyond the scope of an ordinary program
like Pd as they are both complex pieces of software (the .app is a bit
different as it can be acchieved with simple copying), i am not sure how
this relates to the problem of embedded preferences.
obviously you don't need embedded preferences on linux so much, as any
script (which in turn can just pass "-noprefs -alsa ..." to pd) is
virtually indistinguishable from a "real" application like Pd.
unlike osx and w32 where scripts are somehow considered non-real apps.
so i guess your auto-deb-ianizing Pd would create mainly create a nice
frontend script.
fgmasdr
IOhannes
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
