> 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" <[email protected]> > An: [email protected] > 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. > > > > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
