On 02/25/2014 10:41 PM, Peter Brinkmann 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.
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.
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.
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.
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.
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.
-Jonathan
Cheers,
Peter
On Mon, Feb 24, 2014 at 8:12 PM, Billy Stiltner
<billy.stilt...@gmail.com <mailto: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
<http://home.comcast.net/%7Epatslabtech/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 <mailto: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 <mailto:Pd-list@iem.at> mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@iem.at <mailto: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
