Here's my couple thoughts on this popular subject:
I think that before we try to put lots of effort into making PD look nicer we should be trying to improve functionality. There are still a couple issues that keep PD from reaching its full potential, and IMO these are way more important than bitmap sliders or fancy fonts. I originally asked about the font changing just as a point of interest so that I could do something fast and simple to improve pd for my use, obviously there are other people thinking about PD's looks too.
The way I see it there are a few things that keep PD back (in no particular order):
- GUI interfering with audio -- I know this is one of the reasons
that this discussion started, but I think we've lost track of that a little.
- Audio dropouts when loading sound files -- In my opinion this is
one of the largest issues in terms of using PD as a performance instrument, which I think it is otherwise ideally suited for.
- Audio latency (i've only tested this on os x) -- can't get anything
under 13ms with any hardware.
So, I know I'm repeating myself a little here.. but I think that these are the top priorities for developing the audio side of PD... If any of these can be solved by changing the GUI around than that's great, but I feel like the discussion has become more about aesthetics than function. The way PD looks is important, but only after the major functional issues have been resolved.
/* Matt Nish-Lapidus
www.ekran.org/mn-l matt@ekran.org // mattn-l@rogers.com
"What's this fish doing in my ear?" */
exactly. switching to gtk+/fltk/wx/qt isnt a magic bullet that will suddenly provide better usability, in fact, it will greatly slow down getting pd to a more usable state since it will require 1) a massive overhaul of pd itself, which will slow down work on the real issues you mention, and 2) the rewriting of every single gui external. so far i have yet to hear of any real significant gain from doing this either... why does it matter what toolkit is drawing the menu's? some may say "performance" or "better looking gui" but really the look of pd isnt determined by the toolkit, but the design of the gui objects and object boxes themselves, changing to another toolkit wont change the look much at all. as for performance, i think there is much profiling and optimization yet to be done with the current gui. as for prrtty menu/pref panel widgets: tcl/tk supports native os look on mac os X + windows, i've seen some mention of some people making it able to adapt to the look of gtk+ on linux too.
the widget set used is really not a big factor in the usability of the end result.
of course, all in my humble opinion :)
-josh
Matthew Nish-Lapidus wrote:
Here's my couple thoughts on this popular subject:
I think that before we try to put lots of effort into making PD look nicer we should be trying to improve functionality. There are still a couple issues that keep PD from reaching its full potential, and IMO these are way more important than bitmap sliders or fancy fonts. I originally asked about the font changing just as a point of interest so that I could do something fast and simple to improve pd for my use, obviously there are other people thinking about PD's looks too.
The way I see it there are a few things that keep PD back (in no particular order):
- GUI interfering with audio -- I know this is one of the reasons
that this discussion started, but I think we've lost track of that a little.
- Audio dropouts when loading sound files -- In my opinion this is
one of the largest issues in terms of using PD as a performance instrument, which I think it is otherwise ideally suited for.
- Audio latency (i've only tested this on os x) -- can't get
anything under 13ms with any hardware.
So, I know I'm repeating myself a little here.. but I think that these are the top priorities for developing the audio side of PD... If any of these can be solved by changing the GUI around than that's great, but I feel like the discussion has become more about aesthetics than function. The way PD looks is important, but only after the major functional issues have been resolved.
/* Matt Nish-Lapidus
www.ekran.org/mn-l matt@ekran.org // mattn-l@rogers.com
"What's this fish doing in my ear?" */
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
On Nov 23, 2003, at 9:06 AM, Matthew Nish-Lapidus wrote:
The way I see it there are a few things that keep PD back (in no particular order):
- GUI interfering with audio -- I know this is one of the reasons
that this discussion started, but I think we've lost track of that a little.
This is where threading comes into play. By moving the audio to it's own thread, then it could process audio without waiting for the GUI to finish any tasks. Most audio apps employ this setup - the drawing and UI are in the main thread and audio and related I/O are in separate threads. Audio DSP in a single thread would also allow for the priority to be changed with pthread_setschedparam() and on OSX a 'real-time' Mach-O thread could be setup to ensure CPU cycles are set aside for every instance the render chain is run. The downside is this might introduce a lot of complexity to the pd scheduler, and might require a lot of work to make it stable and perform well. Others will know more about this than I.
- Audio dropouts when loading sound files -- In my opinion this is
one of the largest issues in terms of using PD as a performance instrument, which I think it is otherwise ideally suited for.
Yves and Krzysztof have posted about this, and Yves has some code that could help with this. Krzysztof is also proposing a change to the way pd communicates with the GUI, which sounds like a good thing to try.
- Audio latency (i've only tested this on os x) -- can't get
anything under 13ms with any hardware.
Guenter suggested that portaudio could be changed to use callbacks which would allow for smaller buffers and thus reduce latency. I think this would probably have to happen alongside the other changes proposed in order to reduce problems with maintaining stable I/O.
So, I know I'm repeating myself a little here.. but I think that these are the top priorities for developing the audio side of PD... If any of these can be solved by changing the GUI around than that's great, but I feel like the discussion has become more about aesthetics than function. The way PD looks is important, but only after the major functional issues have been resolved.
A lot of people on this list are in full agreement. It doesn't do anyone much good to have a real-time audio system that cannot fully deliver on the guarantee of real-time audio output! There's no reason at all that Pd cannot give low-latency, glitch free audio on every platform - it just requires a bit more work.
cgc
/* Matt Nish-Lapidus
www.ekran.org/mn-l matt@ekran.org // mattn-l@rogers.com
"What's this fish doing in my ear?" */ \
-
cgc -
Josh Steiner -
Matthew Nish-Lapidus