Is ofxOSC compatible with TCP?

If the library itself is not exposing the data you want, simply modify the library and expose that data; make a getter function and store the data you want as a class member and not as a function variable (declare it in the .h file)

My apologies, I know this must be extremely frustrating for you. I believe that Is what I am trying but I am obviously missing something. I believe I have set up a setter and getter, but when I try to use it in ofApp It just returns empty strings. While I know I will need to set up something so it is not printing every frame, it should still be showing something should it not?

I have also replaced incomingOSC with ofToString(ofGetElapsedTimeMillis()) and that works, again - printing on every frame. Unsure why incomingOSC is empty.

//----- .h file
string incomingOSC;
virtual string Recv();

//----- .cpp (end of printPacket function for now)
incomingOSC = desc;

string OSCMethod::Recv()
    return incomingOSC;

//----------ofx library wrapper----------
//----- .h
string recv();

//----- .cpp
string ofxEosSyncLib::recv()
    return oscMethod.Recv();

void ofApp::update(){
    cout << eosSync.recv() << endl; //ONLY PRINTS EMPTY STRINGS

My sincerest apologies. Trust me, I wish I was smarter too.

Hi, it might be that OSCMethod::Rect() is being overridden. Or not called at all. the simplest test is to put a cout inside that function, in which you can print the incomingOSC string, thus testing if the function gets called and if you are getting anything in that string.
and remove that cout in the ofApp::update as it will be only messing around.

Yes, if I assign incomingOSC = "Hello World" then in the main ofApp I get “Hello World” over and over again. Which I would assume means that the function is indeed being called. However if incomingOSC = desc it prints empty strings. If I cout right under where I am assigning incomingOSC = desc it works as expected.


is a virtual function so it might be overriden somewhere, thhus you dont get the string you are looking for.

What happens if you try the following instead

string ofxEosSyncLib::recv()
    return oscMethod.incomingOSC;

same thing, just empty strings.

there must be something overwriting it.
when you put the cout << incomingOSC << "\n"; just below incomingOSC = desc do you get empty lines in between non empty strings? if so, probably the problem has to do with asyncronicity as you are trying to read the variable at a point where it has been cleared.

Strangely I get the expected output, with a single empty line - followed by more OSC.

I am assuming I will basically have to break this library apart in order to make it work. I just don’t understand how I can’t find anything on TCP OSC with c++

Hi, more than breaking it appart you need to understand what’s going on. It is not a big library and it is quite tidy so it shouldn’t be problematic. Although I was looking at it and it has a strange design pattern. I think the problem with the TCP OSC in your particular case has to do with the header of the messages, which seems to be non standard.

or the other option, is that you write to the developers of that library and ask for help.

Yes I will do that, I have contacted ETC’s github and am going through other channels.

I will just comment to say I don’t think these are non-standard OSC messages as other language libraries work right off the bat, and every single other OSC program I have used (none specifically made for ETC) work.

Alright, eating my words here. It does look like EOS handles the type tag differently. I just don’t understand how this has never posed an issue until now. So, my sincerest apologies for being skeptical.

I am still actively working on this project and will post an update if I find a solution.

Thanks all

Final Update:

The library has been made. Thanks to Jayson Haebich for the help!