OSC block error - receiving OSC message from Kyma

1

hello everybody, I am new to Cinder and I already love it.
I am trying to send OSC message from Symbolic Sound Kyma to a CinderApp. I am using the OSC block that comes from cinder.

I got this error:
*|warning| void cinder::osc::ReceiverBase::dispatchMethods(uint8_t , uint32_t, const asio::ip::address &, uint16_t)[1159] Message: /osc/response_from doesn’t have a listener. Disregarding.

|fatal | void cinder::app::AppBase::executeLaunch()[197] Uncaught exception, type: cinder::osc::Message::ExcNonConvertible, what: /posx: expected type: FLOAT, actual type: INTEGER_32

libc++abi.dylib: terminating with uncaught exception of type cinder::osc::Message::ExcNonConvertible: /posx: expected type: FLOAT, actual type: INTEGER_32

I have tested Kyma/OSC sending with Processing/PureData/SuperCollider and I got no problems…
thanks.
d

2

The error seems to be in the client code, not the osc block itself. You’re apparently trying to retrieve a value from an osc::Message called “posx” as a float, but the server that’s sending the messages sent it as an int.

3

Thanks for your reply. I forgot to mention that the I am sending floats and not ints. Kyma only sends out floats. If I check it with another OSC client as PD or Processing, I can see floats arriving.

4

if you print out osc::Message directly you should see exactly what’s coming in.

void yourListener ( const osc::Message& message )
{
    std::cout << message << std::endl;
}

My suspicion is that the processing client is being more forgiving about how it treats numeric types than cinder’s implementation is.

5

I will check it later. But in the server (Kyma), I can’t change anything because the OSC sender is a “native” module. Is there any workaround I can do in the C++ code to make it more “tolerant” ?

6

You don’t need to change the sender, your client code is where the problem is - you’re asking for a float where an int is coming in. Can you show me your listener function? Are you perhaps asking for the wrong argument index?

Either way you have the source of the cinder osc implementation, so you’re free to modify it to be more tolerant, but i wholeheartedly don’t recommend that. In my experience when you bring to native programming the kind of “hack and hope” style that a lot of processing guys seem to have, you’re gonna have a bad time.

1 Like
7

thanks for helping me think about this, the problem was in the sample code for cinder:

mReceiver.setListener( “/mousemove/1”,
[&]( const osc::Message &msg ){
mCurrentCirclePos.x = msg[0].int32();
mCurrentCirclePos.y = msg[1].int32();
});
the .int32() was actually the problem.