[PD] libpd separating gui from core

[Billy Stiltner]

re:
":P Moreover, processors haven't gotten faster in a while"
you can say that again!
I think it was 2005 I ordered the mayor of Appalachia a 3.2Ghz Intel CPU
17"laptop. My current machine is only 2.2 Ghz.


On Tue, Feb 25, 2014 at 10:41 PM, Peter Brinkmann <
peter.brinkmann at googlemail.com> 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.
> 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/20140226/d41408fd/attachment.htm>