right, well from a quick look there is a bug in LiveOSCCallbacks.py for requesting a clip name, but it shouldnt stop it sending strings.
on line 258 my version says this :
self.oscServer.sendOSC("/live/name/scene", (trackNumber, clipNumber, LiveUtils.getClip(trackNumber, clipNumber).name))
but should be
self.oscServer.sendOSC("/live/name/clip", (trackNumber, clipNumber, LiveUtils.getClip(trackNumber, clipNumber).name))
looks like someone copy / pasted and forgot to edit the code properly
what i would suggest is to first try replacing the
LiveUtils.getClip(trackNumber, clipNumber).name)
with a string literal in the python code (say "test") to see if that comes out properly. If it does then there is something wrong with the LiveUtils.getClip lookup, if it doesnt then there is something wrong with the message sending.
The oscServer.sendOSC just delegates to the oscClient code (this is in RemixNet.py)
so the block in OSCClient.send starting at line 132 (in the version i have) does the type checking, so try putting some debug code in there and see what types python thinks its getting.
you might want to dig down into OSCArgument (OSC.py line 165) which is where the message arguments get converted to binary. This particular line looks like fun :
OSCstringLength = math.ceil((len(next)+1) / 4.0) * 4
add 1 to the length of the string, divide by 4, take the ceil and multiply by 4. ?
Looks like some kind of padding calculation for alignment on 4-byte boundaries.
The string is then packed into a double char format here
binary = struct.pack(">%ds" % (OSCstringLength), next)
right so the OSC Spec says this :
OSC-string
A sequence of non-null ASCII characters followed by a null, followed by 0-3 additional null characters to make the total number of bits a multiple of 32.
which is why the 4 byte alignment calculation is done.
anyway, that looks like the lowest level string handling code so you could always start at the bottom and tracing out what its actually working with.