[PD] libpd separating gui from core

[Dan Wilcox]

Also, to be honest, at this point if Cycling 74 came out with Max runtimes for iOS and Linux, I would probably switch. I don't say that because I don't like PD, but more from a pragmatic point of view where I consider which project is currently progressing in the long term.

For instance, on PD-dev, we're talking about updating GEM so it will work with the new Apple APIS aka in 64bit on any Mac OSX 10.7+. The writing has been on the wall for that transition FOR YEARS but there has been no work on that front. I must admit that I'm volunteering to make this update not because I use GEM, but because I fear PD losing out to Max when GEM doesn't work in computer labs running new Macs. Again, this is from personal experience at a major teaching institution where I was trying to push teaching PD but, frankly, it just wouldn't cut it for course requirements and taste of the professors involved. And I take that as a personal failure.

enohp ym morf tnes
--------------
Dan Wilcox
danomatika.com
robotcowboy.com

On Feb 23, 2014, at 7:37 AM, Dan Wilcox <danomatika at gmail.com> wrote:

> On Feb 23, 2014, at 2:11 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
> 
>> Do you have an example of a patch that suffers from Pd's current single-threaded implementation that would be measurably improved by using a multi-threaded approach?
> 
> Ask any of the people who have to run two instances of Pd in order to have both GEM and audio without dropouts. And this is in 2014 with modern computers orders of magnitude more capable than when Pd was first designed.
> 
>> Also, what is the metric to use here?
> 
> Mmm open a larger patch with audio running, momentary dropouts.
> 
> Also, this is perhaps better to ask a beginner trying to pickup PD after starting with Max MSP, they may not give you "meaningful metrics" but their impression may be along the lines of "not only does this program look old, but it keeps clicking when I'm dragging things around". Etc etc
> 
> Things maybe acceptable to us PD "grey beards", but at some point it would be nice to find a way to enter the modern, multicore multithreaded world. Moores law has shifted from clock speed to "just add more cores" years ago now, so it's not like "buy a faster machine" is going to magically solve single threaded speed issues.
> 
> At the very least, we should be able to run a performance intensive GEM patch with real time audio without drop outs *while* editing. Oh wait, that's called Max MSP. :D And that is perhaps the reasonable stance taken by a certain teaching institution I just left who is really only interested in PD on places where Max currently can't be used, like Raspberry PI.
> 
> enohp ym morf tnes
> --------------
> Dan Wilcox
> danomatika.com
> robotcowboy.com