- Prefers to be called
- Uses pronoun
- Seattle, USA
- Work website
- Facebook profile
- YouTube profile
- Personal website
- 5 months 1 week ago
- Last seen
- 5 hours 8 min ago
It turns out there is a limitation with the approach described above: it won't handle zeros probably (presumably because they're considered to terminate the preceding characters/string?) So I'm reading an external file I create manually and then outputting that to the serial port. I'd prefer a self-contained method so would still welcome any suggestions.
The task I'm working on is scheduling projector power on/off times for an installation via its RS232 control codes.
I've run into some strange behavior with 'Is Time-of-Day After' which I might write up separately; it doesn't return True if the current time is many hours past the test time. Composition attached.
IIUC: If you happen to be on a network where you can't specify a fixed IP address, then the DHCP server could change that IP from session to session and you could end up with a conflict. The other Vuo nodes I listed should help in that case but I must admit my tests don't work all the time. For some reason the output ports are not always added in my client app (VDMX). It would be nice if the Vuo team could help us with some reference compositions showing how to do OSC sending robustly for all network setups, including none :-)
It looks as though a combination of 'Specify OSC Output' 'Get OSC Output Values' and 'Specify OSC IP Output' will handle varying IP addresses. It would be nice if there was an example Composition for sending OSC; the two included are for receiving.
Seems a shame to have to specify the IP address rather than just port number. I suppose the IP address won't change without you knowing.
So the problem with a 'Make OSC Output' setup is really on the receiving side, where clients take all messages even when a single port is specified?