Is ofxOSC compatible with TCP?

Hello, Beginning to realize OpenFrameworks may not be right for this project. I need to receive OSC via TCP.

However I don’t see anything in ofxOsc allowing communication through TCP. Is this true?

If it is true, any recommendations for how to receive OSC through TCP?

Hi,
I’m not sure, but I think I’ve succesfully used this addon once:


Not sure if it’s 100% compatible with other OSC TCP programs…

Thank you for the link, unfortunately that library has been abandoned - Had a very nice email from the creator. When trying to use this library, upon another client logging on or receiving messages, the program freezes.

Still looking for a solution.

Still looking for any sort of help or guidance on this one.

Hi, Why do you want to use TCP for it? If you are worried about data packet integrity it sure does not make much sense to use OSC, as it is focused on different things. What’s wrong with using plain TCP communication?
Can you extend a bit on about the scenario you are going to use this? so we might be able to give some advice.
best

Totally! Thank you for the reply. Basically I am interfacing with a lighting software called ETC EOS. That software uses both TCP and UDP, but prefers TCP. It sends and receives OSC to change things within the lighting console. I made an app in Java that controls shutters among other things - Now I am trying to do it in c++ for IOS.

TCP is preferred because it is more stable and drops less packets from the console. As well as it is easier for the end user to use because they don’t have to worry about incoming and outgoing ports.

OSC is needed because that is how the console listens / talks.

I made a Repo with a short explanation and sample “show” file. I am starting to look into people to pay to help me with this. https://github.com/Tedcharlesbrown/OF_OSC_TCP

Hi @Tedcharlesbrown I was able to run ofxTcpOsc on the current version of openFrameworks. The only thing I had to do was to update the example projects using project generator, where you need to put in the addons section ofxTcpOsc and ofxNetwork. Also renaming the example’s src/testApp.cpp and src/testApp.h to src/ofApp.* makes things easier. Make sure you also change it where it says #include "testApp.h"
I hope this helps.

1 Like

Interesting, while yes that makes that library work - but It is still not able to work with external programs (ETC EOS). The two example files are able to communicate with each other - but trying to send OSC to the EOS software results in a corrupt packet size exceeding max limit. And no OSC packets are received in OpenFrameworks.

Update to this project. I found a c++ library and I am attempting to use it. I am however having issues making it into an addon. I have attempted but am 100% sure I am not doing it right.

I have been following the guide by OpenFrameworks, as well as using other addons as examples - however I can’t quite make it work.

Any help with this would be very much appreciated. Thank you all for you patience, my apologies for the posts.

Update: Basically. I am giving up on this. I don’t actually think this library is going to work even if I can get it running in OpenFrameworks, and I am really frustrated that I cannot find a single example or anything for how to get a TCP OSC server running in C++ or OF. I obviously don’t know enough to make it myself. I have attempted to contact people to pay to help me create it with no luck there either.

It makes no sense to me why for some reason nothing is connecting to the ETC EOS software. The OF example TCP Server doesn’t even see that the software is on the network.

So basically I am just going to tell my user base, sorry - if you want better functionality - get an android.

just a thought but did you try both versions of OSC the EOS supports? There might be a mismatch between the OF addons and the desk.
OSC v1.1 uses SLIP protocol over TCP which adds delimiters in the stream, v1.0 sends the length at the start of each packet i think
The addons might be using OSC v1.0 which would cause framing errors.

fwiw - most, if not all the shows i’ve worked on just use OSC over UDP with the eos desks

Have you had a look at oscRouter? Its log might give you an idea what’s going on

Hey, thanks for posting. Yes, I looked at both length-headers and SLIP. If anything it looks like the addons are using SLIP, I will take another look.

Totally understand that you have used UDP. But the issue is I am trying to make this app for everyone. It is much easier for those who don’t know much about networking to have to just type in the IP address and be on their way. Not to mention I am parsing a lot of packets and have already seen drops using a UDP version side by side with my TCP version. Trying not to make users worry about ports and have to type in their devices IP address into the console as well, just in order to make the app work the same as my existing app on Android.

I haven’t looked at oscRouter, but I am trying to make ETC’s “EosSyncLib” work with the help of some other very kind people. Currently, I can send - but I am trying to figure out how to receive all OSC. Not just the strings gotten using “eos/subscribe”.

Hello again, I am very close to a solution… Just need a little more help writing a wrapper function to extract the data I need. I will post a link to my github repo as well as posting the code here.

//oscparser.h //line: 328
virtual void Recv(string incomingOSC);

//oscparser.cpp //starting line: 2509
void OSCMethod::Recv(string incomingOSC) //Library sends OSC Data to this function
{
    return incomingOSC; //attempting to return this to the wrapper?
}

I am not sure what parameters to use since I am just trying to return the data from the function.

Thanks all.

Hi,
I am not following what you are trying to achieve.
can you link to the files with the code you posted please?

sure thing, https://github.com/Tedcharlesbrown/ofxEosSyncLib/blob/master/libs/EosSyncLib/src/OSCParser.cpp

Basically I found that the function starting at line 2465 has the data I want, I am just unsure about how to extract it - since it is in the library.

There is no function to get “desc”, so in theory I would want to extract that to use it in my main application.

bool OSCMethod::PrintPacket(OSCParserClient &client, char *buf, size_t size)
{
	// find osc path null terminator
	if( buf )
	{
		for(size_t i=0; i<size; i++)
		{
			if(buf[i] == 0)
			{
				//std::string desc("[OSC Packet] ");
                std::string desc;
				if(buf[0] == 0)
					desc.append("<null>");
				else
					desc.append(buf);

				size_t count = 0xffffffff;
				OSCArgument *args = OSCArgument::GetArgs(buf, size, count);
				if( args )
				{
					for(size_t j=0; j<count; j++)
					{
						OSCArgument &arg = args[j];

						// value
						desc.append(", ");
						std::string value;
						arg.GetString(value);
						desc.append(value);

						// abbreviation
						desc.append("(");
						char abbrev[2];
						abbrev[1] = 0;
						abbrev[0] = OSCArgument::GetCharFromArgumentType( arg.GetType() );
						if(abbrev[0] == 0)
							abbrev[0] = '?';
						desc.append(abbrev);
						desc.append(")");
					}
					
					delete[] args;
				}
                
                Recv(desc); //SEND INCOMING OSC
                
				client.OSCParserClient_Log(desc);
				return true;
			}
		}
	}

	return false;
}

//HOW TO USE THIS IN OFAPP.CPP?
string OSCMethod::Recv(string incomingOSC)
{
    return incomingOSC;
}

Hi, I would recommend you not to mess with the library’s code considering that it is working fine (or at least I would guess it does).
Then, the function you are looking at is a print function which is probably not the best place where to get the data as it is being formated for printing.
Then, the parser is already doing the work for you getting the data from the incomming stream. It can be a real pain to get a parser to work correctly if you are not 100% sure about how the protocol works.
then, what is it that you want to extract from the incoming messages that has not been already extracted by the library?

Hey, unfortunately the only thing specifically extracted by the library is not necessarily useful to me. The reason why extracting from that function is beneficial is it shows ALL incoming OSC.

Thankfully i already have a parser that I made that works perfectly - I just need to get that information to it. The function I referenced is one of the first places I found where I can get the whole OSC string. In reality I just need to get all incoming OSC, I don’t even really need the rest of the library and what it is doing to parse.

To clarify, the only reason why this library is useful to me… is because it is one of the only libraries that i have seen even work with the ETC EOS software. “work” as in connect via TCP and send and receive OSC. I do not plan on using any of the parsing or anything else the library provides - only the fact that the TCP connection works.

so, if you look at EosOsc class you’ll find the Recvfunction which is where actually the osc data is initially received and starts getting parsed, that’s where the function you mention gets called. This is where you’ll find the “real” osc data. the EosOsc class is where the OscParser is instantiated and called. So what you could do is to make your own OscParser class and swap it for the one that is being used in EosOsc class and call to parse instead of using that print function you mentioned.
Notice how the tcp and osc objects are instantiated and initialized in the EosSyncLib class, as there are pointers and not regular objects.

1 Like

I see, I think I would still have the question on how to actually get that data out of the library and usable in ofApp.h… but I was also playing around with this earlier… Somehow even though oscData is being sent to the printPacket function… It doesn’t give me all the data. It only gives me the address and not the arguments.