@Booberg No you can open at least 64 ports..... maybe more..... so....
[netreceive -u 10000]
[netreceive -u 10001]
..
..
..
[netreceive -u 10063]
and their corresponding [netsend -u] in the control patch.

10000 to 10063 are the port numbers and it is best to make them big.
25 would clash with email for example.
But what do you mean by controller values at audio rate? Do you mean 192000 messages / second ........ or sent as audio signals?
David.

Hi folks!
I reached this thread because I had the same problem: there were no way to receive OSC messages in PDparty. I was sending a simple bang from Isadora, just for test purposes, and it works fine on PD on my Mac (sending to locahost), but does not work sending to my Iphone IP. I was sure that the OSC were issued corrected, cause I can see them on Isadora OSC monitor.
Finally I found the problem was a conflict between the OSC incoming port in PDparty (Iphone) and de OSC port that the patch is lisent to (specified in a message to netreceive). If this one (in netreceive) is the same that the one in Port incoming (PDparty), you get in the console this error "error: blind: Address already in use (48), and the patch in PDparty do not receive OSC messages. I changed the OSC incoming port in PD settings, and the patch is receiving OSC messages to the port specified in [lisent] and [netreceive].
I attach my test patch (just play the sound file "cascabel" from the bang button or from OSC (send "/toggle1 1" to port 4321 to the IP where PDparty is running).
Hope it is useful for somebody. I was stuck for hours finding the reason for no receiving OSC
Regards
Daniel
TEST_PDparty.pd cascabel.wav

@Jona Good to see it working!
Yes, generally netsends and netreceives have matched ports (one port only).
For comms with verification of receipt (tcp) it is vital.
But for udp you can "broadcast"...... much like streaming internet radio.

So you could have all your [netreceive] objects as [netreceive 3001 1] and broadcast to your router the [netsend]
So, on my network the primary router address is 192.168.1.1
That is the address that will serve up its web-page. Often referred to as the "gateway".
Its broadcast address will be 192.168.1.255
255 is reserved specifically for this purpose so......
[connect 192.168.1.255 3001( will set [netsend 3001 1] to broadcast to any/all copies of [netreceive] listening on port 3001 on any computer on the local network.
If that is what you want?
David.

don't know where that coma is coming from as it is not part of the original message.

here is a simplified version. oscform.pd

i am at this point using packOSC with netsend
and comparing it to oscformat with netsend

and trying to figure out how the message is being formatted differently by those two objects.

The actual patch is sending tuio messages to another source. (part of which you helped me with a while ago.)

but i am also using netreceive and oscparse to try to gauge what the differences are.

for some reason when sending with oscformat the message that arrives in oscparse keeps the / slashes but not when sent from packOSC.

netreceive-oscparse from packOSC-netsend
print: list tuio 2Dcur source localhost
print: list tuio 2Dcur alive 2
print: list tuio 2Dcur set 3 0.145 0.227 -5 -5 -16.8504
print: list tuio 2Dcur fseq 6

netreceive-oscparse from oscformat-netsend
print: list /tuio/2Dcur source localhost
print: list /tuio/2Dcur alive 2
print: list /tuio/2Dcur set 3 0.745 0.807 -5 -5 -16.8504
print: list /tuio/2Dcur fseq 6

Hey,

I'm doing some basic testing using python to send values to pd using the pdsend and [netreceive]. I'm doing all this inside my Raspberry Pi, with the hope of expanding on this to use the GPIO with some sensors to control a Pd patch.

So, I've made a basic python patch: send2Pd_test.py that sends some dummy values to this pd patch: Netreceive_Test.pd

The values are received when I do this. But I get a "EOF on socket ##" message in the Pd Terminal window along with my printed values from netreceive.

This is my first time using [netreceive]. I'm just wondering if this is normal behaviour or if it's something that I should try and fix before continuing further. I also would like to know what it is I need to fix because everything seems pretty standard from what I've done so far.

Hi all,

On windows MobMuPlat pdwrapper.pd [netreceive -u] doesn't work on Pd-exended when I add the -u flag.. When I try this on a Ubuntu machine it does work and [netreceive looks like a different version. Is there a work around to get [netreceive -u] working on Pd exended on a Windows Machine so that Pdwrapper.pd works on Windows?

Thanks

@Dannielo If you get a solution that works please let everyone know by posting in this thread.
To get you working in the meantime.........

You could just use [netreceive] for data..... you don't absolutely have to use osc.
If you want to use osc there are objects in Vanilla that work....... [oscparse] and [oscformat]

However there is a bug in [oscparse] if you use an integer in the message address (not the data of course!).
There is a solution for that bug included in this zip, as well as a demo of [netsend] and [netreceive] for vanilla.
vanilla osc.zip
And for Python...... to send to [netreceive]......... https://guitarextended.wordpress.com/2012/11/03/make-python-and-pure-data-communicate-on-the-raspberry-pi/
David.

Hi whale-av, thanks for your reply. I managed to get this up another way a couple of months back, but now I'm back making an updated version. I ended up using pd-extended last time and so found that [tcpreceive] work well. However now I am using Raspian Jessie and Pd Vanilla 0.46.2 I cannot use that object any more.

What you said makes sense I am now attempting to use a [netreceive 8010 0] and then using curl to route my data to the same port (8010). This worked with [tcpreceive] in Extended but I couldn't get it to work with [netreceive]. It still isn't working with [netreceive] now.

I know I have some work to do to separate out the data stream once it's coming through but at this stage even connecting [print] to [netreceive] yields no data. Curl (in my terminal) is acting like it's running and connected, for example if I run the curl scrip without running the Pd patch and building the [netrecieve] first the curl doesn't connect (as you explained before).

Do I need to be doing something to somehow "wake up" [netreceive] to receive the data? If so I can't find it in the documentation. Any suggestions would be very much appreciated.

Hi everyone,

I'm glad to announce we've finally release the new version of n-Track Studio with Pd patch support.

Here the user guide to know about using Pd in our DAW:
http://it.ntrack.com/help/manual.html#pure-data-for-ntrack

Don't hesitate to contact us for any problem or suggestion!

HI Everyone,

I’m one of the developers of n-Track Studio, a cross-platform Digital Audio Workstation available for Mac, Windows, iOs and Android (www.ntrack.com).

The new beta version of n-Track Studio 8 now include a new VST3 to allow to load and use Pure Data patches inside the workstation.
The VST3 is based on libpd and it's included in both Mac and Windows version.

If you want to test it and I have prepared a temporarily FAQ page to help user to create compatible pd patch and test them in n-Track Studio:
http://en.ntrack.com/faq.php?category=13&showAll=1

I hope you’ll enjoy our project to make a new tool for the Pure Data community and every feedback could be useful!

Marco