so whats the problem then if that works?
also have you tried a little patch in vvvv that sends to /info and receives in return? just to make sure this basically works…
The problem is, that the main thing isn’t to send the data to the desk - except for the fact, that I need that, because otherwise I can’t tell it to send me back the requested data - but to receive some.
The desk is Audio mixer, and my point is to use it as a controller for PC. It doesn’t work in MIDI mode as full interface, but only partly, so now I’m creating an app so that I can make it usable in full-surface control mode.
Anyway, I can’t get it done via vvvv neither. I mean, I don’t even know for sure if I set everything correctly in there… sending is ok, localhost works both ways, but when entering the desk’s ip I can only send, the receiver stays the same…
However the desk works for sure. The official PC app XControl.exe, which is available to download, works just fine. Also, whenever I change the value via vvvv to the desk, the desk reports back that value to XCONTROL app (if I connect with both to the desk - and yes, I know that vvvv can’t receive anything if there’s another app listening on the same port… that’s why I tried without xcontrol before and after seeing that the desk reports info fine…).
I really don’t know what’s going on here… :(
so post the patch you’re trying with here so we can tell you if this is a correct test.
I have no idea how to save that thing, when rearranged. But it sure as hell works. If I open the listening port before running official desk’s app, I catch the “/info” message that the program is sending, if I set the desk’s ip in that program to local ip. However, the thing get’s even better: if I set the IP in a program to actual desk’s ip, with vvvv I catch the desk’s response!
I tried to check the thing with UDP Test tool. Here’s what I’ve done and the results from UDPTesttool:
If I set listening on port 10023, and after that open up the XControl official app and set the “desk’s” ip in app to the PC’s IP, I catch the message that the app should send to the desk, and it’s completely the same as the one from my app, in hex: 2F 69 6E 66 6F in binary: 00101111,01101001,01101110,01100110,01101111 and in decimal 47 105 110 102 111 -> it’s simply /info command. However, here’s the trouble:
Even if I send that same command to the desk, I get no reply! But, if I leave analyser open to listen to that port, and set the xcontrol’s ip to desk’s real ip, I actually do catch response from desk! And it has strings (I converted manualy from hex, without zeros): /info,ssssV1.00osc-serverX321.15
So basically, I really just don’t understand: if the XControl app sends info while searching for the desk, the desk replies, but if I send that same exact command, it doesn’t.
[to prove that I have the same coding, I copied the hex value from desk’s info reply, and try to send to my pc’s ip from analyser: The xControl app recognized it as if it was the desk. So I guess it’s ok!](to prove that I have the same coding, I copied the hex value from desk’s info reply, and try to send to my pc’s ip from analyser: The xControl app recognized it as if it was the desk. So I guess it’s ok!)
Do you have any idea what is happening here?
I attached you udp analyser program, if you’ll have a minute or two, could you please try and see if it works for you, and if not, if you have any idea what might be the problem?
It’s far beyond my imagination and knowledge…
Thanks a lot!
udptesttool_setup.rar (1.4 MB)
young man!
if you want help then try to follow the given advice and stop telling stories.
so i gather:
your code sends osc correctly but you have troubles receiving osc sent from the behring, right?
in order to check you get the basic wiring right i suggest you create a vvvv patch that sends /info and listens for (and displays) the returned info.
when doing so leave any udp-tools or official apps closed.
you can save a vvvv patch by pressing ctrl+s or middleclick in a patch to open the menu and save from there. post the patch you come up with here and say if it works or if not what seems not to work. from there we’ll take the next step.
no need for that, thanks.
and yes, young man, but not telling some stories. If you’d understand and see what I saw, (I didn’t explain very well though), you’d know that I was talking that neither udp tool nor vvvv is not recognizing anything from the desk, while it does WHEN the official app is running (so, the desk replies to official app’s request, and I catch it IN vvvv AND in udp-tool if catching on that port. However, when sending from vvvv OR udp tool, no response. With same request. Now, today, with wire shark, I figured the problem: all of those programs were sending TO port 10023, where desk is listening, but not FROM that port: wire shark shows that my program is sending from random port to 10023, so the desk replies to that random port, FROM 10023. Looks like both, vvvv and udp tool are listening what port is it send from, I guess, or what?
However, when checking UDPClient in my delphi, I noticed that there’s an option to bind port, as well as the Port option. I figured that the bind port is port where it’s sending FROM, and the Port is port that it’s sending TO. I’ve alrady tried that once when checking every option (amateur ;) ), but app crashed because of the port being used - by UDPServer I guess. I managed to repair that by setting the Reuse socket from OSDependent to Enabled, on both client and server. I’m not sure if I understand that Host port and normal port, with the server’s indy port, but however, now I get the replies back correctly, - I mean, the UDPServerRead event happens and breaks at breakpoint.
I’m really surprised that nobody ever mentioned that port setting and that port trouble. I don’t know, is it that obvious(?), that I really should figure that out by myself or set it up from the beginning, or it just didn’t come to anyone’s mind?
Anyway, the app now works correctly with send/receive both enabled, so I’m glad.
The problem still exists with reading the array of byte. Even though normal mode works without errors, in debug mode, I get exception on the line where I try to use the function that David from StackOverflow wrote - > converting array of byte to TBytes so that I can use it in your OSCUtils…
As already told several times, I don’t know how to deal with that conversion, but it looks like his version doesn’t work. So I guess I’ll have to wait for you, (if you’ll ever even do that?) to adapt OSCUtils so it’s fully compatible with indy10’s array of byte.
Joreg, I’m really sorry if I’m bothering so much here, and if I even ot out of topic above, but I’m just trying to figure all this out, and also write as much (and as less as possible) as I can to describe it the best, so that also any other user can find it, and if even 1 finds any of that info or problem/solution useful, I’ll be happy. :)
Bdw thanks for all your help and patience so far (and hopefully even further), I learned a lot in these days, and in last month in general, about delphi, OSC, and other network -delphi stuff. :))
Hopefully to find read solution asap. ;)
Cheers.
now that is odd indeed, never seen such a behavior but on the other hand it is clearly stated in their documentation:
“…replies are sent back to the requester’s IP/port.”
so probably just use the .ReceiveBuffer on the same IUdpClient that you call .SendBuffer on and see if that receives you the return values.
Actually, as stated above, I solved that with binding the port to UDPClient. It has two properties: Port, and Bound port; looks like the Port is destination port,but Bind port is source port - didn’t know that :/
I set both on 10023, and since the UDPServer is also set to listen on 10023, the app somehow crashed, but now that I’ve tried to set the “Reuse socket” property from OSDependent to Enabled on both, UDPServer and UDPClient, it doesn’t crash anymore. Also, the UDPServerRead actually does trigger.
So, now I do get replies from the desk. Yeey.
However, in the debug mode run I get process exception on executing CopyBytes function, that should convert array of bytes to TBytes. Looks like it doesn’t work… :(
So now there’s that conversion from received bytes to OSCPacket.Unpack that needs to be solved I think… :)
Will try the .Receive buffer now also to see what’s up… thx.
So, here are debug’s results:
I finally got some time again, and went through UDPServerRead procedure and checked with break point 1 by 1, and the app doesn’t break until the end of the procedure, and had some access violations, but that was me, idiot, forgetting to put “msg:=” before TOSCMessage.Unpack, so that one solved, so I deleted last reply.
Anyway, TADAAA. I managed to solve the float and integer arguments, and it works! I can now finally actually get the values of fader, so: yeah.
I still however don’t know how to decode string arguments. I get the argument count correctly, but then lost when figuring how to decode it. There are functions GetArgumentAsFloat and GetArgumentAsInt, but there isn’t any GetArgumentAsString. However, there is GetArgument function, but it results back as TBytes, and not as string.
Please, last clue here? :))
Ps:
If it’s not too much (after all I’ve already asked and torched you…), can you shortly explain, what are these functions, and why are they needed - if at all:
function UnpackAndReturnInt(Bytes: TBytes; var Offset: Integer): Integer;
(and float, etc…)
function UnpackFloat(Bytes: TBytes; var Offset: Integer): TBytes;
(and string, etc…)
Are these just old functions, or are they different way of decoding, than the one I now use?
Also, how can I detect if the reply is float, string or integer, if I can detect that at all? Or do I need to set this manually in dependence of every request I sent (expecting the reply to be same type)? Do you already have the typetag somewhere implemented, or should I do it myself with every OSC path…?
Thanks! (I feel I’ll have to transfer 20€ to your account so you’ll have a couple of beers from me for helping me here out for the whole week now…˘˘)
good to hear your progress.
have a look at the code i posted above. line 27 reads a string argument.
also in the code above line 24 see how you get the typetag for each argument. the code above then does nothing with that typetag but returning it for the vvvv-user to deal with. in your case you’d call different GetAs… functions depending on the typetag.
and have a look at the code of OSCUtils.pas to see how the Unpack… functions are used internally. you won’t need them.
Holly Delphi…
Memo1.Lines.Add(TEncoding.UTF8.GetString(msg.Argument[i-1](i-1)))
Now that’s what was missing to me to decode string in correct format. Voila. :))
Hahahah, that was lovely, interesting and kinda hell of a way to make this all work. :)
I was deep in math and logic connections since yesterday already, because now that for a fact it works, I can get down to do the program implementation itself, but having the last piece of a puzzle so I can start by identifying the desk, is even better now. :)) Hopefully I’ll attach to the rest of the project soon. :)
Anyway, I won’t just disappear yet. :) I’ll see how my work and progress will go, hopefully as fast as I wish, and once alpha version made completely, we’ll put this on a web and I’ll post a link, so you could see results! And find out what exactly were I even doing here… ;)
Joreg, we’ll keep in mind that you were big part of the OSC section. If you don’t mind, I’d love to give you the credit for helping me out on this one!
phew…glad we got through this.
always a pleasure to help out…