[ANSWERED] Monitoring OSC

jtsteph

Hi,

I am wondering what people use to monitor OSC. I like protokol a lot for troubleshooting, but want to have some kind of GUI to visualize things like wave streams, toggle states, etc. I would like to run this on another machine or an rpi if possible. I could probably build something that reads and visualizes the protokol log stream, but I wonder if there is anything anyone is using that might be quicker to get up and running - something like touch osc but for windows or linux.

I would be grateful for any input on this.
- j

mark_m

@jtsteph

Are you looking for something above and beyond the monitor window in Isadora? (menu bar, windows, monitor or CTRL+SHIFT+N)

jtsteph

@mark_m. Yes and no. It might be the quickest/best way forward. I would ideally run this on another machine as I have isadora and resolume running at the same time on my main computer and would like to monitor things being passed back and forth so I can get a sense things in a glance. My thought was to run the monitoring on an sbc or rpi with a little monitor on the side. It would also allow me to monitor stuff from other collaborators. Maybe I am over complicating things - my default configuration :-)

Fred

@jtsteph

OSC is generally IP address and port specific. If you run the monitor on another machine it will either have to be running network packet capture to see network packets that are meant for other machines or the OSC messages will need to be either broadcast or routed to the monitor and not to the machine that is meant to receive them.

Usually we monitor signals to confirm connections, so using the Isadora monitor would be the most appropriate- you see not just what is on the network, but the details of the messages that actually make it to the machine and the port Isadora is using. It does not however give you the GUI you want.

I can understand wanting to monitor all the OSC signals on a network, but it’s important to first decide how this needs to happen. If you want to let your OSC messages continue to flow to their destination you need to use a packet analysis tool like wireshark. Wireshark can already monitor any OSC packets on your network but it does not have any pretty graphs.

I don’t actually find an OSC monitor that does the graphing at all. This would not be hard to make but without using a packet analysis tool like wireshark all OSC messages would need to be rerouted to the monitor host (your raspberry pi) and would no longer be available to the destinations they are meant for. Broadcasting osc is possible but not the best practice. It would also make your setup need a little more care. You would have to target machines by port and not up address as broadcast sends everything everywhere.

jtsteph

@fred Thanks for your detailed input. I understand now. I will stick to CV and Audio from my collaborators. I looked a bit at analyzing the Protokol log stream to generate gui graphing etc - but I think this is a task that will take me away from my core interest here. In the end, I think the quickest way forward is to use the Isadora control panels, and the logging in isadora, resolume and protokol. I've never really used the control panels for much more than reporting values for troubleshooting. I'll look deeper into it. Thanks again.

- J

Juriaan

@jtsteph

What is also a nice plugin for visualizing numeric data is Grapher, which you can find on our Add-on page.

jtsteph

@juriaan Ohhhh. This actor is fabulous. I have already managed to trouble shoot some weird phasing issues I had between my smoothers and my wave modulators where I was getting some slow oscillations when there were running at the same frequency. I am working on optimizing a bunch of stuff so I can have these running during the performance as a dashboard. Thanks for pointing these out.

DillTheKraut

@jtsteph

You can 'Broadcast' the OSC messages. Instead of sending the commands to the IP address of a specific device, you can send' them to the whole network.
There are two specific IP Addresses for this.
First: x.x.x.0 (Example if the IP Address range is 192.168.1.x, it would be 192.168.1.0)
Second: x.x.x.255 (Example if the IP Address range is 192.168.1.x, it would be 192.168.1.255)
The IP 255.255.255.255 might work as well.
Just put one of these IP addresses as the destination value of your OSC sender.

These IP Addresses are not allowed to be given to a single network device, but in a simple network (only unmanaged/good configured managed switches), network messages send to this addresses are recognized by all devices in the network. This way, you can have any OSC monitoring tool on any devices in the network, without the need for doubling/ trippling the OSC actors/ senders.

DillTheKraut

@jtsteph

I remembered a tool I used a while ago. Not as fancy as the 'Grapher' but more of the Isadora monitor on steroids.
https://www.kasperkamperman.co...

On top, it is for linux too.

jtsteph

@dillthekraut Just digging back into this now. THANK-YOU for the tip here. I would love to have some simple out-board monitoring and this will help me minimize duplicating the OSC send actors - they can get expensive when you start adding them up.

jtsteph

@dillthekraut there is also "protokol" which outputs a stream of OSC values to a user-defined-length text file (for example 50 lines of osc values). I had the idea to read the stream with some kind of lightweight script and generate GUI status graphics with select extracted values. Might be a "later" project as I am loving the isadora grapher actor and it seems quite lightweight. As I am using Resolume for my video engine and Isadora for my logic, having a small isadora stage on my monitor with the grapher and a few doo-dads seems to add very little overhead.