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

On Apr 10, 2009, at 4:22 PM, IOhannes m zmölnig wrote:

hi

Miller Puckette wrote:

...

I think this is a good idea, but don't know in detail how to do it. Patches should be able to have a say as to what they "prefer" (beyond what's available via the declare object) but they can't just smash
over everything - for instance, they might not know what audio device they should use.

actually my need comes from wanting to automatically open a certain
patch when starting Pd. so - while i think that every configuration i can store in a patch
is a great plus - this doesn't necessarily solve my problems.

i think a good idea would be to automatically look for a special
patch (e.g. bin/autostart.pd) and always open it.

i would even go as far as use this patch to store all the
preferences (and get rid of the system-specific preference system).

for the sake of clarity, this patch should then be opened invisibly. if somebody wanted to edit it, they can always manually open it.

something like this had been discussed on this list already, iirc.

Yes, I fully agree with this. For whatever reason, I use the word
"startup" perhaps "autostart" is a better word. Here's how I think it
should work:

• pd should load everything it a folder called "autostart"
• Pd should load any file in the path called "autostart.*"

So Pd would then load autostart.pd_linux, autostart.tcl,
autostart .pd, autostart.pd_lua, etc. I made a working sketch of this
idea in pd-devel, it loads Tcl code to modify the GUI. Check out the
'startup' folder.

.hc

...

O've started putting local config files in some of my patches for
which I have versions for 3 different audio setups the patch has to run
in - I just use loadbang and textfile :)

not a bad idea though not very feasible if you want to enable/ disable e.g "-rt", is it? out of curiosity: do you have lines like "pd audio-dialog 0 0 0 0 2
0 0 0 0 0 0 0 2 0 0 0 44100 50 -1;" in this textfile?

mfga.sdr IOhannes

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore