[PD] libpd separating gui from core

Sun Feb 23 19:43:02 CET 2014

On Feb 23, 2014, at 12:14 PM, Max <abonnements at revolwear.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> ok, Dan, i can feel you there. but let's not mix up the GUI-core
> separation with the GEM on OS X question. As much as their
> consequences are similar, they are fundamentally different in their
> implementation, no?

Max,

Forgive me as I'm not going to answer specifically regarding GEM :D That was just a recently re-opened wound so it made a pointed example.

I think what bothers me is that this comes up again and again and still the main response is: "what we have now is fine". That, after plenty of effort and previous code implementations that died on the vine and it feels already like trying to push libpd in that direction will yield the same result. I'm not trying to single out specific people, but just my general feeling in the project.

Maybe I'm off base, but I feel that pd needs real modernization or it will get less and less adoption. Sure it will be around, but you wont see as many beginners starting with it. At this point a  continued debate over whether the gui should be multithreaded or not seems moot to me.

That comes in contrast to my involvement with the OpenFrameworks community which is growing via leaps and bounds. Sure, it's a younger project, but we've already had a number of developer conferences, developed a concerted development roadmap, delegated community leaders, etc. We work together. There have been a number of residencies sponsoring further development. I would really like to see that with this community as I really love working with PD but, again, why bother trying to push forward such an agenda on my own? I could probably rebuild my entire setup using Super Collider but I simply like patching audio better.

I'm not trying to weigh blame on anyone, just explain the situation as I see it. I suppose from a different perspective, I'm an outsider coming in and trying to needlessly shake up things that are already working, proposing premature optimizations, etc.

> Questions that comes to my mind when I see the GUI-core separation
> discussion is this: Let's assume - totally hypothetically spoken -
> there is a company or individual who would sponsor this effort.
> 1. Is there someone capable of completing the task?

I can probably do it if I wrap my head around the pd core. Peter Brinkmann and Jonathan W are probably better suited with their core familiarity and, obviously, Miller knows it through and through. The problem, of course, is that I or whoever would do this would need to be able to sit down, focus, and crank it out. I can't answer who could help sponsor that. My initial idea would have been STEIM, but do to NL budget cuts, they now have to rent the studios so the previous "no stings attached" residencies I had before are sadly no longer available. Another answer would Universities, but so far, I haven't seen much movement on this from previous discussions. The last option would be how I've funded my most recent project: freelance work and dedicating time off to work on my own projects. I could probably manage that, if needed, but I would *really really really* hate to spend a month on something that may not be adopted o go anywhere. I'd like to have the decisions made before I go out on a limb on my own dime. Open source is all about sharing, but that doesn't mean we write code for everyone else for free. 

> 2. Would the result of this work be accepted by Miller and become vanilla?

As history has shown, the chances are limited. Again, there is probably a good way to do it where you could choose whether to use a single or multithreaded core but the real stakeholders are absent from the discussion.

> 3. How long would that take?

Dunno. A few full time weeks for one person, probably (at least from my estimate). I imagine that could be shorter if there is a core developer meeting and overall architectural decisions could be hashed out and a roadmap developed. Sadly, this would be perfect for Google Summer of Code.

> m.
> 
> Am 2014년 02월 23일 21:37, schrieb Dan Wilcox:
>> 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 _______________________________________________ 
>> Pd-list at iem.at mailing list UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iEYEARECAAYFAlMKLGwACgkQ3EB7kzgMM6Ij6QCeLvTudFFoBWIAryx6DvaFTI6D
> KH4An0zgJwCtqm1a9evrikGWWX48xyZ4
> =oJnl
> -----END PGP SIGNATURE-----

--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140223/70eb9a49/attachment-0001.htm>