Hi all,
Pd version 0.42-4 is out on http://crca.ucsd.edu/~msp/software.htm or via subversion on sourceforge: svn checkout https://pure-data.svn.sourceforge.net/svnroot/pure-data/trunk/pd/
This fixes the crash bug Luke Iannini tracked down (a patch containing templates and also an unset "send" crashes), plus Hans's gfxstub crash and 2 bugs in the (still experimental) pd~ object.
cheers Miller
Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/listinfo/pd-announce
hello folks, I'm using OSC to send information from Processing to Pd... I started writing my "receiving" Patch in a Computer where was Installed Ubuntu 8.04 and Pd-extended 0.40.3 in stalled by the .deb package, my laptop was an Archlinux "client" in which Processing was running... Processing sent floating point numbers to Pd... All worked properly....
In the second Panorama, my archlinux box is both the "server" and the "client", Pd is the version 0.41.4 compiled by me with all useful libraries (OSCx for example)... Pd refuses to receive floating point numbers from Processing giving me this value:
1.4013e-45 ...... = n/0 ???
I can use only Integer numbers.... why ???
Fabio [mbutUbuntu] Buda
--- mbutubuntu mbutubuntu@yahoo.it schrieb am Do, 5.2.2009:
hello folks, I'm using OSC to send information from Processing to Pd... I started writing my "receiving" Patch in a Computer where was Installed Ubuntu 8.04 and Pd-extended 0.40.3 in stalled by the .deb package, my laptop was an Archlinux "client" in which Processing was running... Processing sent floating point numbers to Pd... All worked properly....
In the second Panorama, my archlinux box is both the "server" and the "client", Pd is the version 0.41.4 compiled by me with all useful libraries (OSCx for example)... Pd refuses to receive floating point numbers from Processing giving me this value:
1.4013e-45 ...... = n/0 ???
I can use only Integer numbers.... why ???
hi
from what i know, OSC supports a whole bunch of number types and obviously [dumpOSC] doesn't know how to handle the type chosen by processing.
i guess, i can't help you here, probably only the author of the OSCx library can. however, OSCx shouldn't be used anymore, since it does not seem to be maintained anymore and is known to be buggy. there is a well maintained and well tested replacement for it in mrpeach, though it might not be as straight forward to use as OSCx.
i think, you could replace [dumpOSC] by something like:
[udpreceive <portnumber>] | [unpackOSC]
good luck
roman
Yep, as Roman says try [udpreceive] with [unpackOSC] (OSC comme often
'on' UDP) or [tcpreceive] with [unpackOSC], if you want a service
with connection. The choice depends if you absolutely need to receive
your data.
AFAIK, OSCx accepts only UDP protocol.
++
Jack
Le 5 févr. 09 à 14:15, Roman Haefeli a écrit :
--- mbutubuntu mbutubuntu@yahoo.it schrieb am Do, 5.2.2009:
hello folks, I'm using OSC to send information from Processing to Pd... I started writing my "receiving" Patch in a Computer where was Installed Ubuntu 8.04 and Pd-extended 0.40.3 in stalled by the .deb package, my laptop was an Archlinux "client" in which Processing was running... Processing sent floating point numbers to Pd... All worked properly....
In the second Panorama, my archlinux box is both the "server" and the "client", Pd is the version 0.41.4 compiled by me with all useful libraries (OSCx for example)... Pd refuses to receive floating point numbers from Processing giving me this value:
1.4013e-45 ...... = n/0 ???
I can use only Integer numbers.... why ???
hi
from what i know, OSC supports a whole bunch of number types and
obviously [dumpOSC] doesn't know how to handle the type chosen by
processing.i guess, i can't help you here, probably only the author of the
OSCx library can. however, OSCx shouldn't be used anymore, since it
does not seem to be maintained anymore and is known to be buggy.
there is a well maintained and well tested replacement for it in
mrpeach, though it might not be as straight forward to use as OSCx.i think, you could replace [dumpOSC] by something like:
[udpreceive <portnumber>] | [unpackOSC]
good luck
roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
thanks... udpreceive wors wery well.... but udpsend doesn't... :P:P....
Jack wrote:
Yep, as Roman says try [udpreceive] with [unpackOSC] (OSC comme often 'on' UDP) or [tcpreceive] with [unpackOSC], if you want a service with connection. The choice depends if you absolutely need to receive your data. AFAIK, OSCx accepts only UDP protocol. ++
Jack
Le 5 févr. 09 à 14:15, Roman Haefeli a écrit :
--- mbutubuntu mbutubuntu@yahoo.it schrieb am Do, 5.2.2009:
hello folks, I'm using OSC to send information from Processing to Pd... I started writing my "receiving" Patch in a Computer where was Installed Ubuntu 8.04 and Pd-extended 0.40.3 in stalled by the .deb package, my laptop was an Archlinux "client" in which Processing was running... Processing sent floating point numbers to Pd... All worked properly....
In the second Panorama, my archlinux box is both the "server" and the "client", Pd is the version 0.41.4 compiled by me with all useful libraries (OSCx for example)... Pd refuses to receive floating point numbers from Processing giving me this value:
1.4013e-45 ...... = n/0 ???
I can use only Integer numbers.... why ???
hi
from what i know, OSC supports a whole bunch of number types and obviously [dumpOSC] doesn't know how to handle the type chosen by processing.
i guess, i can't help you here, probably only the author of the OSCx library can. however, OSCx shouldn't be used anymore, since it does not seem to be maintained anymore and is known to be buggy. there is a well maintained and well tested replacement for it in mrpeach, though it might not be as straight forward to use as OSCx.
i think, you could replace [dumpOSC] by something like:
[udpreceive <portnumber>] | [unpackOSC]
good luck
roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you use OSC, you need [packOSC] before [udpsend]. See the help
patch of [packOSC] in mrpeach.
++
Jack
Le 5 févr. 09 à 16:12, mbutubuntu a écrit :
thanks... udpreceive wors wery well.... but udpsend
doesn't... :P:P....Jack wrote:
Yep, as Roman says try [udpreceive] with [unpackOSC] (OSC comme
often 'on' UDP) or [tcpreceive] with [unpackOSC], if you want a
service with connection. The choice depends if you absolutely need
to receive your data. AFAIK, OSCx accepts only UDP protocol. ++Jack
Le 5 févr. 09 à 14:15, Roman Haefeli a écrit :
--- mbutubuntu mbutubuntu@yahoo.it schrieb am Do, 5.2.2009:
hello folks, I'm using OSC to send information from Processing to Pd... I started writing my "receiving" Patch in a Computer where was Installed Ubuntu 8.04 and Pd-extended 0.40.3 in stalled by the .deb package, my laptop was an Archlinux "client" in which Processing was running... Processing sent floating point numbers to Pd... All worked properly....
In the second Panorama, my archlinux box is both the "server" and the "client", Pd is the version 0.41.4 compiled by me with all useful libraries (OSCx for example)... Pd refuses to receive floating point numbers from Processing giving me this value:
1.4013e-45 ...... = n/0 ???
I can use only Integer numbers.... why ???
hi
from what i know, OSC supports a whole bunch of number types and
obviously [dumpOSC] doesn't know how to handle the type chosen by
processing.i guess, i can't help you here, probably only the author of the
OSCx library can. however, OSCx shouldn't be used anymore, since
it does not seem to be maintained anymore and is known to be
buggy. there is a well maintained and well tested replacement for
it in mrpeach, though it might not be as straight forward to use
as OSCx.i think, you could replace [dumpOSC] by something like:
[udpreceive <portnumber>] | [unpackOSC]
good luck
roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
JacK, I know... packOSC works, but udpsend doesn't connect, neither tcpsend...
Jack wrote:
If you use OSC, you need [packOSC] before [udpsend]. See the help patch of [packOSC] in mrpeach. ++
Jack
Le 5 févr. 09 à 16:12, mbutubuntu a écrit :
thanks... udpreceive wors wery well.... but udpsend doesn't... :P:P....
Jack wrote:
Yep, as Roman says try [udpreceive] with [unpackOSC] (OSC comme often 'on' UDP) or [tcpreceive] with [unpackOSC], if you want a service with connection. The choice depends if you absolutely need to receive your data. AFAIK, OSCx accepts only UDP protocol. ++
Jack
Le 5 févr. 09 à 14:15, Roman Haefeli a écrit :
--- mbutubuntu mbutubuntu@yahoo.it schrieb am Do, 5.2.2009:
hello folks, I'm using OSC to send information from Processing to Pd... I started writing my "receiving" Patch in a Computer where was Installed Ubuntu 8.04 and Pd-extended 0.40.3 in stalled by the .deb package, my laptop was an Archlinux "client" in which Processing was running... Processing sent floating point numbers to Pd... All worked properly....
In the second Panorama, my archlinux box is both the "server" and the "client", Pd is the version 0.41.4 compiled by me with all useful libraries (OSCx for example)... Pd refuses to receive floating point numbers from Processing giving me this value:
1.4013e-45 ...... = n/0 ???
I can use only Integer numbers.... why ???
hi
from what i know, OSC supports a whole bunch of number types and obviously [dumpOSC] doesn't know how to handle the type chosen by processing.
i guess, i can't help you here, probably only the author of the OSCx library can. however, OSCx shouldn't be used anymore, since it does not seem to be maintained anymore and is known to be buggy. there is a well maintained and well tested replacement for it in mrpeach, though it might not be as straight forward to use as OSCx.
i think, you could replace [dumpOSC] by something like:
[udpreceive <portnumber>] | [unpackOSC]
good luck
roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Ah, ok :)
Have you open [routeOSC] and [packOSC] in mrpeach ?
Click on [connect 127.0.0.1 9997( message, you must have in the
console :
udpsend: connecting to port 9997
Then click on [send /test/one/two/three zz 88 T( message, you must
have in the console :
print: /test/one/two/three zz 88 T
error: pipelist: no method for '/test/one/two/three'
... you might be able to track this down from the Find menu.
In this case, all should be ok ?
++
Jack
Le 5 févr. 09 à 16:23, mbutubuntu a écrit :
JacK, I know... packOSC works, but udpsend doesn't connect, neither
tcpsend...Jack wrote:
If you use OSC, you need [packOSC] before [udpsend]. See the help
patch of [packOSC] in mrpeach. ++Jack
Le 5 févr. 09 à 16:12, mbutubuntu a écrit :
thanks... udpreceive wors wery well.... but udpsend
doesn't... :P:P....Jack wrote:
Yep, as Roman says try [udpreceive] with [unpackOSC] (OSC comme
often 'on' UDP) or [tcpreceive] with [unpackOSC], if you want a
service with connection. The choice depends if you absolutely
need to receive your data. AFAIK, OSCx accepts only UDP protocol. ++Jack
Le 5 févr. 09 à 14:15, Roman Haefeli a écrit :
--- mbutubuntu mbutubuntu@yahoo.it schrieb am Do, 5.2.2009:
hello folks, I'm using OSC to send information from Processing to Pd... I started writing my "receiving" Patch in a Computer where was Installed Ubuntu 8.04 and Pd-extended 0.40.3 in stalled by the .deb package, my laptop was an Archlinux "client" in which Processing was running... Processing sent floating point numbers to Pd... All worked properly....
In the second Panorama, my archlinux box is both the "server" and the "client", Pd is the version 0.41.4 compiled by me with all useful libraries (OSCx for example)... Pd refuses to receive floating point numbers from Processing giving me this value:
1.4013e-45 ...... = n/0 ???
I can use only Integer numbers.... why ???
hi
from what i know, OSC supports a whole bunch of number types
and obviously [dumpOSC] doesn't know how to handle the type
chosen by processing.i guess, i can't help you here, probably only the author of the
OSCx library can. however, OSCx shouldn't be used anymore,
since it does not seem to be maintained anymore and is known to
be buggy. there is a well maintained and well tested
replacement for it in mrpeach, though it might not be as
straight forward to use as OSCx.i think, you could replace [dumpOSC] by something like:
[udpreceive <portnumber>] | [unpackOSC]
good luck
roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http:// lists.puredata.info/listinfo/pd-list
I think the problem is "server side".... processing couldn't open a socket... :P:P
IOhannes m zmoelnig wrote:
mbutubuntu wrote:
JacK, I know... packOSC works, but udpsend doesn't connect, neither tcpsend...
highly unlikely. show your patch :-)
fgmasdr IOhannes
--- Jack jack@rybn.org schrieb am Do, 5.2.2009:
Yep, as Roman says try [udpreceive] with [unpackOSC] (OSC comme often
'on' UDP) or [tcpreceive] with [unpackOSC], if you want a service
with connection. The choice depends if you absolutely need to receive
your data. AFAIK, OSCx accepts only UDP protocol.
you cannot use [tcpsend]/[tcpreceive] use together with [packOSC]/[unpackOSC], since there is a special OSC specification for stream oriented transport layers such as TCP. OSC assumes that either the transport layer takes care of the corrent handling of packets (which is the case for udp) and specifies a special header for OSC packets, when it is transported over a stream oriented protocol (TCP).
this makes the use of OSC over TCP much more complex. i made some abstractions for mrpeach to handle this correctly. here a little description about using them as intended:
OSC OVER TCP
for unidirectional TCP connections, use:
[packOSCstream] and [tcpsend] for the sender side and
[tcpreceive] and [unpackOSCstream] on the receiver side
for bidirectional TCP connections, use:
-on the server side: [tcpsocketserver OSC <port>] with [unpackOSC] for receiving and [packOSCstream] for sending
-on the client side: [tcpclient] with [unpackOSCstream] for receiving and [packOSCstream] for sending
(for the sake of completeness:)
OSC OVER UDP
for sending: [packOSC] with [udpsend]
for receiving: [unpackOSC] with [udpreceive]
i know, this sounds all complicated. actually i made those abstractions to get at least raw functionality, so that transporting OSC over TCP is possible at all. in order to make things less confusing and more obvious, i guess, i should add more high level abstractions, that contain the networking and un/packing stuff in once class.
roman
Thanx Roman for the clarification. I thought that [tcpsend]/
[tcpreceive] worked with OSC.
I think it must be specify somewhere in the help patch (with
[packOSC]/[unpackOSC] or/and [tcpsend]/[tcpreceive] ?).
I just download abstractions from :
http://romanhaefeli.net/software/pd/OSCstream.tar.gz
I will see that tomorrow.
++
Jack
Le 5 févr. 09 à 17:35, Roman Haefeli a écrit :
--- Jack jack@rybn.org schrieb am Do, 5.2.2009:
Yep, as Roman says try [udpreceive] with [unpackOSC] (OSC comme often 'on' UDP) or [tcpreceive] with [unpackOSC], if you want a service with connection. The choice depends if you absolutely need to receive your data. AFAIK, OSCx accepts only UDP protocol.
you cannot use [tcpsend]/[tcpreceive] use together with [packOSC]/ [unpackOSC], since there is a special OSC specification for stream
oriented transport layers such as TCP. OSC assumes that either the
transport layer takes care of the corrent handling of packets
(which is the case for udp) and specifies a special header for OSC
packets, when it is transported over a stream oriented protocol (TCP).this makes the use of OSC over TCP much more complex. i made some
abstractions for mrpeach to handle this correctly. here a little
description about using them as intended:OSC OVER TCP
for unidirectional TCP connections, use:
[packOSCstream] and [tcpsend] for the sender side and
[tcpreceive] and [unpackOSCstream] on the receiver side
for bidirectional TCP connections, use:
-on the server side: [tcpsocketserver OSC <port>] with [unpackOSC] for receiving and [packOSCstream] for sending
-on the client side: [tcpclient] with [unpackOSCstream] for receiving and
[packOSCstream] for sending
(for the sake of completeness:)
OSC OVER UDP
for sending: [packOSC] with [udpsend]
for receiving: [unpackOSC] with [udpreceive]
i know, this sounds all complicated. actually i made those
abstractions to get at least raw functionality, so that
transporting OSC over TCP is possible at all. in order to make
things less confusing and more obvious, i guess, i should add more
high level abstractions, that contain the networking and un/packing
stuff in once class.roman
On Thu, 2009-02-05 at 18:12 +0100, Jack wrote:
Thanx Roman for the clarification. I thought that [tcpsend]/ [tcpreceive] worked with OSC. I think it must be specify somewhere in the help patch (with
[packOSC]/[unpackOSC] or/and [tcpsend]/[tcpreceive] ?). I just download abstractions from : http://romanhaefeli.net/software/pd/OSCstream.tar.gz
this archive only contains [packOSCstream] and [unpackOSCstream], the other abstractions are missing. however, everything is in svn (externals/mrpeach), so please use those, since mrpeach accepted to include them and those are going to be kept up-to-date by me.
roman
Le 5 févr. 09 à 17:35, Roman Haefeli a écrit :
--- Jack jack@rybn.org schrieb am Do, 5.2.2009:
Yep, as Roman says try [udpreceive] with [unpackOSC] (OSC comme often 'on' UDP) or [tcpreceive] with [unpackOSC], if you want a service with connection. The choice depends if you absolutely need to receive your data. AFAIK, OSCx accepts only UDP protocol.
you cannot use [tcpsend]/[tcpreceive] use together with [packOSC]/ [unpackOSC], since there is a special OSC specification for stream
oriented transport layers such as TCP. OSC assumes that either the
transport layer takes care of the corrent handling of packets
(which is the case for udp) and specifies a special header for OSC
packets, when it is transported over a stream oriented protocol (TCP).this makes the use of OSC over TCP much more complex. i made some
abstractions for mrpeach to handle this correctly. here a little
description about using them as intended:OSC OVER TCP
for unidirectional TCP connections, use:
[packOSCstream] and [tcpsend] for the sender side and
[tcpreceive] and [unpackOSCstream] on the receiver side
for bidirectional TCP connections, use:
-on the server side: [tcpsocketserver OSC <port>] with [unpackOSC] for receiving and [packOSCstream] for sending
-on the client side: [tcpclient] with [unpackOSCstream] for receiving and
[packOSCstream] for sending
(for the sake of completeness:)
OSC OVER UDP
for sending: [packOSC] with [udpsend]
for receiving: [unpackOSC] with [udpreceive]
i know, this sounds all complicated. actually i made those
abstractions to get at least raw functionality, so that
transporting OSC over TCP is possible at all. in order to make
things less confusing and more obvious, i guess, i should add more
high level abstractions, that contain the networking and un/packing
stuff in once class.roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
IOhannes m zmoelnig -
Jack -
mbutubuntu -
Miller Puckette -
Roman Haefeli