Why OSC input uses a stream setup and no direct address as for osc transmit?

[Bennnid]

Hi ( and sorry if I'm the 1234's person to ask but I looked a bit in search engin and couldn't find it ) 
> I am sorry if my remark seems disrespectful, but I m so happy with isa that I would like to understand it better or help making it evolve...

I find it quite complicated to use stream setup window instead of a direct input with an actor specifying the address, so as osc transmit does...

- this could open more flexibility to workflow and modularity with text input to change osc in with other actors
I'm often banging my head on the keyboard cos: 

- sometimes you have to add an old osc controller you already have a macro for, but your patch already uses the stream setup numbers for other controlls, 
- sometimes you wanna share an osc controller + patch with someone and sort function doesn't give the same numbers so copying is loosing time and making loads of mistake risk
- sometimes you don't remember the controller number you are patching and you need to open stream setup window once again to know who s who

I'm sure there are good reasons about it , but I 'd like  to know them before asking a feature request, 

Sincerely deep thanks for your work ! 
best regards

[bonemap]

@bennnid

I agree - it would be good to have more flexibility when working with OSC streams.

It would be great if the stream setup could be accessible/viewable while the scene editor is active. For example as a floating window like the Stage Setup. 

There are some important efficiencies with the Stream Setup, such as auto detect, and a viewable list of all available incoming data sources. I would not want to forfeit any of the current setup features except that they are stuck in a fixed dropdown interface that does not float and can not be accessed simultaneously with an active scene editor.

Additional features like being able to save and export a particular stream setup configuration, being able to append saved routing settings to new setups etc might add more pro functionality.

The big one for me is being able to reference the stream setup while patching in the scene editor. 

On projects with lots of OSC addresses I have resorted to the annoying option of getting a screen grab of the stream set up and placing it as a background image into Controls and using a control/scene editor split window. This can be further compounded if the stream list extends beyond the window that requires scrolling.

Best wishes

Russell

[liminal_andy]

@bonemap building off of your thoughts, I think it will be essential to divorce the OSC payloads from the addresses when assigning channel numbers. In ZoomOSC, for example, there are often variable numbers of payloads on a given OSC message depending on how many users are online, for example, and some patches made with small Zoom calls in mind have broken because the OSC channel assignments are too close together and the payloads being as numerous as they are cause a data overrun.  

I understand the advantage of mapping OSC addresses to channels, just not sure that the payloads should be part of that system moving forward. 

[bonemap]

@liminal_andy said:

I understand the advantage of mapping OSC addresses to channels, just not sure that the payloads should be part of that system moving forward

 Hi Andy,

RIght! I can see your point with dynamic payloads. I assume that a system that accommodates the issue you are describing will require associating direct osc input address within the scene editor. I wonder if there is a 'best of both worlds' approach?

Best WIshes

Russell   

[liminal_andy]

@bonemap For me, all I would change in step 1 of re-imagining the flow of live input to Isadora would be to allow channel numbers to be assigned to OSC addresses, and then have the OSC (multi) listener select the number of payloads to parse, not the number of channels to subscribe to. In the scene, I can use the context of the job the patch is doing and the flow of data into my actors to decide how many payloads should be parsed off of the OSC message corresponding to a channel. 

This keeps the easy re-use and global changing capabilities of the current channel system but prevents the argument parser from being partially locked away to a system that cannot change based on runtime circumstances. 

EDIT: It would also be handy (as you are all discussing) to have an OSC listener that did not require the channel system, which, when used, is the equivalent of saying, "I accept the loss of remapping functionality in exchange for being able to change this at runtime, and I understand I am responsible for implementing my own global values if I want to make propagating changes to this value." Maybe it requires you to input your initials as well to sign consent agreement for the actor :p

[Bennnid]

@bonemap
to me a stream setup window could be floating ( as you said)  and autodetect input ( as now), great! (+ 1 for the import/export osc assignation)
but the "must" could be that the number set in osc listener input, could pull the osc name of corresponding stream set up number and auto copy the address (already autodetected) in another input field,
giving you the choice of using number or text address, and allowing to have more clarity within the patch (read address on the box) ( still thinking about mistakes we make reading/copying values for identifiers).

further more If you have a patch with too many numbers to manage IDs of values.. 
for ex: Matrix Value s-r, brodcaster/listener, get-set global value, (which you can name with characters though)

 It becomes really a lot of numbers to identify flux...

Another idea : osc listener could autofill the name if you start entering it, copying from an embed oscmonitor (like floating stream setup with no numbers),
and have a kind of bold writing when fully correct or stay gray if not matching the monitor, so that you would never think again, "did I misspell something?".

so the patch would display the info without being obliged to copy the full adress.

(another topic on the way, is there a board listing all controllers from control panel and their link? )

[bonemap]

@bennnid, @liminal_andy,

Yes, I can see that more precise flexible/identification of channels would be of benefit. 

The MultiOSC Listener was updated in Isadora 3 (or was it 2.6) to incorporate the input address through a toggle input on the actor.

This actor can be used to provide a reference for all of the active channels that have been assigned channel numbers in the stream setup - so this was a good step forward at the time.

The following appear to be the things that would be good to address if there was going to be any changes to OSC streams in Isadora:

• that there is no way of dynamically assigning channels within the scene editor
• channels that have dynamic lengths (as identified by Andy) are not accommodated in the current method and potentially cause malfunction
• appending new input sources requires reentering the stream setup and assigning channel numbers (could this be automated so that the stream setup expands dynamically?)
• moving a stream setup to another Isadora file or attempting to share a stream setup can mean losing all of the channel mapping previously assigned through the stream setup

Is there anything else?

Best wishes

Russell

[liminal_andy]

@bonemap maybe support for partial match on the address? So we can make OSC logic trees to spare some nodes?

[bonemap]

@liminal_andy said:

support for partial match on the address

 Yes, that is a great suggestion

Best WIshes

Russell