OSC multiple listener issues

ian

Hi all,

I'm working on a data-intensive project that involves about 200 OSC channels that each transmit a time-synced data packet of 18 values that drive visual generation elements. The packets are generated on the local machine via a python script that provides the interface with an AWS database, and then are sent locally to Isadora.

In prototyping the project for the first 50 packets I've run into a three issues with the OSC multiple listener.

1) data received in a listener is sometimes offset by 1 channel number from the channel number specified in the Stream setup. For example a channel called /sensor20 is set in stream setup to start at OSC channel 20. In the OSC multiple listener the first data value for the packet is only received if the starting channel is placed at 19, while the channel address shows on the listener at channel 20.

2) Special value types not transmitted for unixtime and MAC addresses: The multiple listener will only display the first few digits (and irregularily) unix second or millisecond values when included in an OSC packet, and when a MAC address is encoded will only display the first two characters regardless of how encoded.

3) The most significant issue is having just discovered the 800 channel limit - Is there a way to get around that? I have approximately 200 "addresses" of data (which in other OSC implementations would be a channel), but as Isadora splits the into a channel per value that means the project will consume ~ 3600 isadora OSC channels.

If that is a hard limit work around suggestions are most welcome. While it is desirable to work in OSC (data is also being sent to max-msp) the data source is a dynamoDB json stream, so perhaps we could be sending a json to izzy instead.

thanks for thoughts,

Working with izzy 3.2.6 on OSX 13.6.

happy to share more details

Best

Ian

bonemap

@ian

You might want to use json or request/access to the current beta version that has a new OSC Address Listener module.

Best wishes

Russell

Woland

@ian said:

1) data received in a listener is sometimes offset by 1 channel number from the channel number specified in the Stream setup. For example a channel called /sensor20 is set in stream setup to start at OSC channel 20. In the OSC multiple listener the first data value for the packet is only received if the starting channel is placed at 19, while the channel address shows on the listener at channel 20.

This is the first thing I think of when I read this is that the 'show addr' input might be in play here, but I'm not sure.

@ian said:

2) Special value types not transmitted for unixtime and MAC addresses

Forgive me if it's a silly question, but what do you mean by 'special value types'. OSC Listeners can have the types integer, float, and text. As far as I can tell, 'integer' should cover unixtime, and 'text' should cover MAC addresses.

@ian said:

The multiple listener will only display the first few digits (and irregularily) unix second or millisecond values when included in an OSC packet, and when a MAC address is encoded will only display the first two characters regardless of how encoded.

With the 'type' input of the OSC Multi Listener set to 'text', floats, text (e.g. MAC addresses), and integers (e.g. unixtime) all come out fine as text (gif example) then you can use a JavaScript actor or this User Actor (included in this patch) shown in the screenshot below to convert the text version of floats and integers back to floats and integers:

As for the issue with MAC addresses, I'm not having trouble sending or receiving MAC addresses in the different formats I tried in the patch linked above. How specifically are you encoding them? Can you give some examples of the format you're using so I can try to reproduce the issue? Is it possible that maybe there's something in your Python code that's truncating it?

@ian said:

3) The most significant issue is having just discovered the 800 channel limit - Is there a way to get around that? I have approximately 200 "addresses" of data (which in other OSC implementations would be a channel), but as Isadora splits the into a channel per value that means the project will consume ~ 3600 isadora OSC channels.

As a beta tester you have access to the OSC Address Listener plugin which should solve your channel limit issue. (I sent you a DM with a link.)

The packets are generated on the local machine via a python script that provides the interface with an AWS database, and then are sent locally to Isadora.

Also as a beta tester, you have access to the Pythoner plugin which, depending on your use case, may make it so that you don't need to transport anything over OSC.

Best wishes,

Woland

ian

@woland and @bonemap Thanks so much!

I'll dig into the suggestions and the OSC Address Listener over the weekend and report back.

ian

@woland

Thanks so much for the referral to the new address listener. That's totally resolved the channel and address shortage issue, and delighted that brings Izzy in line with the packets I'm sending to the other apps running OSC.

- on the old multiple listener issue of MAC ID's not being passed- your workaround of force-stetting the multi-listener to text, then converting the text back to number worked for me. The listener was auto-setting to the first item in the list - typically a float, and then any item that was not a float was not being output. In any case, that is resolved with the new address listener.

- I can keep investigating the old multi-listener channel offset issue if helpful for TT, but the new address listener is such an improvement(!) I wouldn't otherwise bother.