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