Pd-dev July 2010

pd-dev@lists.iem.at

20 participants
139 discussions

vinylcontrol~
by Caucasian Caucasian 03 Oct '10

03 Oct '10

Hallo, I'd like to test [vinylcontrol~] from http://karhumusic.sesser.at/vinylcontrol/vinylcontrol.html on Windows XP, but unfortunately I'm not able to compile external by myself (missing knowledge base ;-) ). Is there anybody who could help to make it work please?. Thanks a lot ales ---------------- code.google.com/p/visualtracker

2 1

Re: [PD-dev] [PATCH 06/10] fixed race-condition in the audio/midi API initialization
by Hans-Christoph Steiner 01 Sep '10

01 Sep '10

That's the idea of the wait4pd stuff, to make sure that pd is started before continuing on. I don't think this is necessary. Do you have a way to trigger pd taking too long to start up? .hc On Jul 15, 2010, at 2:57 AM, IOhannes m zmoelnig wrote: > if Pd takes too long to startup, Pd-gui will initialize the audio/ > midi API-menus > with NULL-lists; > if Pd finally shows up, the menu cannot be modified anymore, and > thus the user > cannot select the API they want. > > the fix moves the audio/midi APIs into a sub-menu of "Media", and > provides a > function ::pd_menus::build_media_api_menus that will clear the old > API-menus and > refill them with the new API-lists. > this allows Pd-core, to update the API-lists after the GUI has been > initialized. > --- > tcl/pd-gui.tcl | 1 + > tcl/pd_menus.tcl | 50 ++++++++++++++++++++++++++++++++ > +----------------- > 2 files changed, 34 insertions(+), 17 deletions(-) > > diff --git a/tcl/pd-gui.tcl b/tcl/pd-gui.tcl > index c99decc..b4f20b3 100755 > --- a/tcl/pd-gui.tcl > +++ b/tcl/pd-gui.tcl > @@ -460,6 +460,7 @@ proc pdtk_pd_startup {major minor bugfix test > if {$::tcl_version >= 8.5} {find_default_font} > set_base_font $sys_font $sys_fontweight > fit_font_into_metrics > + ::pd_menus::build_media_api_menus $::pdwindow_menubar.media > set ::wait4pd "started" > } > > diff --git a/tcl/pd_menus.tcl b/tcl/pd_menus.tcl > index fc617df..7157c5e 100644 > --- a/tcl/pd_menus.tcl > +++ b/tcl/pd_menus.tcl > @@ -224,6 +224,32 @@ proc ::pd_menus::build_find_menu {mymenu} { > -command {pdsend {pd finderror}} > } > > + > +## update the audio/midi API lists > +# this is done by first clearing the menus, and then rebuilding > them from scratch > +proc ::pd_menus::build_media_api_menus {mymenu} { > + if { [winfo exists $mymenu.audio] } { > + $mymenu.audio delete 0 [ $mymenu.audio index last] > + set audio_apilist_length [llength $::audio_apilist] > + for {set x 0} {$x<$audio_apilist_length} {incr x} { > + $mymenu.audio add radiobutton -label [lindex [lindex > $::audio_apilist $x] 0] \ > + -command {menu_audio 0} -variable ::pd_whichapi \ > + -value [lindex [lindex $::audio_apilist $x] 1]\ > + -command {pdsend "pd audio-setapi $::pd_whichapi"} > + } > + } > + if { [winfo exists $mymenu.midi] } { > + $mymenu.midi delet 0 [ $mymenu.midi index last] > + set midi_apilist_length [llength $::midi_apilist] > + for {set x 0} {$x<$midi_apilist_length} {incr x} { > + $mymenu.midi add radiobutton -label [lindex [lindex > $::midi_apilist $x] 0] \ > + -command {menu_midi 0} -variable ::pd_whichmidiapi \ > + -value [lindex [lindex $::midi_apilist $x] 1]\ > + -command {pdsend "pd midi-setapi $::pd_whichmidiapi"} > + } > + } > +} > + > proc ::pd_menus::build_media_menu {mymenu} { > variable accelerator > $mymenu add radiobutton -label [_ "DSP On"] -accelerator > "$accelerator+/" \ > @@ -237,23 +263,13 @@ proc ::pd_menus::build_media_menu {mymenu} { > $mymenu add command -label [_ "Load Meter"] \ > -command {menu_doc_open doc/7.stuff/tools load-meter.pd} > > - set audio_apilist_length [llength $::audio_apilist] > - if {$audio_apilist_length > 0} {$mymenu add separator} > - for {set x 0} {$x<$audio_apilist_length} {incr x} { > - $mymenu add radiobutton -label [lindex [lindex > $::audio_apilist $x] 0] \ > - -command {menu_audio 0} -variable ::pd_whichapi \ > - -value [lindex [lindex $::audio_apilist $x] 1]\ > - -command {pdsend "pd audio-setapi $::pd_whichapi"} > - } > - > - set midi_apilist_length [llength $::midi_apilist] > - if {$midi_apilist_length > 0} {$mymenu add separator} > - for {set x 0} {$x<$midi_apilist_length} {incr x} { > - $mymenu add radiobutton -label [lindex [lindex > $::midi_apilist $x] 0] \ > - -command {menu_midi 0} -variable ::pd_whichmidiapi \ > - -value [lindex [lindex $::midi_apilist $x] 1]\ > - -command {pdsend "pd midi-setapi $::pd_whichmidiapi"} > - } > + menu $mymenu.audio > + menu $mymenu.midi > + $mymenu add cascade -label [_ "Audio"] -menu $mymenu.audio > + $mymenu add cascade -label [_ "Midi"] -menu $mymenu.midi > + > + build_media_api_menus $mymenu > + > if {$::windowingsystem ne "aqua"} { > $mymenu add separator > create_preferences_menu $mymenu.preferences > -- > 1.7.1 > ---------------------------------------------------------------------------- Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom

4 12

new loader replacement progress report
by Claude Heiland-Allen 25 Aug '10

25 Aug '10

Hi everyone, I've been working on some algorithms to eventually replace the way Pd finds and loads and creates objects. Sorry for the length of this mail, but you can skip some sections if you don't care about implementation details and/or user interface details :) Table of Contents * Specifications * Example Loaders * Clearer Error Messages * Test Inputs * Test Outputs Specifications -------------- As agreed by everyone so far, the new load order will be roughly: for path in paths do -- the core does this bit for loader in loaders do loader(path, libray, object) instead of the old, problematic: for loader in loaders do for path in paths do -- the loader does this bit loader(path, library, object) I restructured the loader plugin mechanism to be (pseudocode): typedef err libloadfun(symbol *dir, symbol *lib); typedef err objloadfun(symbol *dir, symbol *lib, symbol *obj); struct loader { symbol *name; float priority; libloadfun *libfun; objloadfun *objfun; } Example Loaders --------------- -- binary loader is super simple Loader.new("bin", 70, function(dir, lib) return loadbin(dir, lib) end, function(dir, lib, obj) return loadbin(dir, obj) end) -- directory loader is needed if there is no main library file -- the core code checks the results to see if it succeeded Loader.new("dir", 10, function(dir, lib) if dir:sub(-1 - #lib, -1) == ("/" .. lib) then return function() end else return nil, "dir doesn't match lib" end end, nil -- directory loader can't load objects ) -- the abstraction loader is quite complicated -- if the file exists it creates a callback that -- registers the class, with a constructor that -- runs the abstraction itself -- a Context here is essentially a 'canvas' Loader.new("txt", 30, nil, -- abstractions cannot register new classes function(dir, lib, obj) local src = dir .. "/" .. obj .. ".txt.lua" local f, err = fileexists(src) if f then local ldir, lobj = dir, obj return function() register(lobj, src, function(o, arguments) Context.push(Context.new({ ldir })) runtxt(ldir, lobj) Context.pop() end, src) end else return nil, err end end) The current implementation is entirely in Lua, in an unpublished git repository. I'll upload it somewhere if there is any interest. Clearer Error Messages ---------------------- The main upshot so far is clearer error messages instead of random possibly-working-but-perhaps-not implementation defined behaviour when more than one library defines the same name: OBJECT [obj4] obj4 ... couldn't create (ambiguous) (found in: 'lib4') (found in: 'lib3') (found in: 'lib1') (found in: 'lib5') (found in: 'lib2') disambiguate by [import lib2/obj4] replacing lib2 by the library you want to import from OBJECT [obj2] obj2 ... couldn't create (ambiguous qualified import) (imported: 'lib2/obj2') (imported: 'lib1/obj2') disambiguate by removing extra qualified imports The error messages for objects that are not found are better too: OBJECT [obj8] obj8 ... couldn't create (no such object) (looked in: 'lib4') (looked in: 'vanilla') (looked in: 'lib3') (looked in: 'lib1') (looked in: 'lib5') (looked in: 'lib2') OBJECT [lib1/obj8] lib1/obj8 ... couldn't create (no such object in library) OBJECT [lib6/obj1] lib6/obj1 ... couldn't create (no such library) Note for that last [libc6/obj1] example: if libc6 actually did exist in the path but was not imported, the error would currently be the same. I want to make it so that [somelibrary/someobject] would work even when [somelibrary] is not imported (but such "implicit imports" would be deprecated, and warnings emitted). Test Inputs ----------- The test input directory structure (.bin.lua approximates .pd_linux etc, .txt.lua approximates .pd patches/abstractions): ----8<---- .: global prj1 ./global: lib1 lib2 lib3 lib3.bin.lua lib4 lib5.bin.lua vanilla ./global/lib1: obj1.txt.lua obj3.txt.lua obj4.txt.lua obj5.txt.lua obj7.txt.lua obj2.txt.lua obj4.bin.lua obj5.bin.lua obj6.bin.lua ./global/lib2: lib2.bin.lua obj2.txt.lua obj4.bin.lua obj5.bin.lua obj6.bin.lua obj1.txt.lua obj3.txt.lua obj4.txt.lua obj5.txt.lua obj7.txt.lua ./global/lib3: obj1.txt.lua obj3.txt.lua obj4.txt.lua obj5.txt.lua obj7.txt.lua obj2.txt.lua obj4.bin.lua obj5.bin.lua obj6.bin.lua ./global/lib4: obj1.txt.lua obj3.txt.lua obj4.txt.lua obj5.txt.lua obj7.txt.lua obj2.txt.lua obj4.bin.lua obj5.bin.lua obj6.bin.lua ./global/vanilla: debug.bin.lua ./prj1: prj1.txt.lua ----8<---- The test input file (prj1.txt.lua) imports stuff and creates objects: ----8<---- import({ "lib1", "lib1/obj1", "lib1/obj2", "lib2", "lib2/obj2", "lib2/obj3", "lib3", "lib4", "lib5" }) for o = 1,8 do object("obj" .. o) end for l = 1,6 do for o = 1,8 do object("lib" .. l .. "/" .. "obj" .. o) end end ----8<---- Test Outputs ------------ The full raw output: http://claudiusmaximus.goto10.org/t/pd/pd-new-loader-test-4-verbose.txt The output with the STAT lines filtered out: http://claudiusmaximus.goto10.org/t/pd/pd-new-loader-test-4-quiet.txt The output with the STAT lines sorted and duplicates counted: http://claudiusmaximus.goto10.org/t/pd/pd-new-loader-test-4-statistics.txt (The counts are low because the results are cached, this will need to be changed for live-coding abstractions etc...) Hopefully I'm heading in the right direction with this, if not then yell loudly! Thanks, Claude -- http://claudiusmaximus.goto10.org

2 1

buildbot or some other proper build automation
by Hans-Christoph Steiner 20 Aug '10

20 Aug '10

On Jun 30, 2010, at 2:53 PM, András Murányi wrote: > 2010/6/27 Hans-Christoph Steiner <hans(a)at.or.at> > > On Jun 25, 2010, at 11:59 AM, András Murányi wrote: > >> 2010/6/10 András Murányi <muranyia(a)gmail.com> >> 2010/6/10 Hans-Christoph Steiner <hans(a)at.or.at> >> >> and its not 2010-06-10 in NYC yet :) >> >> .hc >> >> But in Moscow it is, so the script could make space for the >> following day's harvest too. >> >> Hello HC, >> >> still frequent failures because of the non existing directory. I'm >> serious - if you want to give a chance to uploaders from 'earlier' >> time zones than NYC you got to have the directory created >> earlier.... (just imagine Japan guys, they'd have a crazy short >> time frame to upload with the current setup) >> BTW can we file bugs against the autobuild system on SF? I suppose >> not... >> >> Andras > > IMHO, the auto-build scripts are a big kludge, so I don't want to > spend more time on them. And did the bulk of writing them. :) We > should use something like buildbot, but no one has set it up yet. > If you are interested, that would be a great project to take on. > > .hc > > > Sounds cool. I'd be interested in picking up this project if you can > help me with the things i'm not so good at: the first is platforms. > Buildbot seems something web-centered, and needs Twisted on the > clients too. Twisted is installed by default with Ubuntu and MacOSX > 10.5+, available for Windows and the rest goes from source. This > means, at a first glance, that Mac 10.4, Fedora and every other > Linux than Ubuntu, will need Twisted to be built or prebuilt, and > i'm not sure about 64-bit platforms and PPC. Python will be needed > to, i suppose it's more widely available. > What do you think? > > Andras We should move this discussion to pd-dev so its archived and others can contribute/learn/follow. I hope you don't mind, I cc'ed pd-dev. I think we can get twisted installed on 10.4 using Fink. Its included in Debian too. We'll need to install it manually on Windows, or however appropriate. That said, I am not married to buildbot, if you want to take on this project, feel free to research other options. There are some that are Java-based for example. I just remember builtbot sounding like the best back when I looked into it. .hc ---------------------------------------------------------------------------- "Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman

2 7

[ pure-data-Patches-2929666 ] test for jack-availability
by SourceForge.net 30 Jul '10

30 Jul '10

Patches item #2929666, was opened at 2010-01-11 03:56 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2929666&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix Status: Closed Resolution: Accepted Priority: 7 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: test for jack-availability Initial Comment: when jack is linked using "weak linking" (the default on OSX), it is possible to run Pd even though jack is not installed (that's the point of weak linking) however, in this case, the application has to check itself whether the weak-linked library is available or not. the attached patch this this (by checking whether the function pointer to "jack_client_new" is NULL or not) ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-29 22:52 Message: git commit cce7460726d8c89c8de80b62215318d616c7e950 ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2010-07-25 20:50 Message: took this out of turn because trying to work on jack callbacks :) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-01-26 18:06 Message: added this code to pd-extended 0.42: http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=131… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2929666&group_…

1 0

[ pure-data-Patches-1412469 ] allow env vars in path and loadlib on Win32
by SourceForge.net 30 Jul '10

30 Jul '10

Patches item #1412469, was opened at 2006-01-22 22:05 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1412469&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Closed Resolution: Accepted Priority: 6 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: allow env vars in path and loadlib on Win32 Initial Comment: This very minor change allows "path" and "loadlib" preferences to use Windows environment variables in the registry. A more complete solution is proposed in the feature tracker "minor changes to support env vars on Windows": http://sourceforge.net/tracker/index.php?func=detail&aid=1412443&group_id=5… ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-29 22:50 Message: git commit c564e72c7354088ee8ffe3e4625cfafeda45ae91 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-10-22 21:48 Message: Logged In: YES user_id=27104 Originator: YES is it time to revisit this? It's a super simple change, and makes things a lot more flexible for Windows users. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2006-08-14 01:27 Message: Logged In: YES user_id=313747 I need to check this again later -msp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1412469&group_…

1 0

[ pure-data-Patches-1242495 ] changing properties doesn't set "modified" status
by SourceForge.net 30 Jul '10

30 Jul '10

Patches item #1242495, was opened at 2005-07-21 14:07 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1242495&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: changing properties doesn't set "modified" status Initial Comment: When you change the properties of an object, it does not set the "dirty" or "modified" flag on the patch. Therefore, Pd does not prompt to save if that patch is closed and those changes are lost. To see this bug in action, make a new patch, and place a GUI bang object on the canvas (i.e. [bng]), then save the file. Now, open the properties dialog of that bang and change the color of it and it OK. When you close the patch, it does not prompt you to save your changes. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-29 22:50 Message: git commit 9f945f0121c99d2fac419475c764c4163f8c8f67 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-28 11:34 Message: Logged In: YES user_id=27104 Originator: YES Attached is a patch that fixes this for all canvas-related properties panels (i.e. NOT the audio/midi/path/startup pref panels). This should work for adding and deleting cords, and properties panels for: canvas, arrays, iemguis, and atom boxes. The only downside is that with the properties panels, there is no checking whether there has actually be any change. I just sets the dirty flag if the user clicks on OK or Apply. File Added: cords_and_properties_set_dirty-0.41.4.patch ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2007-05-27 11:08 Message: Logged In: YES user_id=1709568 Originator: NO Not only changing properties of an object. Also deleting an existing connection does not set the modified flag! To see the bug in action: Make a new patch, create any two objects and connect them in any way (any inlet of one to any outlet of the other), then save the file. Now, click on the wire connection and delete it, without moving the objects. When you close the patch, it does not prompt you to save your changes. This is true both for control and signal connections. At least Windows XP, version 0.40-2 Should I post this as a separate bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1242495&group_…

1 0

[ pure-data-Patches-1990599 ] allow recursive calls of new_anything()
by SourceForge.net 30 Jul '10

30 Jul '10

Patches item #1990599, was opened at 2008-06-11 04:36 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990599&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: feature Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: allow recursive calls of new_anything() Initial Comment: currently there is a protection mechanism against recursively calling "new_anything()". unfortunately this mechanism is the main obstacle that prevents abstractions to be loaded via a "loader" mechanism (and instead requires special case handling) the attached patch will allow some recursive calling of new_anything() (but still has a protection against stack overflow, at a depth of MAXOBJDEPTH=1000) ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-29 22:47 Message: git commit 5a58ca2b41d9cf46a91c8897754b196582c7ca89 ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2010-07-29 00:00 Message: I don't remember what the problem was that required stopping recursion -- perhaps it's gone now anyway. But the check that's in the patch will keep things OK anyhow I think. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-03-15 20:50 Message: FYI: this was included in the Pd-extended branch in 0.40: http://lists.puredata.info/pipermail/pd-cvs/2008-06/014617.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1990599&group_…

1 0

[ pure-data-Patches-1948146 ] array: move instead of redraw graphics
by SourceForge.net 30 Jul '10

30 Jul '10

Patches item #1948146, was opened at 2008-04-21 14:15 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1948146&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jakob Leben (jleben) Assigned to: Nobody/Anonymous (nobody) Summary: array: move instead of redraw graphics Initial Comment: This is a patch that fixes slow ("sticky") displacing of arrays by moving instead of recreating their graphics. It also fixes the problem of array name not appearing immediately after its creation as it was necessary now that arrays don't recreate but only move all that belongs to their appearance when displaced. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2010-07-29 22:42 Message: array moves should really use the tcl 'move' command. It will greatly speed things up, IMHO. Right now, changes in arrays can generate up to 1 megabyte of Tcl code per second for the GUI to execute. Using a move command, we should be able to get that down to a much smaller amount, I think three or four orders of magnitude is feasible. That said, I have not tested this patch. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2010-07-28 20:41 Message: Interesting idea - I wonder though if it would be simpler and more maintainable to use some sort of throttling instead. Array moves are definitely ugly now. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-04-24 15:56 Message: Logged In: YES user_id=27104 Originator: NO see patches 1943614 and 1943301 for a history of this patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1948146&group_…

1 0

[ pure-data-Patches-1962700 ] two embedded prefs for Mac: default and override all
by SourceForge.net 30 Jul '10

30 Jul '10

Patches item #1962700, was opened at 2008-05-12 19:18 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1962700&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: two embedded prefs for Mac: default and override all Initial Comment: This patch creates two different kinds of embedded org.puredata.pd.plist prefs files on Mac OS X. The first is the default settings that come with Pd-extended.app, the second is a prefs file that overrides all others, so that people can make their own custom apps based on the Pd.app, and be sure that the user's prefs aren't going to override things. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2010-07-28 20:38 Message: I think we should fix the preferences system so that pd extended doesn't rely on any preferences at all -- anything short of that will make for maintenance headaches later on. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-13 13:06 Message: Logged In: YES user_id=27104 Originator: YES That could work. I don't think this will cover every possibility. I think a more straightforward approach would be to handle very special hardware setups in the patch rather than the preferences. I think the preferences should be general things, since you can't really query or test for failures with the preferences system. For the built-in audio, it almost always just works, so specific configuration isn't needed. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-05-13 03:37 Message: Logged In: YES user_id=564396 Originator: NO hmm, but how should the author of a custom app know about the hardware-settings of the end-user? wouldn't it be better to split the configuration files into machine-dependencies (soundcard,...) and user-dependencies (libs,...) which could then be overridden seperately? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1962700&group_…

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev July 2010