@beep.beep said:

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.

Yeah, this is nightmarish. When i'm jamming with my friend or playing a gig, I don't want to have any Wi-Fi on at all, so if OSC refuses to work via USB-tethering unless if there's a Wi-Fi connection on, I cannot use it and will stop thinking about it. (We gig at libraries, and one can never know if there will be a stable enough Wi-Fi connection, and I am not connected to anything at all during the gig to make sure there's no notifications and other such stuff that could detract from the focus. So no network connection and no internet apps at all)

Maybe there's a way of accomplishing what I want to accomplish via MIDI only, and never use the OSC aspect of TouchOSC.

well at least it's less of a birdsnest now, but i have a feeling that this should be done in a better way.

FWIW I eventually bought a cheap WiFi router to use only for shows (not only for the tablet controller, but also for Ableton Link if it's a group jam). Only the players know the password (no extra traffic) and I never attach an Ethernet cable, so no outside traffic. The device is under my control, so there's no more "venue's WiFi is unreliable." (One recommendation btw is to turn off discovery on this router, so that the audience's phones never even know it's there.)

Android used to allow tethering without a live internet connection. My current devices don't allow that, which is just a mind-blowingly stupid evolution (but shows you that the purpose of these devices isn't creative, it's to get you to spend more money more quickly -- "why, if it's not online, then... we just can't imagine any purpose for that"). If iOS never allowed it, then

hjh

Btw did you notice in your MIDI patch that cc 41 maps onto index 0, and cc 42 onto 1, and 43 --> 2, and 44 --> 3, up to 56 --> 15... meaning that you can delete the whole rat's nest and do:

[ctlin]  (without a cc filter)
|   |
|   [- 41]
|
[* 0.787]
etc

Looking for patterns can save a ton of manual labor.

hjh

@ddw_music said:

For iOS: https://support.apple.com/en-gb/guide/iphone/iph45447ca6/ios

Connect a Mac or PC to your Personal Hotspot
You can use Wi-Fi, a USB cable, or Bluetooth to connect a Mac or PC to your Personal Hotspot. Do one of the following:
...
Use USB: Connect iPhone and your computer with a cable. If you receive an alert that says Trust this Computer?, tap Trust. In your computer’s network preferences, choose iPhone, then configure the network settings.
...
After that, the Mac should have an IP address that directly connected to the mobile, through the cable. There's no reason at this point TouchOSC would be prevented from sending and receiving OSC messages (while allowing MIDI...? that doesn't make any sense).

Hmm. Thing is, I'm using a fully Airplane Mode iPad with no Wi-Fi, Bluetooth, Cellular Data connectivity. I'm only using a USB-cable to connect between macOS and iPadOS with TouchOSC - so I'm not 100% how Personal Hotspot -specific IP addresses will assist.
overall it seems like there just might not be a netless-USB-tether way of identifying what the iPad's IP address is. all the stuff i see, is about using the iPad as a personal hotspot over usb-cable, and therefore having an IP address to connect PD onto for OSC back'n'forth communication.

@ddw_music said:

Btw did you notice in your MIDI patch that cc 41 maps onto index 0, and cc 42 onto 1, and 43 --> 2, and 44 --> 3, up to 56 --> 15... meaning that you can delete the whole rat's nest and do:

[ctlin]  (without a cc filter)
|   |
|   [- 41]
|
[* 0.787]
etc

Looking for patterns can save a ton of manual labor.

hjh

that is pretty sweet! unfortunately, here my problem is that i need this to only be happening if it is coming from a specific midi-port.
to show my current TouchOSC nightmare, it is currently like this:

so i cannot simply go "sure, everything 41-56", because i'm using it in multiple places. i need to only be catching ctlin 41-56 coming from midichannel 6, otherwise i'll be catching all kinds of un-related stuff.

so while the [- 41] definitely would assist, the required logic is to discard anything 41-56 that isn't coming from channel 6.
if that can be easily solved, that'd be pretty hot!

continuing with OSC:
there's apparently this command arp -a that i can run on the terminal
i get a list of bunches of IP addresses, then when i move a slider on TouchOSC, the iPad-specific IP appears:

$ arp -a
? (10.0.1.1) at f0:99:bf:0:c2:5c on en8 ifscope [ethernet]
? (10.0.1.2) at 3a:69:f1:6f:e7:a4 on en8 ifscope [ethernet]
? (10.0.1.6) at (incomplete) on en8 ifscope [ethernet]
? (10.0.1.8) at 64:4b:f0:13:9d:b7 on en8 ifscope permanent [ethernet]
? (10.0.1.15) at (incomplete) on en8 ifscope [ethernet]
? (10.0.1.255) at ff:ff:ff:ff:ff:ff on en8 ifscope [ethernet]
? (169.254.7.238) at (incomplete) on en8 [ethernet]
esaipadmini.local (169.254.68.27) at c6:b:31:36:6b:a6 on en12 [ethernet]
esasoftabilitym1.local (169.254.168.156) at c6:b:31:40:41:93 on en12 permanent [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en12 ifscope permanent [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en8 ifscope permanent [ethernet]
broadcasthost (255.255.255.255) at ff:ff:ff:ff:ff:ff on en8 ifscope [ethernet]

so armed with this knowledge, i went in and did

and

and then ..

it works!! it.. works!!!!!
and @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?

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

so while the [- 41] definitely would assist, the required logic is to discard anything 41-56 that isn't coming from channel 6.
if that can be easily solved, that'd be pretty hot!

[spigot] blocks messages if its right inlet is 0.

One of the ctlin outlets gives you the channel number (I forget which one). It's not leftmost, which means it will be processed earlier than the controller value.

Channel number --> [== 6] will produce 1 if it's 6, and 0 otherwise.

So if you plug that into the right inlet of spigot, then you have an on-off switch based on channel number.

Then you can pack the value and array index into a 2-item list, pass this through spigot, and it's ready to plug directly into tabwrite (because tabwrite accepts a list of "value index").

hjh

@esaruoho I am away working on a show (using Wi-Fi as I have without a failure since 2011) and so very slow to follow your thread.
The [netsend] and [netreceive] are inside [osc-s-r] which is inside [globpitcharray] about half way down on the right and side.
As @ddw_music does, I use a dedicated router (semi) secured by password and mac address filtering, and not connected to the internet. Also... I never let my show laptops connect to the internet once they are set up..... automatic updates etc. can be fatal.
I am usually 50M to 100M from the access point. It is tempting fate to say it always works..... so I will not (it does though).
David.

@ddw_music said:

[spigot] blocks messages if its right inlet is 0.
One of the ctlin outlets gives you the channel number (I forget which one). It's not leftmost, which means it will be processed earlier than the controller value.
Channel number --> [== 6] will produce 1 if it's 6, and 0 otherwise.
So if you plug that into the right inlet of spigot, then you have an on-off switch based on channel number.

thanks! that helped! so two spigots like in the picture below, and it seems to work like a charm, no issues.

Then you can pack the value and array index into a 2-item list, pass this through spigot, and it's ready to plug directly into tabwrite (because tabwrite accepts a list of "value index").

hmmm.
so [pack f f] and then slam that into tabwrite?

thanks, this also seems to work!
interesting stuff for sure. i've never really gotten comfortable with using [pack] anywhere, there might be multiple ways of doing it properly

@whale-av said:

The [netsend] and [netreceive] are inside [osc-s-r] which is inside [globpitcharray] about half way down on the right and side.

ok! found the [osc-s-r] and set TouchOSC on macOS and TouchOSC on iPad to talk to 8000 and 9000. i am now able to get "from iPad to PD" controls working over OSC - and the array on PD does update.
what's not working, is the "back to iPad" color highlighting with steps, even after starting playback of array via metronome.

but pretty amazing that, in the end, even the arp -a was not required to snoop the ipaddresses, since TouchOSC itself recognizes, without having internet access, on the iPad, via usb-tethering, the macOS IP address, and macOS is able to recognize the iPad IP address. this without any internet connectivity or wi-fi on required.

but i'm still vague on how to get the "back from PD to iPad" OSC connection going. but if i got this far, maybe there's hope!

@esaruoho said:

but i'm still vague on how to get the "back from PD to iPad" OSC connection going. but if i got this far, maybe there's hope!

A few suggestions here: https://forum.pdpatchrepo.info/topic/14414/using-touchosc-to-draw-into-a-16-step-array-communication-back-n-forth-show-array-content-in-touchosc/19

I don't know how to change colors by OSC messages in TouchOSC -- you'd probably need to read its documentation to find the right message format.

As before, try a simple test first (change the value of one control). Then expand.

hjh

@esaruoho That's great news.
You will be able to update the grid on the iPad from Pd, sending back the same midi message that you receive in Pd, but the colour change I thought would need a text string.... which is simple with OSC messages..

However here....... https://hexler.net/touchosc-mk1/manual/editor-controls-properties it states that value,touch and colour can be controlled by midi message.

You will have to assign a midi control to the colour value in your TouchOSC layout..... for each control.
"Color corresponds to the control color, indexed by the control's MIDI message controller value, note velocity or program number value, ranging from 0 to 8"

I don't know how that would work with a grid.
With individual faders it would be easy, with a multifader it should be possible as you must already have a midi address assigned somehow to each individual fader.

TouchOSC have a new tool on their site for protocol analysis...... https://hexler.net/protokol#_
David.

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

@beep.beep Multicast is more secure and less heavy on your network than broadcast....... https://forum.pdpatchrepo.info/topic/14396/how-to-send-audio-over-the-network-in-pure-data/3
The topic was for audio streaming... the same principles apply although audio streaming is more likely to flood the network than data.
It does mean though that [netreceive] will need a "listen" message to join the group using multicast.
David.

@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, i think i'm ready to try this out. i've been getting back'n'forth type stuff going on with TouchOSC and Ableton Live, so in theory i should be able to get PD stuff back to TouchOSC via OSC.
fingers crossed!

so on TouchOSC "Grid" called multifader1, the scripting contains

function onReceiveOSC(msg)

  local colors = 
  {
      red = Color(1.,.16,.11),
      green = Color(.46,.8,.15),
      blue = Color(.0,.77,.66),
      yellow = Color(1.,.93,.0),
      purple = Color(.67,.5,.67),
      gray = Color(1.,1.,1.),
      orange = Color(.98,.63,.11),
      brown = Color(.51,.4,.28),
      pink = Color(1.,.02,.95)
  }

  local address = msg[1]
  if(address:sub(-6) == '/color') then
      local argument = msg[2][1].value
      local color = colors[argument]
      if(color ~= nil) then
          self.color = color
      end
  end
end

and the multifader1-named-grid sends out 7 different messages

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

ok. i can confirm a couple of things, @whale-av

1. the TouchOSC Grid starts from 1 instead of 0 - so the array starts from 1 instead of 0. the solution was in the i - so the minute i changed it from 1...2 to 0...1 - the array-writing started working:
   

2. there's no feedback back to the iPad. i figured out what the IP for the iPad is by using arp -a - set it right and now the array on PD is actually muddying up the content on the iPad's grid, with an offset of 1. hard to describe properly
   

so here's what i'm working with right now:

i'd love to figure out how to get the color right (nothing seems to happen)
any ideas?