[PD] libpd separating gui from core

Jonathan Wilkes jancsika at yahoo.com
Wed Feb 26 19:50:22 CET 2014


On 02/25/2014 10:41 PM, Peter Brinkmann wrote:
>
> Late to the party, but here are a few thoughts on the topics that have 
> come up:
>
> 1. Pd and concurrency: Audio processing must be separate from user 
> interaction. If you want decent latency, you need to do your audio 
> processing on a real-time thread. On the other hand, the GUI cannot be 
> on a real-time thread. So that's settled :P Moreover, processors 
> haven't gotten faster in a while, but you get more and more of them. 
> So, to stay relevant in the long run, we really want the option of 
> multi-threaded audio processing (bonus points if we manage to squeeze 
> in GPU support). It's not so much about existing patches that don't 
> work well right now; it's more about patches that have never been 
> attempted.
>
> 1a. On a related note, it would also be helpful to have support for 
> hardware-specific optimizations such as vectorization. Right now, 
> libpd will run anywhere (which is great), but it's optimized nowhere 
> (which causes some users to abandon it after using it as a prototyping 
> tool).
>
> 2. Multi-instance support must happen because that's what it takes to 
> make plugins with libpd. I'm sure we'll see a whole cottage industry 
> of people making Pd-based plugins when multiple instances of Pd become 
> available. I'm also pretty sure that this change would seriously 
> interact with a concurrency overhaul, and so those two should be done 
> together.
>
> 3. I'm sort of losing track of all the stakeholders and their agendas. 
> Here's a rough list of players and their agendas as I see them:
>       * Pd Vanilla (maintain backward compatibility so that existing 
> works won't bit-rot).
>       * Pd Extended (get stuff done by adding lots of capabilities to Pd)
>       * Pd-l2ork (get stuff done by adding lots of capabilities to Pd; 
> not sure how this relates to Pd Extended)
>       * libpd (embed Pd into anything with a CPU)
>       * Anyone else?
>
> I don't think these agendas are necessarily at odds with one another.

They're not at odds explicitly because none of them-- including Miller's 
Vanilla-- claim to be the "core" Pd.  People assume Miller's Vanilla is 
"upstream".  But instead of saying "upstream" a new dev will erroneously 
ask, "How do I get 'x' into Vanilla," and a veteran dev will respond 
robotically without guidance, "Ask Miller."  Eventually something like 
Dan Wilcox's frustration sets in, and potential development gets lost.

I think you've basically been able to do an end-run around the problem 
with libpd up until this point.  By jettisoning the GUI cruft (or, 
technically speaking, ignoring it) you can base off Miller's code and 
get a DSP engine and message dispatching system that's "good enough".  
But it's not "upstream" in the sense of most free software communities 
which have mechanisms to add missing features.  I highly doubt libpd has 
refrained from adding some functionality to fetch the list of args from 
an abstraction because it's not worth the five minutes it'd take you to 
implement that feature.  I'd bet you haven't added it because, like 
every other dev on the list, you know it would be a waste of your time 
because Pd Vanilla doesn't work like most "upstream" repos do.  Namely 
a) Miller has an idea about how that feature should work, b) he doesn't 
articulate what it is, c) he's never reviewed the myriad implementations 
of that feature floating around in Pd-extended, and d) he won't accept 
patches for that feature which have been sitting on the tracker for some 
time now.  This goes for a large number of feature categories-- not 
everything, but enough categories to make devs wary from contributing 
anything other than external libs in those categories.

So to keep this from becoming yet another copy of a previous thread in 
the archive, here's the thing: someone has to step up and say, "I am 
going to maintain 'core Pd'."  That would mean listening to the needs of 
the community, reviewing patches, and _delegating_ responsibilities.

For example, I've got some objects in Pd-l2ork to fetch attributes of 
canvases, the Pd instance, and object classes.  Some of the methods are 
stable, and some I'm still working on.  But if someone said, "I am 
maintaining the core and am accepting patches" I'd prioritize work on 
those classes, test the heck out of them, and try to get as much input 
as possible before submitting them.  And I guarantee many more Pd 
developers would come out of the woodwork and _ask_ to take 
responsibility for some other category of functionality, because it's 
exciting to do work when you know it's part of a larger project.  If 
you've read the user mailing list lately you know how true this is-- 
there are long (recent) threads of people essentially daydreaming in 
detail about new directions for the software to take, without producing 
any code because they _know_ from experience it would just end up 
rotting on the tracker.

I'm not saying the "upstream" maintainer has to be you, Peter.  But it 
has to be somebody.  I'm happy to recount the details of why there's a 
Pd-l2ork and how it's different from Pd-extended, but if no one is 
willing to say they will do the work of listening, reviewing, and 
delegating work on an "upstream" core then we're just dancing around the 
real problem.

-Jonathan

> Cheers,
>      Peter
>
>
>
>
> On Mon, Feb 24, 2014 at 8:12 PM, Billy Stiltner 
> <billy.stiltner at gmail.com <mailto:billy.stiltner at gmail.com>> wrote:
>
>     I think Miller's  puredata is awesome. more than 20 years ago I
>     wrote my own assembly routines as well as c++ for an analog
>     devices 32 ch board for waterplant control software , but ended up
>     using the factory drivers instead when they came out for this
>     software
>     http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html
>     <http://home.comcast.net/%7Epatslabtech/Applications/seatbelt_testing.html>.
>     reminds me more of reaktor than puredata. I  have a hard time
>     comprehending reaktor stuff but things make so much more since
>     using pd.
>     I ought do dig into the programming part of pd . I read a lot of
>     the code and it's kinda starting to sink in how to write an
>     external, it's not quite like on the tip of my toungue yet though.
>
>
>     On Mon, Feb 24, 2014 at 7:08 PM, Jonathan Wilkes
>     <jancsika at yahoo.com <mailto:jancsika at yahoo.com>> wrote:
>
>         On 02/24/2014 03:03 PM, Dan Wilcox wrote:
>
>             Exactly. If we can build a list of things that
>             should/could be in the core, then we have a starting place
>             to see if there is a way to work into into either vanilla
>             or a wrapper like libpd.
>
>
>         Let's just focus on a single feature-- "$@"-- and assume that
>         there is widespread desire for such a feature by most Pd users.
>
>         How do we put this feature into a wrapper like libpd?  The
>         only thing I can think of is as part of a patch set that get
>         applied to core Vanilla, and that's hard to maintain.
>
>         As for working stuff into Vanilla-- that's Miller's personal
>         version of Pd, and I've never once seen him state that it's
>         the reference client, or that it's at the top of any
>         hierarchy.  All I've seen is passive-aggressive statements
>         from other devs on this list who say, "You'll have to ask
>         Miller if you want to get 'whatever' in Vanilla," when I ask
>         about the kind of issues you're talking about. Of course I
>         can't be certain but I'd guess that style of non-development
>         is probably one of the biggest sources of your frustration.
>
>         But I really will help you implement whatever it is you think
>         improves sustainable development for Pd.  I really, really
>         don't want to extract patches from the 1000+ commits in
>         Pd-l2ork (granted the core/non-graphical changes would be
>         fewer), but I'll help you do it if that's the path you want to
>         take.
>
>         -Jonathan
>
>
>         _______________________________________________
>         Pd-list at iem.at <mailto:Pd-list at iem.at> mailing list
>         UNSUBSCRIBE and account-management ->
>         http://lists.puredata.info/listinfo/pd-list
>
>
>
>     _______________________________________________
>     Pd-list at iem.at <mailto:Pd-list at iem.at> mailing list
>     UNSUBSCRIBE and account-management ->
>     http://lists.puredata.info/listinfo/pd-list
>
>

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


More information about the Pd-list mailing list