[LOGGED] OSC Query and Isadoras interface building

[Fred]

OSCquery spec is released and it could be a great thing for Isadora. You can see a bit about the project here:

https://github.com/Vidvox/OSCQ...

It has been well implemented in a number of applications, some videos below.

After thinking about how this could implement in Isadora, and reflecting on using a lot of other media software, I had a thought. A lot of other software works with the idea that you may want access to any parameter from any place. Isadora has its own method requiring us to add osc inputs, midi inputs or keyboard inputs to get access to controls outside, or in addition to then add interface components, (which I feel look really dated and I don't like to give to clients).

The approach that so many softwares use (and this is for a good reason) is to start with the assumption that it is highly likely you want to attach parameters to outside controls. Rather than having to build a chain to get to these parameters and then connect them to outside control (and I am no fan of the stream setup), it would be great to be able to right click any parameter anywhere and choose to make it interact with an external protocol. I feel this would instantly make isadora more popular and up to date. Isadora is great but really comes to life when it talks to other software and hardware, it should be ready and willing to communicate with other devices and tools out of the box, (which it kind of is, but it is not as intuitive as other software).

Coupled with OSCQuery this would mean we could very fast make interfaces outside of Isadora, and because of the way the structure is made, these can be bidirectional, So multiple devices could send data to a parameter and it would be updated independently on a web page that would allow many users and devices to interface with it at once. And the controls look more modern than Isadoras.

I know there are a lot of feature requests out there, for all sorts of things, but I wanted to see if anyone else thought right click access to any input or output parameter for connecting to external data sources or inputs was something anyone else thought to be a good idea. I guess the mad mapper structure (which is not all unique in the field) is a good example.

Here is a mockup:

[Woland]

@fred

Please marry me.

[mark_m]

@woland said:

@fred
Please marry me.

 You like his suggestion then, Lucas?

[bonemap]

@fred said:

in addition to then add interface components, (which I feel look really dated and I don't like to give to clients).

 There are a number of underlying concerns in your pitch. And you raise some of the niggling structural issues that regularly get comments by Isadora users. There was a robust discussion by the 2.6 beta testers about accessing OSC addresses more efficiently in Isadora, particularly from within the Isadora work area. As a result the OSC Multi Listner was implemented with a switch to display OSC pathnames within the body of the node. So this was a step towards a more convenient approach to working with a large volume of OSC connectivity points. 

Taking the in-patch direction a quantum leap further and making each node inherently and readily capable of addressing outgoing/incoming OSC/midi/TCP/UDP/serial/Net Broadcaster pathnames at any parameter variable, is certainly a game changer. It would represent a serious innovation in what the software represents and how it will interface within the ecology of applications typically used in a media and performance production. 

I believe it would require the addition of a combined in/out management panel that allowed sequential access and editable lists of external/internal connectivity points with a ‘go to node’ function that highlights and brings into focus the associated actor.

The connectivity panel would need to be a floating panel (not a dropdown from the Isadora frame) so that it can be always accessible and viewable beside the patch bay as connectivity points are being programmed in an actor.

In addition, an actor with an existing connection could be analogously coloured to indicate that the connection exists and coloured again if the connection is viable/active.

Presently, there is no continuity in the way each type of connectivity point is dealt with in Isadora. It appears that this is due to the ad hoc development of each connectivity feature. Currently Discrete control panels appear in many different places and forms. And some of these only coalesce in a monitor window. However, colocating the management of all node connectivity points would add productivity and nibbleness to the process, particularly when setting up and running a production in-situation.

I hear @Fred ‘s comments directed at the visual style of the Isadora control panel elements.

Best wishes

Bonemap