Re: [PD] embedded preferences...
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. 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) 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. 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. I suppose the same code/idea could be used for GNU/Linux, but I think it would be cooler to have Pd generate .debs. .hc On Apr 9, 2009, at 12:30 PM, 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. 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 :) Miller On Thu, Apr 09, 2009 at 12:56:09PM +0200, IOhannes m zmoelnig wrote: hi all. i was wondering what the status of embedded preferences (that is: using a local preference file that is attached with a certain Pd-application rather than the global preferences valid for all Pd's on the system) for all platforms and the various tastes of Pd was. i know that you can embed a preference file in an osx-bundle in Pd-extended (at least since 0.40), and iirc this embedding has been accepted into Pd-vanilla as well (since version ?) i seem to remember that a similar mechanism exists on linux. i cannot remember anything about w32 (which might be more complicated, given that with w32 we are using the registry rather than a file that ships with Pd) so my question is: - is embedding preferences supported on all platforms? - is embedding preferences supported on both Pd-vanilla and Pd- extended? - what is the minimum version of Pd i need to acquire the usufruct (with regard to taste) fgamdsr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated -John Donne ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] embedded preferences...
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. 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
Re: [PD] embedded preferences...
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] embedded preferences...
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] embedded preferences...
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. 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 :) Miller On Thu, Apr 09, 2009 at 12:56:09PM +0200, IOhannes m zmoelnig wrote: hi all. i was wondering what the status of embedded preferences (that is: using a local preference file that is attached with a certain Pd-application rather than the global preferences valid for all Pd's on the system) for all platforms and the various tastes of Pd was. i know that you can embed a preference file in an osx-bundle in Pd-extended (at least since 0.40), and iirc this embedding has been accepted into Pd-vanilla as well (since version ?) i seem to remember that a similar mechanism exists on linux. i cannot remember anything about w32 (which might be more complicated, given that with w32 we are using the registry rather than a file that ships with Pd) so my question is: - is embedding preferences supported on all platforms? - is embedding preferences supported on both Pd-vanilla and Pd-extended? - what is the minimum version of Pd i need to acquire the usufruct (with regard to taste) fgamdsr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
