[PD-dev] ideas for developing data structures further

Frank Barknecht fbar at footils.org
Sun Feb 27 23:55:21 CET 2005


Hallo,
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:

> In the process of making my "Solitude" composition 
> (http://at.or.at/hans/solitude ), I came up with a few ideas for 
> improvements on Pd's data structures.  Overall I found it to be a quite 
> nice composition environment and with some not so major changes, it 
> could be quite usable as is. 

Apart from composition it also could be made more useable as a general
GUI building tool. Something like a multislider for example could be
made possible, and also simple animatons work quite well, but could
work a bit better. (I used data structures already as a GEM
replacement with pmpd, which worked surprisingly well so far.) 

However for that, mouse handling would need to be improved. Sometimes
it's really hard to hit the area where mouse movement is possible, and
generally some kind of mouse callback would be very handy, which would
be my wish number one. 

> - a way to delete scalars 

votes++

> - a way to raise/lower scalars so you can get to scalars that are 
> blocked by others 
> 
> This is minor, but it would be handy to have a "send-to-back" function, 
> so that you could get to scalars that are completely obscured by 
> another.  This could be implemented using something like a Shift-click, 
> a menu item, and/or a key command. 

I also would like to see this, but it seems to be a more general
problem with Pd's patch layout. Everyone who wanted to add a canvas
*behind* some object once know that this doesn't work without first
cutting and pasting the existing objects. Some kind of "z-index"
variable would be very handy for GUI objects and data structures. 

A workaround us to stack subpatches in GOP mode intelligently, but
then you loose the possibility to work in Edit Mode, when the subpatch
is closed. 

> - full color support (8-bits for each R, G, B) 
> 
> If the data structures support standard 24-bit color, then color could 
> be a much more usable dimension.  The current scheme is a bit odd, and 
> is quite limited in terms of the range of colors it can represent.  The 
> hard part of this is then how to represent the color as a number.  You 
> can't do standard hex with Pd because it would then be interpreted as a 
> symbol if letter digits were present (a-f) and a float if no letter 
> digits where present.  Perhaps the most straightforward way to handle 
> it would be to make one float for each R, G, and B.   The graphic 
> design standard seems to be 0-255, but since Pd is float-based 0-1 
> might make sense.  And 0-1 would be easy enough to/from 0-255. 

This also should be made consistent with the other GUI objects. Color
handling in the IEM-GUI objects isn't optimal either, AFAIR. 

Ciao
-- 
 Frank Barknecht                               _ ______footils.org__
             
             _ __latest track: fqdn _ http://footils.org/cms/show/38




More information about the Pd-dev mailing list