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

Update: turns out enabling wifi on the iPad is not necessary after all! See this thread with various discussion throughout on the subject.

@esaruoho said:

Are you.... you're serious? do i really have to have wi-fi on, even if no wi-fi connection, for OSC to work over USB tethering?

Ha, well yes, I am serious! I was sharing the result of beating my head against this problem for 30-40 hours, in the hopes that others might not waste their time in a similar manner. It's entirely possible that there is a better & more reliable method to achieve this connection, I simply shared the solution that worked for me.

This post of yours is from 7 years ago, is this still the case in 2023?

In one of your other current threads I mentioned that I just tested this setup yesterday, and bi-directional OSC over USB is still working for me. Of course these are versions of TouchOSC/studiomux/midimux that I installed 7 years ago, it's entirely possible that there have been breaking changes in these apps since then.

it's a 100% dealbreaker. i don't want wifi on and don't need it for anything.

My solution was to carry a cheap mini wifi hub and just connect my iPad to its network; neither was connected to the internet (nor was my computer) and as far as I could tell no data was actually sent over the wifi network. Again, this was the only way I could figure out how to convince TouchOSC to send OSC over the USB connection. Maybe there's a better way, if you find it please do share your findings!

guess i'm stuck in MIDI over USB?

It did seem like wired MIDI connections were easier to set up when I did this in the past, and it sure seems like that's still an option. I went through the trouble to get OSC working because I'm lazy & grew tired of dividing/multiplying all control data by 127...

@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 I did something similar to what you're trying to do with TouchOSC, although in my case I was specifically using OSC rather than MIDI. It's been years since I've used this setup but here's my old post from when I was setting it up in case any of the info is helpful:
https://forum.pdpatchrepo.info/topic/10184/touchosc-direct-usb-connection-finally-possible-with-midimux

(tldr: I had to turn the iPad's wifi on for the USB connection to work)

Also, my experience was long enough ago that there could be much easier ways to do this nowadays. It looks like there's a new version of TouchOSC that I haven't checked out, so maybe there's an easier way in 2023?

@seb-harmonik.ar Thanks again!

For anyone else who's following:
https://github.com/pure-data/pure-data/issues/1823
https://github.com/MetaluNet/moonlib/issues/20

@seb-harmonik.ar Yes indeed, thank you! The Console app brought the crash report right up.

And I think I may have quickly found the likely culprit: mknob (from moonlib), which crashes if I bring up the help patch. If that's true, I wonder if this should be a bug report for the external itself (perhaps this repo?) rather than Pd? Or might it still be useful for the Pd devs to see this if other externals could also be broken due to a change in Pd 0.53?

One other question: when the time comes, what's the preferred format for submitting a crash log? Paste the entire thing into a Github issue, or is there a cleaner way?

@Load074 Similar (or same) issue for me on macOS Monterey, certain gigantic older patches of mine are crashing Pd 0.53 when trying to open. I've been doing a bit of initial research into how to generate a crash log (which I've never done & have no idea where to begin) for submitting a bug report to Github, but free time is a bit scarce at the moment. Any quick pointers for doing so are welcome!

The only initial thing I could think to do was to start Pd via command line... saw "segmentation fault" but no other clue about what the error might be.

@Metronome I probably experienced somewhere in the neighborhood of 8-10 headphone explosions when I was new to Pd, and possibly suffered some nonzero amount of hearing damage as a result, so I can very much relate to your question.

Ultimately I came to accept this as inseparable from the nature of Pd as a programming language, in that it gives you the raw tools to do pretty much whatever you like (including things that may not be advisable, either for your ears or your computer). Nowadays I always approach any unfamiliar patch (a help patch, demo from this forum, or anything whatsoever) with caution; I always take a look at what's going into [dac~] first, as many of my past unpleasant experiences came from patches where the author simply connected a number box with no defined upper limit directly into the right inlet of [*~] as gain control, meaning that if you mouse directly on the number box to turn up the volume (without shift-clicking), it's quite easy to slip & blast your ears in an instant.

For my own patch, I used zexy's [limiter~], which lets you specify an output limit in dB; you could make an abstraction which wraps such a limiter, and make sure to always add it in before [dac~] as a safety precaution in any patch you open. Or, when opening patches, just watch out for sketchy output levels before turning on DSP, and if necessary edit the patch first (perhaps [*~ 0.1] or [/ 100] or [dbtorms] may come in handy in these situations, if you catch my drift).

It is worth noting though that accidental volume spikes in general are certainly not unique to Pd, and keeping headphone/speaker volume low at first when checking levels is simply good practice with any speaker in any application.

@Kosmas Hi there, I haven't (successfully) used jack on Mac (I'm also on 10.15.7), but this is what I use to run Pd from the terminal:

/Applications/Pd-0.51-3.app/Contents/Resources/bin/pd /Users/*your*/*path*/*to*/*your*/patch.pd```

I also use several flags depending on what other options I want (-nogui, -channels, -audiobuf, etc.), maybe the -audiodev or -jack flags would get things working? I think I've seen some discussion recently on Pd-list/Github about jack & macos, and if memory serves, it isn't a simple solution...