As I see, there are 2 types of compiled externals, but I'm not sure how to call them:
“single binaries”? (is that how we actually call it?)
“libraries” (but isn’t library and pack collection? Even abstraction
collections like list-abs? So how do we call this to differentiate in terminology? “Monolithic” distribution?
thanks
parser error.
gfmdsar>>IOhannes
Since you mention the key word “parser” for the possible coming prefs.file, do you think XML standards for writing suits for an easy parser?
XML is overkill for something as simple as a preferences file. -Jonathan
I'm all ears.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
XML is overkill for something as simple as a preferences file.
That is right.
But all characters, tabs, lf/cr or what ever con be hold inside <whatwewant> </whatwewant>
It could be a pseudo parser.
Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Sunday, February 19, 2017 2:15 PM To: Lucas Cordiviola; pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file.
parser error.
gfmdsar IOhannes
Since you mention the key word “parser” for the possible coming prefs.file, do you think XML standards for writing suits for an easy parser?
XML is overkill for something as simple as a preferences file.
-Jonathan
I'm all ears.
Mensaje telepatico asistido por maquinas.
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
XML is overkill for something as simple as a preferences file.
That is right. But all characters, tabs, lf/cr or what ever con be hold inside <whatwewant> </whatwewant>
What problem does that solve which a simple format doesn't solve? -Jonathan
It could be a pseudo parser.
Mensaje telepatico asistido por maquinas.
What problem does that solve which a simple format doesn't solve?
I don't know.
I`m putting something on the table, in case a simple file format not feet our cross-platforms needs.
How do we know if a simple file format is all we need?
If a simple one is enough, better, btw.
Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Sunday, February 19, 2017 3:01 PM To: Lucas Cordiviola; pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file.
XML is overkill for something as simple as a preferences file.
That is right.
But all characters, tabs, lf/cr or what ever con be hold inside <whatwewant> </whatwewant>
What problem does that solve which a simple format doesn't solve?
-Jonathan
It could be a pseudo parser.
Mensaje telepatico asistido por maquinas.
#yiv2808832499 #yiv2808832499 -- P {margin-top:0;margin-bottom:0;}#yiv2>>What problem does that solve which a simple format doesn't solve?
I don't know. I`m putting something on the table, in case a simple file format not feet our cross-platforms needs. How do we know if a simple file format is all we need?
Because keys, values, and key/value pairs in the Pd preferences are themselves simple: keys: ascii string containing no spaces values: number, numbers separated by whitespace, ascii string with no whitespace, and file paths. Finally, the key/value pairs in Pd preferences are simple enough that there isn't a need to nest key/value pairs inside other key/value pairs.
You would spend more time figuring out how to parse the XML tags in C than you would parsing the actual data contained in them. -Jonathan
If a simple one is enough, better, btw.
Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Sunday, February 19, 2017 3:01 PM To: Lucas Cordiviola; pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file. >> XML is overkill for something as simple as a preferences file.
That is right. But all characters, tabs, lf/cr or what ever con be hold inside <whatwewant> </whatwewant>
What problem does that solve which a simple format doesn't solve? -Jonathan
It could be a pseudo parser.
Mensaje telepatico asistido por maquinas.
Because keys, values, and key/value pairs in the Pd preferences are themselves simple:
Thanx for clarification!!!
Part of my innocence comes cuz I cant find or open the ~/.pdsettings file on my VM running Ubuntu.
I'm still blind.
IYO this file could be standardize to be displayed on the Windows Notepad, I mean the Unix LF vs the Win CR/LF EOL?
Mensaje telepatico asistido por maquinas.
On 19-02-17 21:50, Lucas Cordiviola wrote:
/>Because keys, values, and key/value pairs in the Pd preferences are themselves //simple:/Thanx for clarification!!!
Part of my innocence comes cuz I cant find or open the ~/.pdsettings file on my VM running Ubuntu.
I'm still blind.
With unix/Linux systems filenames startting with a "." are normally not displayed, but modern Linux file browsers have an option "show hidden files".
IYO this file could be standardize to be displayed on the Windows Notepad, I mean the Unix LF vs the Win CR/LF EOL?
AFAIK, Wordpad can handle LF-only line endings properly. Notepad is to be avoided for any serious work.
Mensaje telepatico asistido por maquinas.
Greetings & success,
Fred Jan
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I think this file should not be shared on different installations of Pd and should be relative only to the running executable.
With unix/Linux systems filenames startting with a "." are normally not
displayed, but modern Linux file browsers have an option "show hidden
files".
Thanx! : ) I was putting “.pdsettings” on the search bar and nothing came out, thinking this mystery Os where I never could hook a normal USB soundcard... : )
AFAIK, Wordpad can handle LF-only line endings properly. Notepad is to
be avoided for any serious work.
I didn't knew that Wordpad trick. On exchange for that, for serious work I recommend Notepad++, especially the “find in files” to name only one of many included tools.
Mensaje telepatico asistido por maquinas.
@ Jonathan,
Because keys, values, and key/value pairs in the Pd preferences are themselves simple:
keys: ascii string containing no spaces
values: number, numbers separated by whitespace, ascii string with no
whitespace, and file paths.
Pseudo XML may not be needed but what was the trouble with it anyway?
I think I can retrieve ANY string with [mrpeach/binfile].
Why not in C ?
Just a thought.
Mensaje telepatico asistido por maquinas.
@ Jonathan,
Because keys, values, and key/value pairs in the Pd preferences are themselves simple: keys: ascii string containing no spaces values: number, numbers separated by whitespace, ascii string with nowhitespace, and file paths.
Pseudo XML may not be needed but what was the trouble with it anyway?
What is pseudo XML? -Jonathan
I think I can retrieve ANY string with [mrpeach/binfile]. Why not in C ? Just a thought.
Mensaje telepatico asistido por maquinas.
#yiv6099620818 #yiv6099620818
<rate>44100</rate> <flags>-font-weight normal</flags>
<fontmetrics> 5 11 6 13 7 16 10 19 14 29 22 44 </fontmetrics>
Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Monday, February 20, 2017 12:09 AM To: Lucas Cordiviola; pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file.
@ Jonathan,
Because keys, values, and key/value pairs in the Pd preferences are themselves simple:
keys: ascii string containing no spaces
values: number, numbers separated by whitespace, ascii string with no
whitespace, and file paths.
Pseudo XML may not be needed but what was the trouble with it anyway?
What is pseudo XML?
-Jonathan
I think I can retrieve ANY string with [mrpeach/binfile].
Why not in C ?
Just a thought.
Mensaje telepatico asistido por maquinas.
Benefit: there would be a single preferences file format shared among all platforms. Cost:* currently the only platform that uses xml for preferences is OSX, and Pd relies on its proprietary, non-portable tool in order to read and save this file. So it would be necessary to write an XML parser for reading and writing in Pd, or bring in an XML library as a dependency.
- can't leverage any of Pd's current parsers or
use them as a guide. For example, the Pd message parser splits tokens on spaces-- the XML preferences file below doesn't fit that pattern-- the pd parser would interpret that first line as a single symbol atom.* the linux preferences file has long-standing code in Pd for reading/writing preference files. That would be thrown out to create a newer one that is more difficult to implement.
- without nested tags we lose most of
the power that XML would have provided. (For example, nested tags to make the values in "fontmetrics" self documenting.)
What are the practical problems with using the current format for the Pd preferences file under Linux?
-Jonathan
<rate>44100</rate>
<flags>-font-weight normal</flags><fontmetrics> 5 11 6 13 7 16 10 19 14 29 22 44</fontmetrics>
Mensaje telepatico asistido por maquinas.
What are the practical problems with using the current
format for the Pd preferences file under Linux?
I don't know, 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. And think that it should live on the pd/bin dir & not in a user dir. to disallow sharing prefs. on multiple installations. (Pd, Purr-Data, PsVST)
If is needed to hold different fonts-metrics there could be a separete file just for that, or it can be stored in the actual file format.
fm1: 5 11 fm2: 6 13 fm3: 7 16 fm4: 10 19 fm5: 14 29 fm6: 22 44
Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Monday, February 20, 2017 1:35 AM To: Lucas Cordiviola; pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file.
Benefit: there would be a single preferences file format shared among all platforms.
Cost:
- currently the only platform that uses xml for
preferences is OSX, and Pd relies on its proprietary, non-portable tool in order to read and save this file. So it would be necessary to write an XML parser for reading and writing in Pd, or bring in an XML library as a dependency.
- can't leverage any of Pd's current parsers or
use them as a guide. For example, the Pd message parser splits tokens on spaces-- the XML preferences file below doesn't fit that pattern-- the pd parser would interpret that first line as a single symbol atom.
- the linux preferences file has long-standing code
in Pd for reading/writing preference files. That would be thrown out to create a newer one that is more difficult to implement.
- without nested tags we lose most of
the power that XML would have provided. (For example, nested tags to make the values in "fontmetrics" self documenting.)
What are the practical problems with using the current format for the Pd preferences file under Linux?
-Jonathan
<rate>44100</rate>
<flags>-font-weight normal</flags>
<fontmetrics> 5 11 6 13 7 16 10 19 14 29 22 44 </fontmetrics>
Mensaje telepatico asistido por maquinas.
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.
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@iem.at An: pd-list@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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
: )
You can also use the Pd icon for your scripts, so you won't scare people :-D.
I was doing .cmd since 2 years. : P
https://lists.puredata.info/pipermail/pd-list/2017-02/117979.html
Mensaje telepatico asistido por maquinas.
Ok, Thanx for the detalis.
Anyway before concluding this thread I must said that this year I've been connecting the pref.file to 2 things:
Purr-Data : https://lists.puredata.info/pipermail/pd-list/2017-01/117407.html Deken : If necessary the pref.file can hold the deken path.for.externals.
And most importantly I connected the pref.file cuz Miller announced it this year for Win & Mac.
Do you think there's need to add a couple of things to the actual prefs?
Font metrics? Deken path?
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of IOhannes m zmoelnig zmoelnig@iem.at Sent: Monday, February 20, 2017 10:15 AM To: pd-list@lists.iem.at Subject: 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.
Ok, Thanx for the detalis.
Anyway before concluding this thread I must said that this year I've been connecting the pref.file to 2 things: Purr-Data : https://lists.puredata.info/pipermail/pd-list/2017-01/117407.html%3E Deken : If necessary the pref.file can hold the deken path.for.externals. And most importantly I connected the pref.file cuz Miller announced it this year for Win & Mac. Do you think there's need to add a couple of things to the actual prefs? Font metrics?
Why do you want to add font metrics to the preferences? That is information that the GUI toolkit should produce automatically.
-Jonathan
Deken path?
Salutti,Lucarda.
Mensaje telepatico asistido por maquinas.
From: Pd-list pd-list-bounces@lists.iem.at on behalf of IOhannes m zmoelnig zmoelnig@iem.at Sent: Monday, February 20, 2017 10:15 AM To: pd-list@lists.iem.at Subject: 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@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Why do you want to add font metrics to the preferences? That is information that the GUI toolkit should produce automatically.
Look here:
https://github.com/pure-data/pure-data/wiki/Crossplatform-font-metrics-&...
Here it is shown the diff between Vanilla & extended: http://lucarda.com.ar/x/Van-Ext-diff.jpg
There are chances that you may prefer one of these 2 settings, depending on your amount of patches done on Vanilla or Extended.
Of course this could be set outside of the preferences on a separate file.
Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Monday, February 20, 2017 2:55 PM To: Lucas Cordiviola; pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file.
Ok, Thanx for the detalis.
Anyway before concluding this thread I must said that this year I've been connecting the pref.file to 2 things:
Purr-Data : https://lists.puredata.info/pipermail/pd-list/2017-01/117407.html Deken : If necessary the pref.file can hold the deken path.for.externals.
And most importantly I connected the pref.file cuz Miller announced it this year for Win & Mac.
Do you think there's need to add a couple of things to the actual prefs?
Font metrics?
Why do you want to add font metrics to the preferences? That is information that the GUI toolkit should produce automatically.
-Jonathan
Deken path?
Salutti, Lucarda.
Mensaje telepatico asistido por maquinas.
Why do you want to add font metrics to the preferences? That is information that the GUI toolkit should produce automatically.
Look here:
https://github.com/pure-data/pure-data/wiki/Crossplatform-font-metrics-&...
Here it is shown the diff between Vanilla & extended:http://lucarda.com.ar/x/Van-Ext-diff.jpg There are chances that you may prefer one of these 2 settings, depending on your amount of patches done on Vanilla or Extended.
I get that. But you are taking an internal format passed between the GUI and the core and exposing it to become a public API. And that format virtually guarantees that users will misunderstand how it works: "I told Pd to make the 12pt font 7x15 pixels, but it is isn't 7x15. Is this a bug?" -Jonathan
Of course this could be set outside of the preferences on a separate file. Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Monday, February 20, 2017 2:55 PM To: Lucas Cordiviola; pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file. > Ok, Thanx for the detalis.
Anyway before concluding this thread I must said that this year I've been connecting the pref.file to 2 things: Purr-Data : https://lists.puredata.info/pipermail/pd-list/2017-01/117407.html%3E Deken : If necessary the pref.file can hold the deken path.for.externals. And most importantly I connected the pref.file cuz Miller announced it this year for Win & Mac. Do you think there's need to add a couple of things to the actual prefs? Font metrics?
Why do you want to add font metrics to the preferences? That is information that the GUI toolkit should produce automatically.
-Jonathan
Deken path?
Salutti,Lucarda.
Mensaje telepatico asistido por maquinas.
But you are taking an internal format passed between the GUI and the core and exposing it to become a public API. And that format virtually guarantees that users will misunderstand how it works:
Ok, so then a new flag?
-fontmetrics <name> … vanilla or extended
Or something like that?
Mensaje telepatico asistido por maquinas.
From: Jonathan Wilkes jancsika@yahoo.com Sent: Monday, February 20, 2017 4:08 PM To: Lucas Cordiviola; pd-list@lists.iem.at Subject: Re: [PD] (wip) Preferences file.
Why do you want to add font metrics to the preferences? That is information that the GUI toolkit should produce automatically.
Look here:
https://github.com/pure-data/pure-data/wiki/Crossplatform-font-metrics-&...
Here it is shown the diff between Vanilla & extended:
http://lucarda.com.ar/x/Van-Ext-diff.jpg
There are chances that you may prefer one of these 2 settings, depending on your amount of patches done on Vanilla or Extended.
I get that. But you are taking an internal format passed between the GUI and the core and exposing it to become a public API. And that format virtually guarantees that users will misunderstand how it works:
"I told Pd to make the 12pt font 7x15 pixels, but it is isn't 7x15. Is this a bug?"
-Jonathan
Of course this could be set outside of the preferences on a separate file.
Mensaje telepatico asistido por maquinas.
-
Alexandre Torres Porres -
Christof Ressi -
Fred Jan Kraan -
IOhannes m zmoelnig -
Jonathan Wilkes -
Lucas Cordiviola -
zmoelnig＠iem.at