Hallo good people
I have already searched the relevant forums, and the TouchOSC manual but I am still struggling to get OSC data into Purr Data.

I am able to successfully parse OSC data from, for example, Sonic Pi into PD (via localhost) on the same machine. I have recently installed TouchOSC on my Android tablet, and installed Protokol (network messaging monitor) on my MacBook. All the OSC messages from TouchOSC (tablet) show up inside Protokol (MacBook), but [netreceive -u -b], [listen 800( in PD shows nothing. Do I need to tell [netreceive] where the OSC data is coming from (the connect 192.x.x.x message doesn't work)?

I'm afraid terms like Host, Client, server etc mean nothing to me, so is there a step by step guide out there for my issue please?

[EDIT] Muppet - I had to close Protokol!! All working fine now. Told you I was a n00b :D
<3
Brendan

In the PD patch provided with the script you should have a [netreceive]. It has to be trigger in order to listen at the port the py script attempts to send to.
See [netsend] and [netreceive] help.

EDIT: for ref, the py script come from https://github.com/eoinfennessy/webcam-theremin/

@whale-av said:

I am almost certain that Gui objects in TouchOSC can talk midi and OSC at the same time.
But I doubt that it will communicate over wireless (required for OSC messages) and USB at the same time.

GUI objects in TouchOSC can send Midi and OSC at the same time, and wired USB connection does work for both, no issues. no need for having the iPad on Wi-Fi. just takes a while for TouchOSC on the iPad to realize what the IP address of the laptop is.

The communications between Pd and touchOSC are set in the abstraction [osc-s-r] within the [globpitcharray1] patch in the zip I posted.
There is a TouchOSC layout plom.touchosc in the zip that should be used with this patch (for a test demo).

thanks for breaking this down for me!

You would need to fix the IP address of the Ipad (static address) and use that address for [netsend] and [netreceive] in [osc-s-r] ....... if you ever get over your fear of using Wi-Fi for this.... or just feel like trying it to see what it will do.......

yes, [osc-s-r] is definitely where it's at. thanks for spelling out the [netsend] and [netreceive] to me, cos looking at the screenshot i had, i can now realize where to input 11000 and 11001 for send + receive. the connect portion of the script was throwing me.

i hope i have it right now,

@zerino You need a patch open with a [netreceive] object in it and connect the left outlet to a [s pd] like,

[netreceive 3000]
|
[s pd]

Then from the command line you send a command like echo open filename.pd $(pwd)\; | pdsend 3000 and it will open filename,pd, this assumes you are in the directory which the file is in, the $(pwd) command can be replaced by a path. You should be able to setup your file manager to do all of this automatically but I am not familiar with if, or an alias in your .bashrc or the rc of whatever shell you use, for bash alias pdopen="echo open $1 $(pwd)\; | pdsend 3000"

Edit, we can not actually use an alias like that in bash, but we can make that a function, just put this in your .bashrc instead of the alias. Need to run source ~/.bashrc in any open terminals or logout/log back in for it to be usable. Then just run pdopen <filename> and it should work.

function pdopen () {
   echo open $1 $(pwd)\; | pdsend 3000
}

@whale-av yes, copying a selceted file in win-file-browser does full path in clipboard...

I think sending via pdsend is slick. And I believe and hope and am interested in if Pd receives it without [netreceive].

Otherwise, opening a [netreceive] patch with a startup-flag (in terminal or preferences or in a script) should do the trick:
https://forum.pdpatchrepo.info/topic/13895/opening-a-patch-inside-another-patch-by-filename/2

@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.

@whale-av said:

@esaruoho OSC is horrible in Vanilla..... because message headers are symbols but can include numbers that Pd interprets as floats. It is much easier to use the MrPeach externals.

Anyway...... vanilla....... plom.zip using a multifader object.
The index currently played by metro turns green.....
David.
Low-res screenshot.......

ok, so now that i have UDP working, what specifically do i need to modify in plom.zip for the [netreceive] to be patched onto it? it seems that the PD script example you provided does not have anything related to [netreceive] or [netsend] .

@esaruoho said:

I could try again, but it looked like UDP required me to know the IP address of both the laptop and the iPad, and that really threw me (i don't know how to figure out what the IP address of the iPad is, or how to make sure it's always the same, same for macOS).

Ah right, for bidirectional communication.

Actually in the netreceive help file, there is a flag for this: "optional -f flag for from address & port outlet (0.51+)".

Help file example prints from: list ::ffff:127.0.0.1 57120 where ::ffff:127.0.0.1 is an IPv6 address.

So...

... should configure the [netsend] to send to the first address from which messages were received (and I did a quick test, which worked). If you enable "Ping" in TouchOSC, then it will automatically send a message to the computer, which will trigger the "connect" logic right away.

Incidentally, I didn't know about this feature (never used the "from" address in Pd). My thought process was, "Well... this is a very common requirement, so let me have a look at the [netreceive] help patch and see if there's anything about 'from'" -- and toward the lower right, there's a [print from] box. Hm. Then, what's different about the [netreceive] feeding it is that it isn't only "-u -b xxxx" but rather "-u -b -f xxxx"... what's that "-f"? Then, looking up from there a little bit, there's a list of object creation flags, where "-f" is explained.

So the solution exists, and documentation for that solution is actually reasonably clear.

i have maybe an hour every 2-3 days to try and get something going, 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.

This I fully understand.

Pd OSC sending, like this. It won't send anything until after you push a connect ip.ad.dr.ess port message into the netsend inlet -- as noted above, you can get the parameters for the connect message from [netreceive].

... producing messages like /1/toggle1 1.0 or /1/toggle2 0.0. This type of message format is what you need to change a control's value on the tablet.

It's also possible to "set" the OSC command path before providing the arguments -- but try the simple way first.

hjh

@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.

@esaruoho You will need to select UDP client........ not TCP...... to connect to [netreceive -u -b]

Fifo (first in first out) overflowed probably just means the buffer has filled to overflow as it is not managing to send the messages onwards.

For TCP then use [netreceive -b] ...... remove the -u....
David.