[PD] UI developer volunteering to help

Matt Barber brbrofsvl at gmail.com
Sat May 3 15:27:45 CEST 2008


Hello,

I would really be opposed to bendable patch cords, or especially the
segmented patch cord style in Max/MSP.  It seems to me these types of
connections reinforce bad habits, as users are not encouraged to
modularize, economize, etc. and they tend to lead to the most
unreadable (and uneditable!) "spider webs" in complex projects.  PD's
style forces one to be explicit, but causes some extra (and IMO,
worthwile) work to make an ergonomic interface for performers.  I
think the inclusion of send and receive symbols in the graphical
objects is one of the best ideas in PD, because it allows one to
easily keep the engine hidden and out of sight, and obviates much of
the need for hideable or segmented cables.

Also, I have had students who came from Max/MSP who created the kind
of huge, sprawling, everything-in-one-window kind of patch they got
used to doing in Max.  We found that by hiding more and more things in
subpatches and abstractions, we could cut down on CPU quite a bit.  I
assume this means tcl/tk redraws entire windows often, but I don't
know the details.  At any rate, I don't think introducing the
segmented patch cables would necessarily result in an explosion of
unreadable patches, but I think the "clunkiness" of PDs interface
encourages thoughtfulness and efficiency, which are invaluable in
pedagogical situations.

What I would welcome would be a richer set of GUI tools in vanilla, as
sometimes knobs are more preferable to sliders, or you may want a
2d-slider for tying two dimensions to each other, but these are less
important than the [pow~], [abs~], etc. objects mentioned in an
earlier thread.

Thanks,

Matt


>  hey david!
>
>  if you want to collect some ideas how a real usable and pretty
>  interface for a modular environment could look like, have a look at
>  http://synthmaker.co.uk/about.html
>  it's got bendable links... you never have to leave edit mode... and
>  have a look at how ALL interface elements as bitmap & vector knobs,
>  sliders or wavedraw display consist of modules themselve.
>  the environment is off course not as powerful as pd, but the interface
>  is just a joy to work with.
>
>  greetings,
>  fabb
>
>
>  On Sat, May 3, 2008 at 6:04 AM, David Golightly <davigoli at gmail.com> wrote:
>  > Hey PD gurus,
>  >
>  > I used to use PD a lot but haven't much for the last year or more.  Now I'm
>  > getting back in to it and finding that the UI is just really clunky and
>  > awkward and makes the workflow really painful.  I build website UIs
>  > professionally in JavaScript (see
>  > http://www.zillow.com/search/RealEstateSearch.htm for an example of a UI I
>  > built, everything except the Flash).  I also have on-the-job experience in
>  > design and usability, as well as coding skills in Python and some exposure
>  > to C, C++ and Java.  I'd like to start pitching in specifically on GUI and
>  > chrome improvements in the trunk for the core PD UI.  How would I go about
>  > getting started?  I noticed the page at http://puredata.info/dev/GuiIdeas
>  > has some outstanding requests from the community, it seems like the best
>  > thing is to start there.  I'd also like to integrate with the developer
>  > community to ensure that UI improvements (specifically, better keyboard
>  > support and smoothing out some glaring dialog/chrome issues) don't have a
>  > negative impact on realtime audio performance.
>  >
>  > Best,
>  >
>  > David
>  >




More information about the Pd-list mailing list