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