[PD] libpd separating gui from core

[Peter Brinkmann]

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 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.
> 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>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 mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
>> listinfo/pd-list
>>
>
>
> _______________________________________________
> 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/20140225/24e50185/attachment-0001.htm>