[PD-dev] Re: pure devil (fwd)

Mathieu Bouchard matju at artengine.ca
Mon Aug 15 10:23:14 CEST 2005


On Tue, 9 Aug 2005, B. Bogart wrote:

> the usual widgets? (for example drawing something like Yves grid without
> using buttons or anything? I think there is something to be said for the
> vector style of PD that I don't see often used in "normal" GUI design.)

Since a long time it struck me as strange that in so many (almost all) GUI
toolkits there are essentially two different systems that don't mix that
well: what's inside the canvas vs what's outside of the canvas... I mean
when there's even a canvas class worth something (e.g. in Tk).

But there *are* GUI toolkits in which everything is built on top of vector 
graphics: Fresco (aka Berlin), Genera (the old LISP OS), Squeak (a brand 
of Smalltalk)... well, that's off the top of my mind anyway.

Maybe it's just the long heritage of MacOS 1 which wasn't as much designed
to be flexible as to be able to run within 1/8th of a meg of RAM including
the apps. Then the inertia caught on somewhere, and then all the 
cross-platform craze froze GUI design solid because cross-platform means 
you have to build your design around the weakest of your target platform, 
or even worse ("least common denominator").

> I'm not sold on the Zoomer idea. If anyone has used eyeweb what they
> have done is removed all nesting (abstractions and subpatches) and
> replaced with with the ability to zoom into a big mess.

Technically, PureData could do very well without subpatches, but without 
abstractions it would just not be PureData. However I don't even recommend 
removing the subpatch concept, and I don't think that the zooming stuff 
implies any of that, nor that its main use would even be to make larger 
patches without having to use scrollbars.

> I've never had a case where I needed to see better what is happening
> up-close.

1. When the pointer device you are using is imprecise, you can't even hit
   an inlet 90% of the time. For example, ever tried patching on a
   touchscreen?

2. When the display is small or far away and the resolution makes pixels
   appear too small, I often can't even read what's on the screen. Not all
   versions of Linux make it quick to switch resolutions, and sometimes
   it's even just better to not mess with resolutions (e.g. most non-CRT
   displays, like on laptops and projectors)

3. When an object has been designed too small. Sometimes you just don't
   want to use Properties to reconfigure it as bigger, e.g. because it's
   inside a GOP abstraction that you don't want to mess with. Instead of
   resizing it you can now just zoom it instead.

> Maybe when I was connecting many patch cords to many inlets, but that
> was the fastest way to do it once.

Even for one patch cord to one inlet it's faster because the target you
are dragging to is bigger. And the target you are dragging from, the
outlet, is bigger as well. Bigger targets are faster to click on because
they're easier to reach.

> other than the ability to have the choice to make one giant web of mess
> and be able to zoom into different regions of it.

Some people already make huge patches using scrollbars because of some
assumed notion that the existence of scrollbars justifies their use - any
use of them... and even that because scrollbars exist, then more space
must be put between objects so that patches take more space so that one
more feature of PureData gets used. It's like consumer society: we have a
duty to eat bread in order to justify the baking of the bread. It's for
the Economy. Except that, to make matters worse, the scrollbar feature of
PureData doesn't have a market value. Whip me.

So I think we should abolish scrollbars. Or should we? (I'm kidding, but
just because I am doesn't mean I'm not making a point.)

> not to mention making the performance process seperate from the patching
> process (and I'm sure we almost all swap back in forth in many
> performances).

In performances I already have my left hand resting on Ctrl+E most of the
time, just in case I need it, and that's because I need it often.

IIRC, Carmen advocates the abolition of the Run/Edit mode. I say that if 
this becomes a reality, then other things have to change. There prolly 
aren't enough keyboard shortcuts and key modifiers that we can rely on 
being available all of the time (laptop keyboards are small)... and then, 
dragging a numberbox without holding modifiers should do what exactly? The 
same as current Run-Mode, or the same as current Edit-Mode ?

I suggested other things, like adding a different, more accessible 
shortcut for Edit/Run toggling -- e.g. Escape or even CapsLock. The Ctrl+E 
powerchord is more complex for the hand and doing too quick often leads to 
Ctrl+W instead (been there done that).

> diversity of interpolation algos, from lop~ to line, line~, line2,
> line3, pmpd and even a circular line.

"A circle is a round straight line with a hole in the middle."
 -- unknown author (presumably after too much topology)

____________________________________________________________________
Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
Freelance Digital Arts Engineer, Montréal QC Canada




More information about the Pd-dev mailing list