As suggests Derek, it would be nice to have some parts of the help reorganized. For exemple, the sound could be like this : I) sound i) oscillators a) purepd … b) externals … ii) filters a) purepd … b) externals …
It is just an exemple, there is certainly better. And it will be useful for the beginner and the pro. For the network, this will be the same with [netsend] [netreceive] [udpsend] [udpreceive] [packOSC] [routeOSC] [oggcast~] [oggamp~] etc. etc. Have you remarks ? ++
Jack
Le jeudi 09 juillet 2009 à 20:50 +0200, Derek Holzer a écrit :
I knew somebody would have to complicate my simple, straightforward answer...
Why hasn't somebody made this the "default" set of OSC objects in Extended by now then? Or perhaps replaced the original oscx libraries with these in a non-breaking way? And why is it split into two different libs?
Couldn't these objects be wrapped to give the same name as the standard OSC objects, but with whatever "better" functionality the list gurus have decided they give? For n00bs, having to use two different non-standard/non-default libs is just super confusing, and distracts from the task at hand, which is not to goof around with configuring Pd and/or importing libs but to communicate between two OSC apps.
Also for writing the FLOSS Manual, a "correct" chapter on OSC now means either Path or [import] has to be discussed first, and then two different libs must be used. Big fat bummer!
Can anybody say (in a few sentences rather than a lengthly thread) why one wouldn't use the simpler OSC objects for such a simple task? Points for brevity, nobody gets paid by the word around here ;-)
D.
IOhannes m zmölnig wrote:
i agree with everything derek has said, but one thing: do NOT use oscx for OSC-communication. instead use mrpeach's net and osc libraries. [packOSC]+[udpsend] for sending osc [udpreceive]+[unpackOSC] for receiving osc
for the reasons see the archives of this list...