[PD] A Few GSoC Project Ideas

[Hans-Christoph Steiner]

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