@beep.beep - i'm running fully usb-tethered with all wi-fi bluetooth mobiledata off. can you have a look and see if this will solve your "OSC only works with wi-fi" issue?

@esaruoho Confirmed! Using your clues I was able send OSC over USB with wifi disabled. Nice to discover that my hacky workaround is no longer necessary! I’ve updated my other TouchOSC thread to point back to our present thread here, if there’s more to discuss on this subject please continue to do so here instead of replying to multiple threads, it makes it quite difficult for others to follow over time.

When I connected my iPad to my Mac & ran “arp -a” in the Mac’s terminal, I only saw one listing: the iPad’s IP address (unlike your screenshot, where you had many entries). This did enable me to at least send from Pd to TouchOSC, but since no IP was listed for my Mac I couldn’t send in the other direction.

Then — for reasons unknown — after fiddling with netsend/netreceive for a bit, “arp -a” then returned a 2nd entry for “broadcasthost (255.255.255.255)”. I’m not a networking expert but some quick searching indicates that this IP can be used to broadcast messages over a local network, so I tried entering 255.255.255.255 for “Host” in TouchOSC and voila, I can send to Pd! This also works the other way with “connect 255.255.255.255 9000” into [netsend -u -b], which successfully sends to TouchOSC on port 9000. I don’t know if there’s an efficiency downside to using a broadcast IP versus a direct IP, but if not this seems to simplify things a lot!

@ddw_music looking at your earlier comment, I didn’t know about netreceive’s -f flag either, that’s great to know! I tried your autoconnect logic and it works nicely, although of course it still requires the iPad to be configured correctly before doing its magic. I guess if there’s truly no harm in leaving TouchOSC’s host set to 255.255.255.255 and “broadcasting” all outgoing OSC data, maybe that’s about as close to zero-config as one can get?

edit: the above tests were done with a 2016 Macbook Pro and iPad 5th gen; when I tried these approaches with my much older 2008 Macbook and iPad 4th gen (both with older OS's) I did not succeed... so this all might be dependent on relatively recent hardware/software.

@esaruoho said:

and also feel a bit like there's no "TouchOSC with PureData for idiots" blog-post for iPad / macOS going on, or at least i haven't been able to find it.

As I mentioned in another recent thread of yours where you were exploring iPad control options, I had some experiences with this type of setup several years ago:
https://forum.pdpatchrepo.info/topic/10184/touchosc-direct-usb-connection-finally-possible-with-midimux

I just tested it & it's still working. (7 years later!) I have midimux & TouchOSC running on the iPad, and studiomux & Pd running on my Mac. As mentioned in my old thread, the iPad must be connected to wifi (any active network, doesn't matter which) in order to send OSC data over the tethered USB connection.

And yes, you will most certainly need to know the IP addresses of the Mac & iPad (for use with [netsend] in Pd, and with TouchOSC on the iPad). I don't know of a way to ensure that they will be persistent, I've always had to reenter them manually every time. Also make sure your in/out port numbers are in order (again, on the Pd side for [netsend] and [netreceive], and on the iPad you can set the in/out port numbers in midimux).

Ah, and finally I'm using [netreceive -u -b] into [oscparse] and [list trim] for receiving in Pd, and [oscformat foo bar etc] into [list prepend send] then [list trim] then [netsend -u -b] for sending out from Pd.

@lucassilveira You are using a multicast address...... With multicast the listener has to join the group.... so you need to tell [udpreceive~] to listen to that address range...... [udpreceive~ 3000 2 239.255.255.250]
Open [pd multicast] in the [udpsend~] help file. You will see that you can also specify that it will multicast on only the Wi-Fi or only the Ethernet connection from your computer, and set the "Time To Live" TTL to limit how far the packets will propagate on the network.
When you receive on the same computer you are already in the multicast group as the datagrams have been looped back by the OS (usually). All ports on the host are available for UDP without a connection, unlike TCP where a return connection is necessary and could be refused by the OS...

With a broadcast address the stream is broadcast everywhere, even to the internet, so insecure, and it will flood the network...... but then you do not need to specify a "listen" address for [udpreceive~] .... just the port is enough because every machine on the network will have the port open and will be receiving.
You only need multicast if you will have multiple receivers, but it will not flood your network as it sends only to receivers that join the group.... https://ipfabric.io/blog/troubleshooting-multicast-traffic-flows/
Broadcast will also be received at multiple end points, but if you will only have one receiver then sending directly to that receivers IP address will work....... and is better, for the reasons above.

I certainly needed to play around with the buffer size for [udpreceive~] to get reliable streaming over wi-fi.
Here are a send and a receive patch that work sending from my computer to a Raspberry Pi over wi-fi.
Obviously the IP addresses will be incorrect for you, but it might help.....
stream.zip
There are 3 possible [connect( messages in the send patch..... by computer name, by IP address, and a broadcast address 255.255.255.255.
David.

@lucassilveira said:

"netsend: no method for 'float'".

Which Pd version are you using?

I ask because of a note in the [netsend] help patch: "lists work like 'send' (as of Pd 0.51)"

This means: If you are using Pd 0.51 or later, you should be able to send a number directly into [netsend] and it will be transmitted.

I confirm that this works in Pd 0.52.2:

Now, note that all the other examples in [netsend] help use "send" messages, such as "send foo $1" toward the bottom:

That "as of Pd 0.51" means: if you're using Pd 0.50.x or earlier, then the only way to make [netsend] work is with the "send" prefix:

But... if you're using an old Pd version... why? Probably better for you to upgrade.

(Also assuming here that you will later use [netsend] to send data to another process -- if it's all internal to Pd, then [send] / [receive] are better.)

hjh

@oid said:

@esaruoho If you are trying to save CPU than I would just separate UI and DSP, run the UI in its own instance of PD and DSP in another, communicate between them with [netsed]/[netreceive], there comes a time in PD when you just have to either separate UI and DSP or sacrifice. Beyond that it is difficult to say, I do not know what your needs are and what sacrifices are acceptable. What are your requirements? I can optimize these patches in a dozen different ways but I have no idea if any of them will meet your needs since I do not know what your needs are or even why you are trying to change things beyond a vague notion of there possibly being something better.

ok. i have heard about this UI DSP separation. so.. is it a case of every single slider for instance needs to do a [netsend] to some other abstraction that only does DSP? or have two separate patches altogether, one for UI and one for DSP? sorry, i'm really vague on this.

So, my main painpoints with the current channelstrip is that when I set up 16 "LFOs" to "breathe" up and down the volume slider (which also has slider-color-changing while it is moved from 0 to 1) - when i have more than 4 of these LFO counters cycling from 0...1 on the channelstrips, all sliders stop updating. it might be 4, 8 or 12, but by the time i try to get all 16 of the looper volumes to cycle from 0...1 (my "breather" has a setup of cycling from "min-max every 2 seconds" to "min-max every 60 seconds") -- and that to me makes me think that the UI is not as optimized as possible.

i keep hearing that ELSE library supposedly has some larger crossmatrix/channelstrip that i could use, but i have not looked at it.

so ideally i'd prefer to take the channelstrip even further, i.e. have all effect sends be modulatable (well, that word where the effects have LFO modulation) so i could have even larger more complex things going on where the channelstrips that receive audio from loopers, are sent to specific sends like reverbs, delays and so on. this kind of larger modulation on all parameters would be really useful.

the way the channelstrip is built is that the dwL and dwR go to a separate [diskwrite~] abstraction which i use to record audio. the "p" (and p1-p8) defines that any channelstrip that has p enabled, is sending to all the other loopers - so in that case, any audio that goes to a channelstrip, can be sampled into the 64kb loopers (16 of them).

also i have thechannelstrip labels (i.e. volume slider name) dynamically written to, so i can always have them easily understandable / informative.
here's the "init state". i use bunches and bunches of loadbang -> message -> senders to get them to a specific state. .

one thing i've been toying around as an idea is to incorporate highpass and lowpass filters to the channelstrips, and EQ. but i haven't figured out how to solve the EQ issue so that the single band peak EQ could be incorporated into such a small formfactor ( the width is only 38 and height is 189 so it's hard to conceive how an EQ could be usable there).

i also have for the 16 channelstrip looper instances, BCR2000 + BCF2000 volume slider control and so on. but i'm willing to take the whole setup "to the dock" and rewrite it, if i could be sure that it will be lighter on the cpu..

so yeah, i do only have a vague notion of "maybe it could be better, i'm not sure?".. but i've not yet seen much netsend + netreceive stuff so i'm not entirely familiar how it could be done and how much i need to rewrite (i.e. does everything need to be netsend+netreceived with a complete split of DSP and UI, to reap the benefits, or can i just try it with the 16 loopers and see what happens?

Hi, thanks a lot for your help. It was very useful for me to understand the whole thing.
First of all, finding the "Broadcast address" is needed in order to reach all ips under the same router.
Finding the broadcast address can be done doing some maths acording to your own ip and the given subnet mask. These maths remain obscure for me but are explained here: [https://www.wikihow.com/Calculate-Network-and-Broadcast-Address
](link url)
Finally I used a calculator, this one: [https://jodies.de/ipcalc](link url)

Then, instead of the needed ip in the **connect **message, I put the given broadcast address followed by the port number and here you are! Worked perfectly!
Thanks a lot for your help @alexandros and @whale-av

note: I'm using oscx library, in my case

@markuc You can send data from Pd Vanilla to a network port....... TCP or UDP...... using [netsend].
The data can be in ASCII or binary format and there are objects for formatting messages to be sent for OSC as well..... and the port can be bi-directional.
You can also send directly to another program from [netsend] using the pdreceive binary that you will find in the Pd bundle..... called in Python for example.
You can also communicate through a serial port using [comport].
Have a look at the help file for [netsend]..... right-click the object for help.
Welcome to the forum...!
David.

@Load074 Since it takes so long you may want to just log all those prints externally. You can use the pdreceive command line application to send the data out of pd with the [netsend] object. So instead of connecting thing to various [print] objects you prepend a descriptive label to the data and then send that into [netsend]. Run pdreceive [port number] >> [logfile name] then send the [connect <port number>( to your [netsend] object in pd, and start the patch, everything gets send there. Then you can use a text editor or the standard command line tools to examine the text file after the crash, just control-c to kill pdreceive after pd freezes. Useful tools too examine the log will be things like tail and grep, tail -50 [logfile] will give you the last 50 lines of the log, tail -50 [logfile] | grep [label] will give you the last 50 occurances of all entries for [label]. Should make it much easier to decode the problem. The [trace] object could also be of use here. And there are a great number of other useful tools on the command line, any of the tools used for working with text files like cut and sort and the shells own scripting language, any good guide for your shell should help you here if you do not have much experience with shell scripting and the command line apps.

And time is relative, no need to wait an hour, speed up your control objects, if everything is under control of a master [metro] make it run 10 times faster and you will get your result in a tenth of the time. If you are logging it all to a file you do not need things to run slow enough that you can read them in the log window.

@nicnut 2nd question first.
You need to know the ip address of the computer you will send to....... so really, if you want your patch to work next year it will need a static address.
However, I think you might be able to replace the ip address with the host name.
Anyway, there is an example here........... https://forum.pdpatchrepo.info/topic/10136/netsend-netreceive-os-x-pd-0-47-0/2 with [netsend] in udp mode.
But you can broadcast also with [netsend].... see below.

1st question.
[udpsend] is available for Pd but you need to install either the MrPeach library or the iemnet library or the net library.
It has multicast but for broadcast you can use the reserved broadcast address for your network.
And you can do the same with [netsend].......... https://forum.pdpatchrepo.info/topic/11062/cannot-connect-to-broadcast-ip-on-linux-via-netsend
David.

Hi,

Just curious about this. In Max there is an object called udpsend that allows you to broadcast messages to any computer on the wifi network running max.

Is there a way to do this in Pd using [netsend]?

Also, if I wanted to communicate with another computer using netsend how would i go about configuring the object on the sending and receving side? I've only used netsend internally on my computer to communicate with other applications.

Thank you. Nick