thanks very much everybody! this is quite helpful. at the moment i'm not requiring a bi-directional communication - i'm only using [netreceive -u -b] and not [netsend]. but it is very good to know of this behavior, because at some point i'll likely want some sort of way that PD can tell the application information for callback or verification purposes.
@ Michael (or whoever want to use Unity with PD in a network configuration)
- i have tried numerous (about 5) Unity - OSC solutions. many if not most
do not obviously seem to have iOS or Android build support, but only work in the Editor. the one with the most depth and capability for build support (not to mention numerous example scenes) that i've encountered is extOSC, available on the Asset Store for free and of course downloadable via Github: https://github.com/Iam1337/extOSC
i started in TouchOSC and then went to Lemur, but ultimately i needed a completely customized interface that neither tool could work with involving manipulating 3D objects. plus i've had a lot of experience dealing with Unity and none at all in Lemur. depending on your needs openFrameworks might be a better choice, esp for 2D interfaces. but if you want game controller or VR device support or using a 3D interface, i think of Unity as better optimized, certainly with better Metal support than oFX.
@everyone re: the [netsend -u -b] bug. if and when i do use this i will be using a different port number than the port i'm using for [netreceive -u -b], but this seems to mean that if PD sends UDP data back to Unity in this manner then do i need to reopen the connection to that port every time i send data?
i did have a fair amount of issues getting OSC to work properly - either PD or Unity would tell me the IP was already in use or Sockets.Net in Unity said the connection was refused. i did find out that the majority of errors were caused in Unity by the toolkit using the same port for sending and receiving. making them different port numbers helped immensely, but getting the port assignment to be forgotten about was a bit tricky and i'm still not 100% sure i've solved it. certainly i would say that [netreceive <portnumber> -u -b] does not seem to work as reliably as sending a [listen <portnumber> ( message at loading or via manual triggering, so i'll likely add a button or something to make sure the connection is solid.
@Dan - i'll look into your rc vanilla abstraction solutions - thanks!
best, scott
On Sun, Feb 10, 2019 at 8:49 AM Christof Ressi christof.ressi@gmx.at wrote:
i think roman made an error report about this [netreceive -u -b]
beahviour already.
https://github.com/pure-data/pure-data/issues/373
Gesendet: Sonntag, 10. Februar 2019 um 15:36 Uhr Von: "michael strohmann" itsnotfair9@gmail.com An: "Scott R. Looney" scottrlooney@gmail.com Cc: PD-List pd-list@lists.iem.at Betreff: Re: [PD] trying to set up OSC between Unity and PD via
[netreceive] or [iemnet/udpreceive]
HI Scott, i do a similar thing - send OSC from the LEMUR app to pd and vice versa. Lemur sends osc and to receive it in pd works fine with [netreceive -u -b] | [oscparse] | [list trim] | [route whatever the message]
there seem to be a odd behaviour with [netsend -u -b] though. according the UDP protocol a message should be broadcast to an IP adress
regardless if the receiving end is actually listening.
this bi-directionality is redarded only with TCP.
however, in [netsend -u -b] once the receive leaves the network the
connection is closed, and you need to reconnect to the device in order to send messages.
so i connect to the device every second, to make sure that it receives
messages upon re-entry to the wlan-network
(i also need to send the status of the patch on a regular basis, so that
all devices are up to date…)
my patch (quite simple file playback in response to sensor input) worked
fine, but i had occasional crashes / freezes with “watchdog singaling pd” (i run pd-0.48 on RaspberryPi B+)
since pd writes “connecting to port “ to the console everytime i connect
- which is every second - after a couple of hours/days is filled the RAM
and caused some misbeavior.
the solution - and i hope it really fixes the freezes also in the long
run - was to send the standard error to dev/null like so:
puredata -stderr 2>/dev/null path/to/patch.pd
i think roman made an error report about this [netreceive -u -b]
beahviour already.
i actually also wanted to use UNITY for sending OSC, but could not find
time to work it out, so pls let me know it you found how to do it…
Cheers! Michael
On 10 Feb 2019, at 10:56, Scott R. Looney scottrlooney@gmail.com
wrote:
OK thanks Christof! [oscparse] seems to do the trick, and formats it
as a list that i can break up. and it seems i have [netreceive] working properly after all, so that was my error thinking it was broken. it is a bit picky and seems to work better if i send it a message as to what port to listen to rather than defining it as an argument initially.
On Sun, Feb 10, 2019 at 1:03 AM Christof Ressi <christof.ressi@gmx.at
mailto:christof.ressi@gmx.at> wrote:
patch with their [udpreceive] which worked fine. trying that same patch in PD however, made all the data print out as integer ASCII values rather than Unicode text characters. i tried two other
Unity
OSC projects and they behaved the same way.
so, at the least, i need a convenient way to change all the ASCII integer numbers in a data stream to ASCII characters.
IIRC, in max, updreceive outputs osc messages while in the Pd objects
iemnet/udpreceive or [netreceive -u -b] output the raw udp packet as a list of bytes. You need another object to parse the data. Pd vanilla has [oscparse], but personally i prefer the mrpeach/unpackOSC resp. osc/unpackOSC externals.
Gesendet: Sonntag, 10. Februar 2019 um 09:39 Uhr Von: "Scott R. Looney" <scottrlooney@gmail.com <mailto:
scottrlooney@gmail.com>>
An: pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Betreff: Re: [PD] trying to set up OSC between Unity and PD via
[netreceive] or [iemnet/udpreceive]
nope - doesn't work. absolutely no output at all from [netreceive -u
-b]
whereas i do get results from [iemnet/udpreceive]. i'm pretty
convinced
that on the Mac anyway the UDP functionality of [netreceive] is
basically
broken, at least in regards to responding to .Net's Sockets UDP
sending
methods anyway.
On Sun, Feb 10, 2019 at 12:20 AM Roman Haefeli <reduzent@gmail.com
mailto:reduzent@gmail.com> wrote:
The equivalent to [iemnet/udpreceive] is [netreceive -u -b].
Roman
On Sat, 2019-02-09 at 23:40 -0800, Scott R. Looney wrote:
hey folks, i'm trying to set up a OSC communication between
Unity and
PD. the eventual goal is that an iOS app will be sending data to
PD
to control various parameters. this isn't a libpd issue as i do
not
want to run a PD patch in Unity. i only want the remote communication.
so far i've tried Kalimba which works perfectly with
[netreceive] in
the Unity Editor. it looks like this is because it uses TCP and
not
UDP for its connection. however due to its age (6 years or so)
the
resulting Xcode project does not build correctly. i'm assuming
it's
likely an old libpd issue, but not sure.
so, i've tried a few other OSC Unity based projects and none of
them
work with [netreceive] in any way (including in UDP mode). i did
find
a few that work with [iemnet/udpreceive]. one of them had a demo
Max
patch with their [udpreceive] which worked fine. trying that same patch in PD however, made all the data print out as integer ASCII values rather than Unicode text characters. i tried two other
Unity
OSC projects and they behaved the same way.
so, at the least, i need a convenient way to change all the ASCII integer numbers in a data stream to ASCII characters. ideally i'd love to have a Unity OSC demo that can send data to PD reliably, using TCP or UDP. any help appreciated! _______________________________________________ Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <
https://lists.puredata.info/listinfo/pd-list%3E
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list <
https://lists.puredata.info/listinfo/pd-list%3E
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list < https://lists.puredata.info/listinfo/pd-list%3E
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list < https://lists.puredata.info/listinfo/pd-list%3E
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list