[PD] GUI and such

[cgc]

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):
>
> 1.  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.

> 2.  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.

> 3.  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 at ekran.org // mattn-l at rogers.com
>
> "What's this fish doing in my ear?"
> */
> \