<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><br></div>Late to the party, but here are a few thoughts on the topics that have come up:<br><br></div>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.<br>
<br></div><div>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).<br>
<br></div>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.<br>
</div><br>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:<br></div> * Pd Vanilla (maintain backward compatibility so that existing works won't bit-rot).<br>
</div> * Pd Extended (get stuff done by adding lots of capabilities to Pd)<br></div> * Pd-l2ork (get stuff done by adding lots of capabilities to Pd; not sure how this relates to Pd Extended)<br></div> * libpd (embed Pd into anything with a CPU)<br>
</div> * Anyone else?<br><br></div>I don't think these agendas are necessarily at odds with one another.<br></div>Cheers,<br></div> Peter<br><br><div><div><div><br></div></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Feb 24, 2014 at 8:12 PM, Billy Stiltner <span dir="ltr"><<a href="mailto:billy.stiltner@gmail.com" target="_blank">billy.stiltner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>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 <a href="http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html" target="_blank">http://home.comcast.net/~patslabtech/Applications/seatbelt_testing.html</a>.<br>
</div>reminds me more of reaktor than puredata. I have a hard time comprehending reaktor stuff but things make so much more since using pd. <br></div>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.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Mon, Feb 24, 2014 at 7:08 PM, Jonathan Wilkes <span dir="ltr"><<a href="mailto:jancsika@yahoo.com" target="_blank">jancsika@yahoo.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div>On 02/24/2014 03:03 PM, Dan Wilcox wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
Let's just focus on a single feature-- "$@"-- and assume that there is widespread desire for such a feature by most Pd users.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<span><font color="#888888"><br>
<br>
-Jonathan</font></span></div></div><div><div><br>
<br><div class="">
______________________________<u></u>_________________<br>
<a href="mailto:Pd-list@iem.at" target="_blank">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/<u></u>listinfo/pd-list</a><br>
</div></div></div></blockquote></div><br></div>
<br>_______________________________________________<br>
<a href="mailto:Pd-list@iem.at">Pd-list@iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br></blockquote></div><br></div>