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.