[PD] A Few GSoC Project Ideas
Hans-Christoph Steiner
hans at eds.org
Thu Mar 13 03:38:13 CET 2008
On Mar 12, 2008, at 10:00 PM, Andy Farnell wrote:
>
> These are all cool proposals Greg.
>
> On Wed, 12 Mar 2008 20:24:33 -0500
> "Greg Surges" <surgesg at gmail.com> wrote:
>
>> 1. A set of externals designed for real-time, high-level analysis
>> of control
>> data. This could include things like histograms, rhythm analysis,
>> rate-limiting and data-filtering objects, all
>> designed for use on a constant stream of input.
>
> There is some overlap with "mapping" library, and most if not all have
> been attempted as abstractions rather than externals. Though
> there's plenty
> of room for new data analysis objects and this proposal seems to
> have nice
> bite sized chunks (contains many independent objects that could
> stand alone)
> which makes it attractive for this GSoC requirements (discourage
> over-ambitious
> monolithic projects)
It might makes sense to split up some of the mapping objects into
more specific libraries. It's getting pretty big these days. I
suppose this could be a GSoC project as well.
>> 2. A set of externals designed to make string assembly and parsing
>> much
>> easier, particularly geared towards the creation of OSC messages.
>
> Strings have always been a problem in Pd. Puredata has a deep
> traumatic
> wound since its childhood AFAICS, because Millers position has been
> that
> it didn't need strings and they could always be "implemented on top".
> Several others like Bryan Jurish have made string libraries, and so
> you would
> find a good mentor. But beware this isn't as simple as it seems on
> the surface
> because of the lack of an intrinsic string type. This proposal has
> merit in that
> it might challenge entrenched and stuck thinking, because strings
> have run us into
> cul-de-sacs before and maybe a fresh vision would push that forward.
At the Pd meeting at LAC in Cologne, IOhannes talked about
incorporating a mechanism for registering any generic type, like
Martin Peach's strings, or data for Gem, PDP, or gridflow. This
could make a good GSoC project for someone who wants to get into the
depths of Pd.
>> 3. Finally, a set of band-limited oscillators, to allow for
>> spectrally rich
>> waveforms without aliasing.
>
> Again, much has been done before and there's no shortage of BLOSC
> abstractions
> and some externals. Unifying these into an efficient and coherent
> set would
> be a good project, as would porting existing optimal
> implementations from Csound
> or other open sources.
I second this, it would be great to have a complete, clean library of
bandwidth-limited oscillators for Pd. It would be a good project too.
.hc
>
> a.
>
>
> --
> Use the source
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/
> listinfo/pd-list
------------------------------------------------------------------------
----
Computer science is no more related to the computer than astronomy is
related to the telescope. -Edsger Dykstra
More information about the Pd-list
mailing list