(I've had this sitting my Drafts box for a while, its time to send it out...)
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.
- a way to delete scalars
The biggest improvement would be the addition of a method to delete scalars. This would allow a number of things currently not possible. A simple example would be to have a cursor and minute markers that only exists when the score is being played. A really great example would be the ability to show and hide parts of the graphical representation. For example, each voice could be saved to an individual file, then with a toggle, it would be displayed or hidden.
- 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.
- 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.
.hc
________________________________________________________________________ ____
"Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies."
- Amy Smith
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
canvas *behind* some object once know that this doesn't work without first cutting and pasting the existing objects. Some kind of "z-index"
add sys_vgui(".x%lx.c lower %lxRECT\n", canvas, x); in my_canvas_draw_new()
On Sun, Feb 27, 2005 at 11:55:21PM +0100, Frank Barknecht wrote:
Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
agree with all your gripes, but color handling, stacking order, mouse flexibility etc are very mature and full-featured in Tk..nothing less than full access to this is acceptable!
anyone know a quick hack to speed up the gui bandwidth? it seems to top out at about 40K/second on windows which really rains on using BLT or Snack for audio editing...seeing all sorts of tantalizing bits about polling intervals in t_tkcmd.c but really have no clue which one to start hacking away at..