Free OSC !

[Juriaan]

Hi there all,

As a Isadora ("Pro") user I always hit my head against one User Experience design decision, and that is the necessary "Stream Setup" Window to receive OSC commands.

The products that I work with (ETC Lighting desk / Resolume / Abelton) all support some great OSC feedback that I wish to receive, and use some Javascript on to take the OSC address apart, analyse that and use it in patch to provide some great actors that work with 'feedback'.

What do I propose ?

A new OSC Actor that allows us on the input to set an OSC Wildcard address, on the output the value and the OSC Address that was received and a small trigger output for when you receive a new message.

Case
For example let's take a look at the case below :

At the moment I'm using a MIDI Faderport 8 Controller that I wish to use with Isadora as a Faderdesk for ETC Nomad for an upcoming performance, basically I'm trying to program my controller to control all the programs that I currently have :) Nice right ? The thing is that Isadora is a bit a pain with the Stream Setup window. 

Why ?

Well, ETCNOMAD is sending the following for each single faderbank

/eos/fader/[PAGE]/[FADER]/name = (string) [NAME] 

If you have 5 pages with 10 faders each that is already 50 values that you have to 'set' at the Stream Setup window, and also 50 OSC Receive Actors (!!) that all needs to be correctly stripped to know which fader / bank it actually was..

[Maxime]

@Juriaan YES YES YES!

[celiomenard]

HI

first I'm sorry for my bad English....

I don't have EOS to test but I saw on Eos website that Eos use multiargumentation for osc

I try with another soft to send osc adress (/eos/fader/[PAGE]/[FADER]/name = (string) [NAME]

So, on Isadora you could use only one stream setup as : /eos/fader   you could choose channel 1 for example

you could use 3 osc listener

the first one is oneos fader.izz channel 1 and receive the first argument who is an integer one (number of page)

the second one is on two channel (because there is another argument, Isadora understand that) and receive the second argument who is an integer one too (number of fader)

the third one is on three channel and receive the third argument who is an text one (name of the page)

you could find a patch with that.

in theory it's the good method.

have a nice day.

Célio

[Fred]

@juriaan Yes, parsing OSC commands would be amazing, and very useful.

[Maxime]

@celiomenard yes you can add up to 16 arguments to OSC messages, and you can indeed get it that way in Isadora, but it means that you need to create 16 listeners to get one entire OSC messages with all of its arguments, which I agree with @Juriaan is quite annoying.

Also if you work with al lot of OSC messages, with different numbers of arguments, it can become quite hard to remember what is what (especially you can't even separate the stream setup window to check out... but let's not suggest alternative solutions to what we want to get :) )

I usually create meaningful OSC addresses, then it would be easy to keep track of what is what by having an osc address input ("/eos/fader" for example) with the number of arguments you want to get.

@Fred I've seen your thread on OSC Query, I agree it would be great, but i feel a full OSC listener actor would achieve that easily and would be more versatile.

[celiomenard]

@Maxime 

my answer was just to find a solution for the problem of Eos fader page for juriann and to show that he don't have to have 50 osc receive actors.

but I'm agree it could be more easy to have an osc multilistener  like the osc multitransmit.

all the best.

Célio

[Fred]

@maxime both would be best. The OSCQuery suggestion is a little different as it gives the advantage of becoming a widely used standard and getting access to web based interfaces that can be shared easily. Either of these solutions has a similar problem though, that is if you have a multi listener, you need to scan for OSC messages with multiple data payloads, identify them and parse them internally to know what they are, then they can be broken out. Without a total re-write I would guess that this would still leave us with the stream setup, but addresses with multiple payloads could then be accessed by a multi-listener.

[Maxime]

@Fred well I vote for both as well :)