Hi again,
IOhannes m zmölnig wrote:
and how do you notice that it is split into 2 "different" libs in PdX?
My mistake, I thought there was a mrpeach net lib and a mrpeach osc lib.
Couldn't these objects be wrapped to give the same name as the standard OSC objects,
ähm, what is the "standard OSC objects".
The ones people have used for a very long time in Pd (for me since 2002), which are loaded by default in Pd Extended and which do the job in a straightforward way.
when using oscx, you are using a library: so either Path or [import] (or better [declare]) have to be discussed first. so what's the difference to mrpeach's libs?
As I mentioned, they are not available by default.... which is the reason I brought this point up. I'm not trying to convince anyone to use outdated software, but I am interested in why it would get replaced in a non-compatible and slightly more complicated way.
however, indeed you have to use 2 objects instead of just 1. big fat bummer!
Yes it is, since it will take twice as long to explain how to use this system in the Pd FLOSS Manual. And that even leaves aside the fact that import, declare or whatever will also have to be explained in-line. See how complicated it gets? ;-)
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?
crashes. osc-standards. ability to communicate with OSC-apps over udp/tcp/usb/...
Thank you. Your brevity is greatly appreciated ;-)
Now can anyone tell me why the original oscx stuff can't just be transparently replaced? Or that at least the mrpeach stuff could be included in the startup of Pd Extended at least? This would make teaching/documenting the "new way" of OSC a hell of a lot easier!!!!
D.