[PD] (wip) Preferences file.

Christof Ressi christof.ressi at gmx.at
Mon Feb 20 15:00:57 CET 2017


> if you do want to have multiple configurations for the same flavour of
> Pd (e.g. pd-vanilla), you can already simply use batch-files.
> all the things settable via the config are also settable via cmdline

That was also my first thought! Not only can you have a dedicated config for each seperate Vanilla installation, you can also have different configs for the same installation, such as: "Pd-no-gui.bat" or "Pd-no-audio.bat". IMHO, it doesn't get more straightforward than that. 

Writing a simple Pd startup script is certainly not more difficult/awkward than writing an XML file and IMHO it's also easier to read.
You can also use the Pd icon for your scripts, so you won't scare people :-D.

Christof



> Gesendet: Montag, 20. Februar 2017 um 11:15 Uhr
> Von: "IOhannes m zmoelnig" <zmoelnig at iem.at>
> An: pd-list at lists.iem.at
> Betreff: Re: [PD] (wip) Preferences file.
>
> On 2017-02-20 03:08, Lucas Cordiviola wrote:
> >> What are the practical problems with using the current
> >> format for the Pd preferences file under Linux?
> > 
> > I don't know,
> 
> so you would like to replace tried-and-tested code with something else
> that is known to be hard to implement correctly.
> for no appararent reason (apart from breaking compatibility).
> 
> i would say, this is a strinct "nono"
> 
> 
> apart from that, XML is a buzzword of the 90ies, and has been superceded
> by various better formats.
> nobody in their right mind would jump on the XML train these days (OSX's
> plist is an XML file; but it has been like that for ever; they also
> haven't changed it to json or whatever, probably because they also
> prefer to not replace tried-and-tested code with new buggy code for no
> apparaent reasons.)
> 
> 
> > I'm a windows user, and think that the linux .pdsettings will be a better substitute for the actual windows method of writing in the registry.
> 
> how so?
> 
> the differences between the .pdsettings stored on the filesystem resp.
> in the w32 registry are really small.
> the registry entry is really just the .pdsettings, but with the data
> stored on a "virtual filesystem" (the registry), that already provides a
> parser for the key/value mapping required by .pdsettings.
> 
> i think part of the hate for the registry stems from the repeated mantra
> that "you can kill your system if you don't know what you do when
> editing the registry".
> in principle, i think the mantra is correct.
> but the problem does not come from the registry itself, but because you
> can shoot your system if fuck your system configuration.
> moving the system configuration to the filesystem would only change the
> mantra to "you can kill your system if you don't know what you do when
> editing files". (which is correct as well).
> 
> 
> > And think that it should live on the pd/bin dir & not in a user dir. 
> 
> hmm, no.
> 
> in general, the pd/bin dir is a read-only directory.
> this is a good thing, as it helps ensuring that some random malware you
> just clicked on in InternetExplorer10 won't be capable of changing Pd
> itself (if you can write to pd\bin to create your preferences file, then
> you can also replace pd\bin\pd.exe)
> 
> things might be different on *your* personal setup, e.g. because you run
> Pd from a FAT32 formatted USB-stick (which doesn't allow any access
> control); or because you are running all applications as Administrator
> (which bypasses a lot of access control). but that doesn't change the
> general principle¹. some things have changed since the 80ies...
> 
> also, there is a very good reason that virtually all OSs have agreed on
> central storage locations for configuration *besides* the
> application-folders.
> 
> 
> > to disallow sharing prefs. on multiple installations. (Pd, Purr-Data, PsVST)
> 
> hmm, no.
> the proper way to disallow sharing prefs, is by using different
> namespaces for all these projects.
> if Pd-vanilla uses ~/.pdsettings and ~/.config/pure-data/ for its
> configuration, then other programs simply should not (if they don't want
> to share prefs, that is).
> instead they should use ~/.config/pd-l2ork/ or whatever.
> problem solved.
> 
> if you do want to have multiple configurations for the same flavour of
> Pd (e.g. pd-vanilla), you can already simply use batch-files.
> all the things settable via the config are also settable via cmdline
> args (if they are not, you should file a bugreport).
> "pd -noprefs -jack -channels 16".
> 
> fgadr
> IOhannes
> 
> 
> 
> ¹ having said this, there *is* already a way to embed preferences on OSX
> and linux alongside your binary.
> just put a default.pdsettings file into your PD directory (on linux) or
> a plist-file with the name of "org.puredata.pd" into your App-bundle (on
> OSX).
> this seems to be somewhat broken, at least on linux (it get's ignored if
> you also have a ~/.pdsettings file), and might be worth fixing.
> 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>



More information about the Pd-list mailing list