Just discovered the sync mode for TouchIn and Out.
Two things came up:
Using synced mode on Touch IN in the same app instance creates issues, the node takes over that is placed last time in network. I think it may relate to socket binding somehow though not sure. This is easy to resolve with selects. Using synced ports mode on on the sending touch out and having multiple apps with touch in synced mode on works for me fine. But switching between synced ports on and off on the touch out node in some cases result in socket binding unknown error. all of this through local host single computer.
I dont get the same naming issues… simply copying the touch in node several times makes the last one receive the channels with correct names… switching between synced port on and off in some cases makes channels not update… but this is inconsistent… .cant really pinpoint yet.
ah ok, im getting the naming issue too when dropping new touch in node. if copied it just takes over with correct channel names… deleting one by one in creation order gets allways the previously placed touch in node active… synced ports off doesnt have this issue. though i suspect that using synced port on may suggest to keep using only one node par project and distribute via selects from there… similar to sync in node
and maybe one last finding: when the touch in node is copied the channel names are correct, toggleing bypass off than on results in losing the names as if placing a new node.
Thanks for the report. I’ve fixed this so the channel names should be sent across when a new client connects.
It’s expected only one node can read from a specific ‘port’ when using synced mode. You can use multiple nodes using different ports though.
Note that underneath, there is only one actual network port being used, and we are packaging up all of the TouchOut data into a single set of data sent at the end of the frame. The receiver (which also only connects to a single real port), then splits up the data based on the ‘port’ parameter, but which used just as a tag on the data in this case.
Builds 2023.12121 and later.
Hi Malcolm,
thanks for the fix.
The docs only note that one syncedCHOP can send data. For the inCHOP this behaviour ist not dscribed in the docs and I do not see a reason why this should be the case. This also contradicts the fact that I can run one ore more of these syncedCHOP in differrent processes, which works fine.
I’ll update the docs. The reason this is the case is because there is only a single network connection per process, so each node picks up the data for it’s own ‘port’. Different processes means different copies of the data.
@malcolm @snaut thanks for looking into this, and for the fix. I have been absent for a bit, now back and installed the latest build.
I think there may be more to this. I encountered the same issue but in different context that I was able to test before:
I am now testing to send timecode channels from win 11 TD process (2023.12.120) to mac Sequoia to drive audio playback on a mac machine. Synced port mode i was not able to get running at all, but during attmepts by switching between modes the same disappearence of channels names happened as before.
Messaging and Streaming protocol modes work, however connection does not get established reliabley, need to change port to different and back, or toggle active on/off and eventually it gets up and running.
Synced port does not work.
Multicast work, however playack of the audio on the mac end based on the transmitted timer channels gets glitchy.
both computer run only a single TD process, and only a single touch out on win machine and a single touch in on the mac laptop
hw: macbook pro m4 max, mac os sequoia
lenovo legion7 rtx 4090, win 11
I’ll need to look into your other notes more, but note that the posted build does not have the fix yet. The fix is in builds after that.
