[PD-dev] split out 'osc' and 'net' from 'mrpeach'?
martin.peach at sympatico.ca
Sun Nov 28 19:38:43 CET 2010
On 2010-11-28 12:13, Hans-Christoph Steiner wrote:
> Hey Martin and all,
> Just had a thought: originally everything in the 'mrpeach' folder was
> bundled into a single library, which I think Martin didn't really
> intend. I did it to get Martin's valuable code out there in a kind of
> beta way. Now I think its quite clear that the 'net' and 'osc' sections
> in 'mrpeach' are really the canonical way of doing networking and OSC
> with Pd, so I think it makes sense to have them distributed as the 'net'
> and 'osc' library. I'm guessing Martin had that intention originally.
> Also, I noticed that IOhannes's filed an Intent-To-Package for something
> called 'pd-osc', which I am guessing is externals/mrpeach/osc.
> So my only question is: what becomes of 'mrpeach'?
I agree it makes sense to package things by function rather than by
author. So here's my take:
Inside OSC ATM is [pipelist], which should maybe go into some list lib
although it's useful for delaying timestamped OSC messages.
In Net, [tcpreceive] is unnecessary as its functionality is covered by
[binfile] and [midifile] should go into a file handling lib.
[slipenc] and [slipdec] are useful for OSC over serial, so maybe put
them in Net?
[tab2flist], [flist2tab], [tabfind] operate on table/arrays.
[sqosc~], [rc~], [rcosc~], [rojo~] are audio generators.
[op~] is similar to [>~], [<~] etc but doesn't have trouble
instantiating without hexloader.
str only works with the (unaccepted) string patch, so it could be dropped.
cmos is not really useful except to simulate some CMOS logic ICs.
[life2x] is a cellular automaton.
[which] tends to crash a lot, but can help to find the path to an external.
[runningmean] is a math object.
More information about the Pd-dev