[PD] embedded preferences...

[IOhannes m zmölnig]

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