[PD] scripts instead of preferences WAS: reorg of puredata.info/docs/developer

Hans-Christoph Steiner hans at at.or.at
Wed Jul 6 19:43:33 CEST 2011


On Wed, 06 Jul 2011 18:52 +0200, "András Murányi" <muranyia at gmail.com>
wrote:
> 2011/7/6 Hans-Christoph Steiner <hans at at.or.at>
> 
> > On Wed, 06 Jul 2011 15:32 +0200, "András Murányi" <muranyia at gmail.com>
> > wrote:
> > > 2011/7/3 Hans-Christoph Steiner <hans at at.or.at>
> > >
> > > >
> > > > On Jul 3, 2011, at 10:04 AM, András Murányi wrote:
> > > >
> > > > On Sat, Jul 2, 2011 at 20:41, Hans-Christoph Steiner <hans at at.or.at
> > >wrote:
> > > >
> > > >>
> > > >> I just finished a big, long-overdue reorg of the
> > > >> http://puredata.info/docs/**developer<
> > http://puredata.info/docs/developer>section of the website.
> > > >>
> > > >>  * Its now a "wiki folder" so it acts like a regular wiki, not like a
> > > >> weird plone mix of things.  It also allows email subscripts to wiki
> > pages.
> > > >>
> > > >>  * I purged old pages and redirected them to the new versions
> > > >>
> > > >>  * I cleaned up the formatting on the front page
> > > >>
> > > >>  * I updated references to CVS, etc.
> > > >>
> > > >>  * I purged a couple very out-of-date things
> > > >>
> > > >> Let me know what you think, and please contribute where you can! :-D
> > > >>
> > > >> .hc
> > > >>
> > > >>
> > > > IMHO the whole GUI Plugins stuff could go under Developer.
> > > >
> > > >
> > > > One goal for me is to make it easy enough for all Pd users to write
> > their
> > > > own GUI plugins.  Honestly, I think we can make GUI plugins replace the
> > idea
> > > > of preferences.  A simple set of preferences is very easy to
> > understand.
> > > >  But many people find a simple set limiting, so you see many programs
> > > > implementing huge preferences systems that mystify most users (think
> > > > Photoshop, MS Office, OpenOffice, etc.)  I think with a well designed
> > > > scripting/plugin system, it would work better than preferences.
> > > >
> > > > .hc
> > > >
> > >
> > > Understood. However, I think plugins can never replace preferences as
> > > they
> > > are two different things. Plugins need to save their data somewhere too,
> > > and
> > > that somewhere is the preferences. If the file format of preferences was
> > > something programmatic (ie. not "loadlib9: moonlib" but "variable
> > > loadlib9
> > > 'moonlib'" or something like that) there would be more change for a
> > > convergence, but at the same time the format would be less easy to
> > > parse/write/etc. So at the end, preferences are data, and plugins are
> > > programs, and that's how it's good.
> > > But, I understand and agree that you want to bring plugins closer to the
> > > users and that that's why plugin docs won't go under developer docs.
> > >
> > > Andras
> >
> > In the context of a programming environment, I don't see a lot of reason
> > to have a separate preferences system.  Things like configuring the
> > audio and MIDI interface are usually best handled in the patch, and that
> > should be as easy as possible.  IOhannes has made big progress there
> > with the 'mediasettings' library.  Things like loading libraries should
> > definitely be done in the patch and not globally.  Just look at python,
> > ruby, java, C++, C, etc. etc. etc for examples there.
> >
> > What I'd like to see is a standard Pd patch that is loaded in the place
> > of preferences.  Then you could configure your Pd setup using a Pd
> > patch.  Any Pd user is going to know how to make a patch, so if you can
> > configure Pd with a Pd patch, then you don't need to learn any new
> > preferences file format or system.
> >
> > hc
> >
> 
> OK, sounds good. But let's just remember the use case when we want pd to
> remember which plugins to load and which not. As plugins load before any
> patch, and they couldn't really be enabled/disabled per patch, their
> preferences will have to be stored somewhere else. We agreed before that
> the
> "/disabled" folders method is no good, and that we (probably me) will
> code
> up a logic which stores this in preferences (via ::pd_guiprefs). I'm
> interested in further brainstorming but right now I feel that good old
> preferences is something we'll have to live with for a longer time. We'll
> have to make a distinction between global stuff (plugins, global prefs)
> and
> those things which are better handled per patch, from inside patches.

Yes, I agree.  For things that affect the editor and not the patch
itself, then preferences makes more sense.

.hc



More information about the Pd-list mailing list