First make sure the TCP Send Data actors inputs are not of the type 'text'. (incase they were mutated at some point and the type remains)
Then try:
P1:1BL P2:1BL P3:1BL
Its possible that 0 as a null byte is internally representing the end of a string, so this raw binary approach may get around the issue if the receiver can handle binary. Def worth a quick test.
Yes, as I shared in the original post that I have tried the other formats:
P1:1 P2:1 P3:1
P1:1X P2:1X P3:1X
and
P1 P2 P3
All of the above send the ASCII representation of the values and not the value itself, e.g. P1 is sent as 31 and not 1, P2 is sent as 30 and not 0, and P3 is sent as 32 and not 2.
If I use the format P1:C P2:C P3:C then P1 and P3 is sent correctly and P2 is not sent at all.
I still can't get the actual value of zero (0) sent.
Have you tried these formats?
| Px:n.m | Output the number, with a maximum of n digits to the left of the decimal point and m digits to the right. If the input parameter is text, ignore n.m and just output the text. |
| Px:Zn.m | Same as above, but add leading zeros to ensure a total of n digits appear to the left of the decimal point. |
Here's the full table:
| "ABC" | When text is enclosed in double quotes, the ASCII code for each character is sent to the output. In this example, the numbers 65, 66, 68 (hex 41, 42, 43) would be sent to the output. You may also included escape characters to output special characters like a carriage return or line feed. |
| XX | Outputs the single byte represented by the specified pair of hexadecimal digits. For instance, if you entered 1F then a single byte with the decimal value 31 (hex 1F) would be sent to the output. |
| Px | Use the default formatting. For integer numbers, output the ASCII text of the number in decimal; for numbers with decimal points, output the ASCII text of the number and all the digits after the decimal point; for text inputs, output the text itself Examples: The integer 12 outputs the characters ‘1’, ‘2’ The floating point number 3.141 outputs the characters ‘3’, ‘.’, ‘1’, ‘4’, ‘1’ The text “hi!” outputs the characters ‘h’, ‘i', ‘!’. |
| Px:n.m | Output the number, with a maximum of n digits to the left of the decimal point and m digits to the right. If the input parameter is text, ignore n.m and just output the text. |
| Px:Zn.m | Same as above, but add leading zeros to ensure a total of n digits appear to the left of the decimal point. |
| Px:nX | Output the ASCII representation of the number as n hexadecimal digits. If the input parameter is a floating point number, the digits after the decimal are ignored. If the input parameter is text, ignore the nX and just output the text. Example: Px:2X applied to the decimal value 254 outputs ‘F’, E’ |
| Px:ZnX | Same as above, but add leading zeros to ensure a total of n digits. |
| Px:C | Output the character as a single byte of data. Examples: The number 65 gives ‘A’ The number 13 gives a carriage return character |
Have you read all the documentation about the syntax by using the "Help" button at the bottom left of the dialog that appears when you double left-click the TCP Send Data actor?
I'll try this out when I have some time to troubleshoot. Thanks!
Thanks! Mouse Jiggler worked for the show last night! Whew!
Re: [TCP Send Data format](/topic/5110/tcp-send-data-format)
I found this previous thread with the same situation as the one I'm dealing with. However, my particular situation is that 0s (zero) are not being transmitted. It appears that if the parameter is a value of zero then it is just skipped. (I need the zero to be included to preserve the expected message format on the other end.)
I have reduced the situation to the very simple example below.



In the above example, parameter 1 and parameter 3 are transmitted as the anticipated values. However, parameter 2 is skipped - the zero is not transmitted
If I use any of the other available formats in the "TCP Send" actor I just get the ASCII representation of a zero and not the value zero.
What am I missing?
@nic said:
I eventually want to stream 4k, but this is more to do with the bandwidth of the various platforms rather than any Izzy issues.
You should chat with the folks at Office Hours Global. They're always pushing the limits of what's possible when it comes to broadcast and streaming. I've been hanging out there for years and they're all super knowledgable and friendly.
@woland Thanks everyone, yes apologies, I was just after a simple task of streaming HD video from a remote camera into Isadora. Of course, the ScreenCapture actor does just that. I eventually want to stream 4k, but this is more to do with the bandwidth of the various platforms rather than any Izzy issues.