@LL1 and @oscarsantis - I just got my remote netsend working with ngrok - it wasn't too hard to set up in the end! As an example of what you get when you run ./ngrok tcp 4000 is Forwarding tcp://2.tcp.ngrok.io:15524 -> localhost:4000 - this gives you the clue to what you then need to setup on your 'netsend' on your remote pd patch (with you local simply setup with 'netreceive 4000' ). So then on your remote, the message box coming in to 'netsend' wants to read 'connect 2.tcp.ngrok.io 15524' (ip and port number respectively).

I tested this with one laptop connected to my wifi, and with another connected to a mobile phone running a 4G hotspot. The next test it too see if it works with someone in Japan! Hope this helps

Hi guys, so I manage to get rid of the "output snd_pcm_delay failed" error by running pd with Jack. It doesn't do anything for the CPU, still got my four cores running at 50%. I did some profiling on groovebox 2 and my first my frist version of the "fork" I was working on and I notcied that I didn't get any vfprintf calls, so the problem doesn't come from neither martin Birkmann patch or my first tweaks on it, but only from the implementation of pd~. Since the vfprintf isn't due to the alsa error message, it must be something else. It's not the synth of the patch or the mixer and fx that works well somewhere else. Then the only thing that are remains in this audio processing patch is the following : an object that permits me to get all the value that come from my GUI patch via netsend/netreceive and another object which take the value received via netsend to then them with a message to the pd~ object.

My netsend/netreceive object seems to have worked fine until now I didn't notice any CPU issues when using it. The other object maybe the source of the problem, thoough it's strange because the value that I send from the GUI are sent properly to the audio processing patch. So I'don't know what to do. Should I pack an archive of my code and put it here so you could have a better idea of whats going on ?

@elcraydo You should use [oscformat] and specify a float in the blob using the message [format f(
which must of course be specified before the blob is sent.
You must then use the -b switch for [netsend]
https://forum.pdpatchrepo.info/topic/11226/netsend/23

Using the old [sendOSC] it might work if you send the message [typetags 0( into it, and specify the incoming float eg........ [float 1.2( ........ although that should not be necessary.
It could be that processing does not support typetags or there is some mismatch with [sendOSC]?
[packOSC] and [udpsend] from MrPeach used to work well.
David.

@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

Hi,
i have some problems with the netsend~ and netreceive~ objects from Remu. I'm using pd extended 0.43.4

I build two patches (client and server) for voice communication with several abstraction using dollar signs etc..
The first patch (client) records audio on 8 channels with the [adc~] object after pushing a Press-to-talk button (PTT) and sends this signal with [netsend~] to the second patch (server). This second patch checks some conditions and sends the signal to other clients. The client receives the signal and sends it to a [dac~] object.
In the beginning of this project I connected everytime I pressed the PTT and disconnected when I released the PTT. Pressing the PTT and connecting caused often errors from [netsend~]:

• (Tcl) Invalid Command Name " " while executing; with different commands inside the "". Sometimes it was a part of the IP-Adress, the port, parts of other words like "ted" from connected or something different
• Sometimes I got the Tcl error: bad option " itemconpdtk_text_set": must be addtag,bbox,bind,canvasx,canvasy,cget,..... while executing

The results of this errors where a frozen GUI (number boxes and Sliders didn't change) or pd crashed.

• (Tcl) missing close brace while executing. After this errror I had to kill Pd because nothing worked anymore...

I couldn't find the reason for the errors so I changed the patches. Now [netsend~] connects directly when the patch opens. But sometimes the "invalid command name" error appears anyway and the GUI freezes, so I had to restart the patch.

Another problem is an error from the [netreceive~] object while sending an audio signal over the network:

• recv data: message too long (10040) or recv tag: message too long (10040)
  it is independent of the chosen format or blocksize. Everytime it happens the sound interrupts. It's not that bad, but sometimes there comes a block of errors and the sound interrupts for a hole second or more, which is disturbing.

So I hope someone understands what i wrote and maybe someone had similar problems.

Tanks for helping.

@alex.vyverman You just need to send and receive (tcp or udp) using [netsend] and [netreceive] objects and specifying the port on the Rpi that you want to use to receive the data. If you are using extended then look at this..........
02.netsend_netreceive.pd
which is in the "pd/doc/manuals/networking" folder.
If you are using vanilla open........ [netsend-help]
netsend-help.pd
which is in "pd/doc/5.reference"
David

@toddak Tehe..... routers as well.....
First, a question that I should not ask...... but I have to....... Have you "joined" the new routers' network before trying to access it. It cannot "join" your home network.... sorry to ask....... but it is a completely new and separate network!........
Probably definitely best to do a total reset of the Linksys (especially as you cannot talk to it and you have no idea how it was set up by the previous owner).
Power it up and press the reset for 30 seconds and keep it pressed while unplugging the power.
Now keep it pressed for 30 seconds and keep it pressed still for another 30 seconds after you plug the power again. Now it is "factory reset"
It's address will be 192.168.1.1 OR 192.168.0.1
It will pop up as the network "Linksys".
Its username when you get to the login is just blank..... no user name, and
the password is: admin
If that doesn't work you will have to google a bit.

Here is how you can send more parameters over [netsend]. I recommend [netsend 1] as tcp can crash Pd if the connection is broken. udp does not actually make a "connection". It just broadcasts to only one port at one ip address, so if the information is not received it doesn't know and doesn't care. It is safer (for Pd).
send x2.zip

You can add as many list headers (like the "param1") as you need, or change them to "whatever".

Osc is not "special" but works in exactly the same way. Header "paths" for osc are slash delimited........ more about that later if you need it! But you only need osc if you are planning to use external controllers (like TouchOSC) or send to things that require an osc message.................

David.

Just a demo patch showing how to use [oscformat] and [oscparse]. The arguments of [netsend] and [netreceive] (-u -b) stand for a UDP connection and binary format, respectively. -b is necessary for [oscformat] and [oscparse]. If you need a TCP connection then just omit the first argument in both [netsend] and [netreceive].
The message to [netsend] should contain the receiver's IP instead of "localhost".
oscformat_parse_usage.pd

Hey guys,

It's a super old post but since the netsend~ and netreceive~ are old as well I thought to add my 2 cents here.

I ran into similar problems connecting a Linux desktop to a Raspberry Pi with netsend~ and netreceive~. My desktop cpu (x86_64) and the ARMv7 of the Raspberry have different word lengths (64bit vs. 32bit). The problem is that the header tag uses long datatype for the members count and framesize, which the compiler maps to the word length of the current architecture. Thus, the send and receive ends of the transmission interpreted a different sized header tag, causing strange error messages about too many channels and incompatible header size.

To fix it, I simply edited the file netsend~.h and changed the datatypes of the members from long to unsinged int (or to something that is guaranteed to stay as standard size like __u32 just to make sure). I also wonder if the array extension is necessary because if you order the larger datatypes first, the compiler seems to pad the overall size of the struct to 12 in both 64 and 32 bit machines.

typedef struct _tag {       /* size (bytes) */
    __u32 count;            /*    4         */
    __u32 framesize;        /*    4         */
    char version;           /*    1         */
    char format;            /*    1         */
    char channels;          /*    1         */
    //char  extension[5];   /*              */
} t_tag;                    /*--------------*/
                            /*   11         */

Btw, does anyone know if there is a more updated version of netsend~ and netreceive~ available since the 1.0b by Remu?