[PD] midi to osc?
IOhannes m zmölnig
zmoelnig at iem.at
Thu Jul 9 21:58:57 CEST 2009
Derek Holzer wrote:
> Hi again,
thanks for the plentiful use of ;-) to peace my mind...
> 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.
which in fact they should be.
i would say it is a bug that they are both in a "mrpeach" library (i
guess most people won't care whether martin has written them or whoelse;
but they might like to have osc-related or net-related objects)
>>> 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
if i understand hans correctly, he is planning to remove all the "loaded
by default" anyhow (which i think is not a bad thing).
>> 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.
actually they _are_ available by default in pd-extended:
[mrpeach/packOSC] and [mrpeach/udpsend] will just create
(not that i very much like this the way it is; i would so much prefer
[osc/packOSC] and [net/udpsend])
no need to know anything about libraries, paths, loading-by-default, and
>> however, indeed you have to use 2 objects instead of just 1. big fat
> 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? ;-)
at least i think that when people are reading the tutorial they should
have an idea about how to connect 2 objects, and how to interact with
these objects independently.
as for libraries see my remark above
alternatively: i guess the tutorials are not self-contained (e.g. you
can expect the user to already having read the other tutorial where they
are tought to connect objects), so you can also schedule the "library
loading tutorial" before the OSC tutorial.
> Now can anyone tell me why the original oscx stuff can't just be
> transparently replaced?
it's easy (apart from the crashes).
it's about creating an abstraction out of about 5 objects and 2
message-boxes. i leave this as an exercise for the adept user.
> 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!!!!
or at least remove oscx from the startup. this would make teaching the
"old way" less preferable :-)
More information about the Pd-list