On May 25, 2009, at 9:17 PM, danomatika wrote:

On Mon, 2009-05-25 at 21:09 -0400, Hans-Christoph Steiner wrote:

...

Another thing to try is writing the GUI in a toolkit that is
optimized for speed. I don't know if you have a GPU, but if you
wrote Pd GUI objects using something like togl or tkzinc, both use
OpenGL, that could also help.

That's a little more then I mean ...

When I first started using Pd I naively thought that num boxes and
sliders somehow were "skipped over" or turned into [clip] objects
when in -nogui mode.

I also thought that, its not true?

I don't really need an accelerated gui as I like what Pd has now, I
just think these basic elements should not peg the cpu in -nogui
mode. That way I can work in a nice graphical environment to create
the patches, then run said patches in the minimal environment and
not get penalized for using gui objects/parameters.

I started work on the 'tkwidgets' library a while back to provide
simple Pd interfaces to the Tk widgets. The IEMGUI code is quite
complicated. I have an almost complete API for Pd<->Tk that includes
code for a standard way of resizing the GUI objects with a mouse. I
think this could serve well as the basis for a GUI library that does
behave like a [clip] in -nogui mode.

For example, instead of a number box, we could make a Tk "label"
object in Pd which accepts anything you throw at it and displays it,
i.e. it would even display spaces and different fonts even! Shocking,
I know. I think there could be a working Pd object based on label in
a day or two of work, refinements would take longer, of course...

.hc

You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie