<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 02/25/2014 10:41 PM, Peter Brinkmann
wrote:<br>
</div>
<blockquote
cite="mid:CADMEzexaC0tNsjTJyMUMLzrXRsiMPZyGevYmLcnuHxGL6TnW1g@mail.gmail.com"
type="cite">
<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>
</div>
</div>
</blockquote>
<br>
They're not at odds explicitly because none of them-- including
Miller's Vanilla-- claim to be the "core" Pd. People assume
Miller's Vanilla is "upstream". But instead of saying "upstream" a
new dev will erroneously ask, "How do I get 'x' into Vanilla," and a
veteran dev will respond robotically without guidance, "Ask
Miller." Eventually something like Dan Wilcox's frustration sets
in, and potential development gets lost.<br>
<br>
I think you've basically been able to do an end-run around the
problem with libpd up until this point. By jettisoning the GUI
cruft (or, technically speaking, ignoring it) you can base off
Miller's code and get a DSP engine and message dispatching system
that's "good enough". But it's not "upstream" in the sense of most
free software communities which have mechanisms to add missing
features. I highly doubt libpd has refrained from adding some
functionality to fetch the list of args from an abstraction because
it's not worth the five minutes it'd take you to implement that
feature. I'd bet you haven't added it because, like every other dev
on the list, you know it would be a waste of your time because Pd
Vanilla doesn't work like most "upstream" repos do. Namely a)
Miller has an idea about how that feature should work, b) he doesn't
articulate what it is, c) he's never reviewed the myriad
implementations of that feature floating around in Pd-extended, and
d) he won't accept patches for that feature which have been sitting
on the tracker for some time now. This goes for a large number of
feature categories-- not everything, but enough categories to make
devs wary from contributing anything other than external libs in
those categories.<br>
<br>
So to keep this from becoming yet another copy of a previous thread
in the archive, here's the thing: someone has to step up and say, "I
am going to maintain 'core Pd'." That would mean listening to the
needs of the community, reviewing patches, and _delegating_
responsibilities.<br>
<br>
For example, I've got some objects in Pd-l2ork to fetch attributes
of canvases, the Pd instance, and object classes. Some of the
methods are stable, and some I'm still working on. But if someone
said, "I am maintaining the core and am accepting patches" I'd
prioritize work on those classes, test the heck out of them, and try
to get as much input as possible before submitting them. And I
guarantee many more Pd developers would come out of the woodwork and
_ask_ to take responsibility for some other category of
functionality, because it's exciting to do work when you know it's
part of a larger project. If you've read the user mailing list
lately you know how true this is-- there are long (recent) threads
of people essentially daydreaming in detail about new directions for
the software to take, without producing any code because they _know_
from experience it would just end up rotting on the tracker.<br>
<br>
I'm not saying the "upstream" maintainer has to be you, Peter. But
it has to be somebody. I'm happy to recount the details of why
there's a Pd-l2ork and how it's different from Pd-extended, but if
no one is willing to say they will do the work of listening,
reviewing, and delegating work on an "upstream" core then we're just
dancing around the real problem.<br>
<br>
-Jonathan<br>
<br>
<blockquote
cite="mid:CADMEzexaC0tNsjTJyMUMLzrXRsiMPZyGevYmLcnuHxGL6TnW1g@mail.gmail.com"
type="cite">
<div dir="ltr">
<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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="http://home.comcast.net/%7Epatslabtech/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
moz-do-not-send="true"
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="">
_______________________________________________<br>
<a moz-do-not-send="true"
href="mailto:Pd-list@iem.at" target="_blank">Pd-list@iem.at</a>
mailing list<br>
UNSUBSCRIBE and account-management -> <a
moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/pd-list"
target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
_______________________________________________<br>
<a moz-do-not-send="true" href="mailto:Pd-list@iem.at">Pd-list@iem.at</a>
mailing list<br>
UNSUBSCRIBE and account-management -> <a
moz-do-not-send="true"
href="http://lists.puredata.info/listinfo/pd-list"
target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>