HI all,

I've got a simple issue when trying to send messages from one computer to another over a WiFi network.

I have netsend and netreceive working a-ok when sending a bang, or a number. But I'm creating a very basic control interface, and so need to have muliple sliders/buttons/toggles working.

I'm a Max user, so previously would have used something like 'Prepend' to add a word to the start of the value, and then use this word at the other end to route the value to where it needs to go.

Sadly I can't figure out how to translate that knowledge to PD without installing externals (Find externals doesn't appear to be working...).

Can someone please guide me through this?

Many thanks -Todd AK

I'm using PD 0.47.1 on a Raspberry pi.

[oscformat] and [oscparse] are probably the droids you're looking for.

hjh

@toddak [netsend] and [netreceive] still work pretty much as they did in Extended, just the parameters have changed in Vanilla I think for udp tcp etc. formatting.
OSC messaging is a bit more difficult in Vanilla especialy because of a problem sending a float as part of the message header. The float arrives as a symbol and so cannot be routed simply.
Here are [netsend] and [netreceive] tests and an OSC patch that solves the float problem.......
It seems you are not using the OSC though.
Make sure the send is to a fixed IP address for the other computer, and use [list prepend] instead of [prepend] for Vanilla.
vanilla osc.zip
Upload the patch if you are still having problems.
David.

@whale-av Yep, you're correct, I'm not sending OSC in this instance.

And thanks for the patches, they work perfectly! Not sure what I was doing wrong, but I've got a distinct feeling it has to do with arguments for netsend.

While I have read the helpfile, can you explain to me in terms of 'PD for Dummies' why in this instance the arguement is -u? Just in the spirit of further learning

@toddak "While I have read the helpfile, can you explain to me in terms of 'PD for Dummies' why in this instance the argument is -u?"

A "listening" connection can be either TCP or UDP.

TCP is more robust but heavier-weight and a bit slower. It's a good idea if you need to send messages outside of a LAN, but not necessary if you're sending from one process to another on the same machine (and probably overkill within a LAN).

UDP is faster but slightly more fragile. I've seen it drop messages over a wifi LAN (but never to/from localhost btw) -- which makes it OK for something like touch controllers (if it's sending dozens of messages per second, dropping one or two won't be fatal) but not ideal when you need to be certain of successful transmission (e.g. large datasets split up into multiple packets, where you lose one packet and you're ruined -- TCP's handshaking is essential in that case).

For control signals in multimedia apps, usually UDP is enough.

hjh

@ddw_music Thankyou so much, that really clarifies things in real world terms!

Overall the patch isn't working still, and at the suggestion of @whale-av I've uploaded the patches here.

The idea is that 'backpack_control02' sends messages to the two other patches, botanic_left_02 and botanic_right_02.

The toggle box sends fine to both other computers simultaneously, but the sliders don't send at all. They're all just connecting over a local WiFi network.

Any ideas as to what might be the issue?

botanic_patches.zip

@toddak The sliders are sending correctly...... it works fine on localhost.
Maybe a firewall setting on the receiving computers? assuming you have the correct addresses...... connect 192.168.1.101 9001..... and connect 192.168.1.103 9001
Check that Pd has been allowed through the firewall for "private" or "local" connections on all the computers.
If you are running Windows a box would have popped up when you first ran Pd asking for that permission and maybe you clicked "no".

I don't know what the options in "firewall" "advanced" are on a mac, but at least the "Block all incoming connections" will need to be deselected for Pd.darwin.
David.

@whale-av The firewall idea is a good one, however that patch that you sent through, with the two sliders, works totally fine when working across the same WiFi network. So if that works am I right in thinking that that isn't the case?

I edited the original patch you send me (see attached), to control two computers and send the bang, and it seems to work fine! Argh...

It makes me think that it could be an issue with naming conventions in terms of naming my sends, and/or how they are interpretted by route. Is that a possibility?

I've attached the patches that are currently working, but I'd love to know why the originals didn't work still. As far as I can tell they are the same apart from naming conventions.

I did also change the sliders, sending values of 0-127 and then also 0-1, but I saw no difference there.

botanic_05.zip

@toddak Yes, you could be correct that starting the "symbol" "101vol01" with a "number" is confusing [route].
On my system it makes no difference, but it is the only difference between your patch and mine that I can see.
It's good that you have it working though.

You could see if the messages are going to the rightmost "rejection" outlet of [route] for your naming convention.
David.