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