Jump to content

Parsing error 3 on UDP input


calfredson

Recommended Posts

Hello,

 

I'm trying to control a generic input using a UDP string sent from another computer on the network.  Here is the string that I am sending:

 

setInput “testin” 0.5

 

The Watchout computer recognizes that there is a command sent, but it returns this error:

 

Parsing error: 3; Unexpected end of file/line/communication: setInput

 

Anyone know what I am doing wrong?

 

Thanks,

 

Craig

Link to comment
Share on other sites

Thank you for the reply.  I have tried adding a carriage return in all possible forms, but I still get the same error.  The program that we are (currently) using to send the UDP data is Max/MSP, so I'm not exactly sure how that program formats carriage returns and hex bits.

 

Otherwise, is my syntax correct?

Link to comment
Share on other sites

  • Moderator

Thank you for the reply.  I have tried adding a carriage return in all possible forms, but I still get the same error.  The program that we are (currently) using to send the UDP data is Max/MSP, so I'm not exactly sure how that program formats carriage returns and hex bits.

 

Otherwise, is my syntax correct?

 

Yes, the sytax is correct.

Keep in mind the input name is case sensitive - so it must be an exact match to the Input named in the WATCHOUT program.

But the error message does not point at that type of an issue.

Link to comment
Share on other sites

The application must be sending the command as a list of strings. Try wrapping the whole command in double quotes -- "setInput “testin” 0.5"

 

You may need to escape the inner double quotes with a backslashes like this - "setInput \“testin\” 0.5"

 

Watchout sends that error if some part of a message is omitted. Sending only "setInput" would give you that exact error.

Link to comment
Share on other sites

  • Moderator

SOLVED!  

 

Thank you Tim.  You were almost correct, but led me to the correct solution.  The string that finally worked was:

"setInput testin 0.5"

with no internal quotes.

Craig

 

so tim's guess on how to designate quotes within a quoted string was incorrect, but still important advice.

The reason it worked with no internal quotes is your input name had no spaces.

(The quotes around the input name are not required in that case)

 

If your input name had spaces, you would have a problem

until you discover how to delimit names with spaces within that string.

Link to comment
Share on other sites

  • Dataton Partner

Hello,

 

I'm trying to control a generic input using a UDP string sent from another computer on the network.  Here is the string that I am sending:

 

setInput “testin” 0.5

 

The Watchout computer recognizes that there is a command sent, but it returns this error:

 

Parsing error: 3; Unexpected end of file/line/communication: setInput

 

Anyone know what I am doing wrong?

 

Thanks,

 

Craig

 

I was able to simulate the same sort of error message when sending 

 

setInput “testin 0.5

 

instead of

 

setInput “testin” 0.5

 

WATCHOUT could not recognize the name correctly due to the missing    "

Link to comment
Share on other sites

I've attached a screenshot of a functional Max patch that works properly with input names that contain spaces.

 

https://drive.google.com/file/d/0B8aHFFwB6M8Tc1BReUdPcm16ZzA/view?usp=sharing

 

Watchout will receive this- setInput "test input" .2

 

Within Max the inner double quotes do need to be escaped using a backslash or the message will not be interpreted correctly and will get split apart into a list of strings.

Link to comment
Share on other sites

This resides more on the Max side of things than the Watchout side, but I kept getting errors in WO when I used the "udpsend" object.  For some reason, Max was sending an extra comma a few bytes after the message.  It was working, but it bogged down WO considerably with the error message.  It turns out that "udpsend" formats all its outgoing messages as OSC, so that might have been where the extra comma was coming from.

 

Anyway, I switched to using the "mxj net.udp.send" object and all was fine.

Link to comment
Share on other sites

If you want to solve this problem, make sure that your MAX/MSP is sending the correct syntax first.

 

I suggest UDP monitoring program.

 

Check the exact syntax with the UDP monitoring program instead of WATCHOUT.

 

You are sure thath the syntax is correct then use your WATCHOUT.

Link to comment
Share on other sites

The syntax is correct.  I've been using Wireshark extensively to snoop on the UDP packets; it has definitely been a useful tool.

 

The latest error relating to bad numbers is definitely related to sending too many data packets.  I throttled the frequency that the data packets are being sent and the error went away.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...