-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with Ardour reply messages #32
Comments
I've asked in the Ardour forum and it seems that these messages can be treated very similar to normal command messages (https://community.ardour.org/node/14456#comment-46448) With OSC 1.0 it was totally fine to check only the first byte of the message, but I think this has changed. Unfortunately I have not found any official information about this. Specification for OSC 1.1 seems to be down (http://opensoundcontrol.org/spec-1_1) |
hey! :-) |
No, it is not this important right now. I tried to hack together a small android app with your library, but have not worked on it for a few days. When I come back to it, I will fork your project and try to make it work with the reply messages. I will let you know if I have something :) |
Hi, FYI: it seems that ardour doesn't send messages with a prefixed '#' anymore. |
ahhh nice! |
First, thanks a lot for this library! Helps me a lot :)
I want to develope a remote application to control the DAW Ardour via OSC messages. Stateless message sending works like charm so far, but message receiving made some problems. It seems that Ardour sends certain 'reply' messages starting with the string
#reply
. As your library only checks for the first char, it assumes that these messages are#bundle
messages:The raw bytes are interpeted wrong and lead to a
java.lang.OutOfMemoryError
inOSCByteArrayToJavaConverter#convertBundle()
(line 157).I couln't find anything about these reply messages in the OSC 1.0 specs. Maybe something from a more recent specification? Any suggestion how I should deal with that?
--- EDIT ---
I just realized you have a development branch that is way ahead of the master branch. I will try this one later, but I guess it has similar problems, as it uses the same bundle check.
The text was updated successfully, but these errors were encountered: