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" <[EMAIL PROTECTED]> 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 > > _______________________________________________ > [email protected] 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
