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@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.
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@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@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list