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:

        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

        default.pdsettings - overridden by user prefs
    Mac OS X
        org.puredata.pd.plist - overridden by user prefs

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.

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.


Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> 

Reply via email to