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

@ddw_music said:

If you enable "Ping" in TouchOSC, then it will automatically send a message to the computer, which will trigger the "connect" logic right away.

hi, i'm not sure what Ping in TouchOSC is?

is it maybe this? i'll try to enable it and see what happens.

@whale-av said:

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.

well, luckily i have some prior art from asking around on the TouchOSC Discord - i got told how to change the colour of a grid object (in this case, a fader from purple to yellow, to differentiate them).

so here's 9 grids that auto-initialize to having the fourth slider (which corresponds to the fourth send in ableton live, which is a specific type of send (+1 octave pitch grain/granulator), set to yellow.
the OSC command for this fourth one is:

function init()
      if self.name == "4" then         -- only executed in control 4
        self.color = Color(1,1,0)
      end
end

so in essence, it should be possible to take this and set the color right.
i'm not sure how though but at least there's the functional color changing code.

ok so i tried to change the formatting for yellow from what was specified in the plom.tosc, green = Color(1,93,0), to green = Color(1,1,0), but that did not seem to result in any specific change.

but i am getting these messages of /1/multifader1/3/color and /1/multifader1/4/color type stuffs and one of them receives the string red and the other the string green.

so maybe what's going on is that they're just not receiving the actual right message. if i was maybe sending a string with the required content, maybe that'd be the trick?

so now i have a simple message without the $3 $1 $2 formatting, which just sends out
[set 1 multifader1 1 color, format s, symbol red(
and i can see it being received.
what i can't see it doing is changing any colouring.
i guess the next step is to modify the grid-object's init state to set a specific fader to yellow and see if it works, instead of using the numbers for yellow, the text yellow.

ok, based on what i'm seeing, the number for yellow, as specced in plom.tosc, is not valid.

local red = Color(1.,.16,.11)

will not work

local red = Color(1,1,0)

will work.

so in that case.. what's not working currently is the "take that message and react to it" part of it. if i could get a PD-button feasibly working that would change the color on a grid, i could continue troubleshooting this, but so far i just don't know how to do it

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

..
ok, solved this by changing a [+ 1] to [+ 0] - now the "back from PD to TouchOSC" no longer bugs out.

if only i could solve how to send the correct OSC message from PD to TouchOSC to change the color. then this'd be pretty much ready to be used.

@whale-av just in case, here's the modified .pd + .tosc
plom_modified_but_no_feedback_yet.zip

not sure how to get the messaging right for the colour change as of yet.

@esaruoho said:

hi, i'm not sure what Ping in TouchOSC is?

If it's enabled, then TouchOSC running on the tablet will send a /ping message to the outgoing address/port at the moment when you activate the TouchOSC interface and every 30 seconds after that. This is an easy way to get the tablet to send a message to the computer right away, so that the computer can get the IP and port that the tablet is sending from.

hjh