hmm. try as i might, i'm just not getting a connection going.
i've used what @ddw_music said about [netreceive -u -b 7878] -> [oscparse] -> [print]
but to no avail.
on the iPad, I've set OSC to connect to TCP SERVER set to port 7878.
on TouchOSC on macOS, I've set up OSC -> Connections 1 -> TCP Client and used Browse to find the iPad Mini.

In theory, I should now be rolling. instead, PD tells me warning: MIDI timing FIFO overflowed - nothing appears on the console, and the iPad keeps trying to reconnect to the server (I've got the Editor Network Server Enabled so can edit the TouchOSC script while using it on the iPad)

I don't know what I'm doing wrong anymore. I need to be using both Bridge, MIDI and now OSC.

@whale-av said:

@esaruoho This being a new thread I had forgotten that you were using a wired USB connection.
Yes, that means that you are limited to midi only.

Is that really true? I used to use TouchOSC on an Android tablet. I could connect USB to the computer, and then on the tablet, open a tethered network connection, and this would assign a new IP address to the computer. Then I could use the IP address in TouchOSC and it 100% worked for OSC.

Unfortunately that feature has been removed from the Android versions on my current devices (but these are skinned Android forks, not "real" Android, so the feature might still exist). 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).

@esaruoho

"just not sure how to get PD and TouchOSC to talk to eachother so that this would work."

The first thing I teach in my class about getting data from an external device is: print out the data so that you understand what's coming in.

This goes for MIDI, OSC, Arduino, computer vision packages -- you can't do much of anything without knowing the format of the messages coming in.

You should get print outs something like:

print: list 1 fader1 0.777236

The specific keyword and number of arguments will be different for the multi-slider, but you can find that out by reading the console window.

The real message coming from TouchOSC is like /1/fader1 0.777236. [oscparse] splits the command path /1/fader1 into separate symbols. ([mrpeach/unpackOSC] doesn't do that -- from this object, you would get print: /1/fader1 0.777236.)

At this point, with [oscparse], you will run into the problem whale-av mentioned: 1 in the printed message is a symbol, but if you try to match it using [route 1], it will fail because [route] will be looking for a number. That's the workaround I posted: [oscparse] --> [fudiformat] --> [fudiparse] --> ...

Then the other detail is that you need to drop the list type tag before routing.

And [route] will give you the argument values, now split into one dataflow pathway per control.

hjh

@esaruoho This being a new thread I had forgotten that you were using a wired USB connection.
Yes, that means that you are limited to midi only.
It will be possible to talk both ways but you will be limited to 127 steps for your controls.. so much lower resolution than OSC...... unless you use the pitchbend in TouchOSC and the [bendin] and [bendout] objects in Pd..... see below.
Also I am not sure that you can change data and colour for the same GUI through midi, but you could use 2 GUI's.... a fader and a "push" button or text label above or on top of the fader for the colour.

The 127 step resolution can be improved using pitchbend to get 14-bit resolution...... https://vi-control.net/community/threads/touchosc-has-been-updated.110551/page-3

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.

So the patch I posted was for OSC wireless....... sorry.
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).
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.......
David.

@cfry I used the Arduino library "OSC" by Adrian Freed and in it there are lots of Arduino examples and a few Pd examples using the mrpeach library (which I don't use anymore since vanilla started talking OSC natively). If you can give me a better sense of what you are having trouble with I can make a more helpful example, e.g. do you need bidirectional messaging? What data are you passing (if any)? What Arduino library would you prefer to use (I see there are more now than when I started)? is it over WiFi or ethernet or something else?

But maybe this example from the OSC lib is all you need: UDPSendMessage.ino

Edit: I found my knockoff ethernet shield and wrote this Arduino sender and Pd receiver,. It includes an example of how to route numbers in the OSC path. Hope this helps.
testOSCSend.ino
osc rcv dump.pd

@Harlekin If you want TouchOSC to control OBS you don't need Pd....... just connect TouchOSC directly to the ports of osc4obs and make your remote.touchosc layout file.

If you want to do some other processing in Pd then connect TouchOSC to Pd directly (in and out)...... and then connect your processed control from PD to osc4obs directly (in and out).
osc4obs facilitates that by creating separate OSC in and out ports.
You will have to do that also if you want to use TouchOSC and Pd in an either/or situation as osc4obs only has one set of osc ports and is making a tcp connection with OBS.

OBS websocket is a tcp connection and so it is possible that osc4obs is requiring tcp for the OSC connections...... in which case remove the -u flag from [netsend] and [netreceive] in my examples below.
It could also be expecting ascii instead of binary in which case remove the -b flag (but I doubt that)....

Externals for Pd are written in C so if you are adept there is some help in Pd/doc/6.externs .....
Basically you need to make a websocket client that replicates osc4obs with outlets and inlets instead of the osc ports.

BUT... you could try the iemnet [tcpclient] first (NOT the [udpclient]...!).... and that should work.
Just replace both [netsend] and [netreceive] with the one [tcpclient]...... connect it to OBS and look at the output using a [print] object.
If OBS is on the same computer the connect message will be [connect 127.0.0.1 4444(
Remove the password from the OBS websocket unless you find that a password can be added to the [connect( message for [tcpclient]...... before or after the port number? preceded by "password" or "passwd"?...... guesswork...... and [tcpclient] might well not accept a password as it is not mentioned in the help file.
Once you are looking at a print of the received messages the problem will be to decode the proprietary message format (it will not be OSC)....... it might be easy.... or not.
If lucky there will probably be the ascii strings you are looking for or a decimal representation of them somewhere in the message.

If you go the osc4obs route then it is quite easy to use [oscformat] and [oscparse] in vanilla instead of creating an external.......
...... vanilla osc.zip

P.S. try to avoid integers within the OSC address (header) as they arrive in Pd as symbols at the output of [oscparse] ....... and are then difficult to route. So what/ever/6 data is best avoided if possible and what/ever/six data is easier to deal with in Pd...... but I have included a solution in the zip file above.

Be careful in TouchOSC to avoid message feedback (much like midi feedback)......... and the same applies in Pd. In Pd you can include "set" at the start of a message (without the quote marks)...... which will set a message in the next object or message box but not send it onward until that object or message is banged.
David.

Hi!
I have a new problem,
Everthing is working but not when I want to use the accelerometer of the phone, that's really weird.
Processing is receiving but not PD

Processing code:
import android.content.Context;
import android.hardware.Sensor;
import android.hardware.SensorManager;
import android.hardware.SensorEvent;
import android.hardware.SensorEventListener;

import oscP5.;
import netP5.;

import controlP5.*;
ControlP5 controlP5;

OscP5 oscP5;
NetAddress myRemoteLocation;

Context context;
SensorManager manager;
Sensor sensor;
AccelerometerListener listener;
float ax, ay, az;

void setup() {
fullScreen();

frameRate(25);
// create a new instance of oscP5.
// 12000 is the port number you are listening for incoming osc messages.
oscP5 = new OscP5(this, 12000);
myRemoteLocation = new NetAddress("192.168.137.1", 12011);
controlP5 = new ControlP5(this);

context = getActivity();
manager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
sensor = manager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
listener = new AccelerometerListener();
manager.registerListener(listener, sensor, SensorManager.SENSOR_DELAY_GAME);

textFont(createFont("SansSerif", 30 * displayDensity));
}

void draw() {
background(0);
text("X: " + ax + "\nY: " + ay + "\nZ: " + az, 0, 0, width, height);
}

class AccelerometerListener implements SensorEventListener {
public void onSensorChanged(SensorEvent event) {
ax = event.values[0];
ay = event.values[1];
az = event.values[2];
print(ax);
print(ay);
print(az);
}
public void onAccuracyChanged(Sensor sensor, int accuracy) {
}

}
void mousePressed() {
/* in the following different ways of creating osc messages are shown by example */
//OscMessage myMessage = new OscMessage(int(knobValue));
//myMessage.add();
OscMessage myMessage = new OscMessage("/test");
myMessage.add(ax);
myMessage.add(ay);
myMessage.add(az);

/* send the message */
oscP5.send(myMessage, myRemoteLocation);
}

PD code:
[import mr peach] -----> [udpreceive 127.0.0.1 12000]--------->[unpackOSC]------->[routeOSC /test]---->[number]

I've already try like that too :
[import mr peach] -----> [udpreceive 127.0.0.1 12000]--------->[unpackOSC]------->[routeOSC /test]----> [unpack f f f]-------->[number]

Thanks in advance

Hi folks!
I reached this thread because I had the same problem: there were no way to receive OSC messages in PDparty. I was sending a simple bang from Isadora, just for test purposes, and it works fine on PD on my Mac (sending to locahost), but does not work sending to my Iphone IP. I was sure that the OSC were issued corrected, cause I can see them on Isadora OSC monitor.
Finally I found the problem was a conflict between the OSC incoming port in PDparty (Iphone) and de OSC port that the patch is lisent to (specified in a message to netreceive). If this one (in netreceive) is the same that the one in Port incoming (PDparty), you get in the console this error "error: blind: Address already in use (48), and the patch in PDparty do not receive OSC messages. I changed the OSC incoming port in PD settings, and the patch is receiving OSC messages to the port specified in [lisent] and [netreceive].
I attach my test patch (just play the sound file "cascabel" from the bang button or from OSC (send "/toggle1 1" to port 4321 to the IP where PDparty is running).
Hope it is useful for somebody. I was stuck for hours finding the reason for no receiving OSC
Regards
Daniel
TEST_PDparty.pd cascabel.wav

@toddak http://danomatika.com/code/pdparty/guide#osc-server-settings mentions setup of an osc server, but as you say there is no doc and it suggests that it only sends the phone sensor data..... but I am unsure.
It says it is inspired by TouchOSC, and the Hexler site had test patches. They used MrPeach (extended) objects though, and they will not work I think with PdParty.
It has not been updated...... https://hexler.net/docs/touchosc-getting-started-osc?android

It does mention [netsend] and [netreceive] further down, but you will have to use the vanilla methods and not the older MrPeach objects.
That can be a little more difficult.
Try this..... vanilla_bug_oscparse_solution.pd
It can cope with addresses that contain a float.
That is unlikely to be your problem though, but it will test the connection.
Chop the patch in half and test PdParty with the correct IP addresses.
David.

@JackPD Ok, looking at sndfiler. Let me see if I understand it correctly.

Take the following test patch:

[table foo 128]

[nbx]
|
[; A bang; B resize foo $1; C bang(

[receive B]
|
[sndfiler]
|
[bang]
|
[send SNDFILER_OUT]

[r A] [r SNDFILER_OUT]
|     |
[timer]
|
[print first]

[r C]
|
[print last]

Is it true that I would get output printed in the order "last" then "first"? If so then sndfiler breaks Pd's depth-first message passing rule.

Is it true that [timer] here will output different values depending on the size of the float provided to [nbx]? If so then [sndfiler] breaks Pd's deterministic scheduling rule.

Also, it appears a "resize" message with no arguments would crash Pd. That's a bit alarming given that I just happened upon it while scrolling through the source. Threading issues are extremely difficult to debug so I'm a bit cautious about exploring much further. (Also there's a threading wrapper library dependency by yet another author...)

Just for a thought-experiment: imagine a set of "delay" externals that try to do computation on a separate thread in the time allotted:

[resize foo 256(
|
[sndfiler 50]

In this case "50" would mean to delay output for 50 milliseconds from the time the object receives an input. So you send the resize message, sndfiler does the work in a separate thread, and after 50ms the object gets a callback to send output.

Now, if the thread has finished its work the output would be sent deterministically. If not the object would block until the thread has finished, send the output, then display an error to the console that it missed a deadline.

That's basically just mapping Pd's system scheduling to control objects. I think that would be a very clunky design that would be hard for users to maintain and reason about. But it's still preferable to breaking determinism as sndfiler apparently does.

Btw-- even after sndfiler finishes its threaded array resizing, it still must rebuild the dsp graph for the reasons I mentioned in my last message. So for patches with lots of signal objects you'd probably still generate dropouts.

Hm... here's an idea:

1. Require every class that deals with garrays to have a "set" method
2. Require the "set" method of these classes to bind the object to a symbol that concatenates the array name with something like "_setter". So [set foo(--[tabread] would bind that object to symbol "foo_setter"
3. When array "foo" gets resized, send a message "set foo" to "foo_setter"

Now every table-related object that uses array "foo" will have an updated reference to the newly resized array before the next dsp tick. This is because when you send a message to a receiver symbol in Pd it will dispatch the message to every object that shares this name.

On the other hand, the "set" methods of table-related classes in Pd weren't designed to be realtime safe. For example, some resize values may trigger an runtime error condition that requires rebuilding the graph. I guess the algorithm above could call some kind of "slim-lined" version of "set" that does size-based checks but excludes things like array name lookups, etc. But that would require splitting out every single "set" into a set of two methods.

A combination of that and the delay-based sndfiler could get you array resizing without dropouts. But that's a very clunky interface which is difficult to debug for a lot of work upfront just to get it running.

@bamboomusic As I understand PdDroidParty it is for running a Pd patch on an android device.
You will need it to send OSC messages over the network to control a patch on your computer that deals with the midi.
Look to use [netsend -u -b] and [oscformat] on the Android patch (if they are included in the list of vanilla objects that will work with PdDroidParty)....... and [netreceive -u -b] and [oscparse] on your computer.
Then use the incoming OSC messages to control the midi objects on your computer.
You can just use [netsend] and [netreceive] and work with lists.... but OSC messages are more human readable.
The really simple solution is to buy a copy of the "TouchOSC" app for Android. Your Android interface will be much prettier and easier to build. It can send OSC and midi messages and has some ready-built templates for many DAWs. Once purchased (I think it is about $5-$6) you can put it on all your Android devices.......... https://hexler.net/software/touchosc-android
David.