OSC limitations
-
Hello,
Since Mark mentioned with the newest release that there will be more updates, I thought I might talk about something which tickled me for some times: OSC listener limitations.It would be great to be able to entirely customize the listening address as well as getting more than only one argument for each message...The OSC sending part is pretty open, why isn't the listening part based on the same model?It's too bad to have to use a third party software to route OSC message into Isadora. It's also getting a bit messy when you have a lot a synchronisation btw two patches to only use /1 /2 etc adresses.Also, totally different topic but I might add it here in the same time... :)The limit scale value output works a bit in a weird way. It will show the correct mapped value, but won't be interpreted that way, unless you add a "+0" operation after...Is it caused by the type of value of the output?Well this is not such a big deal since there's a way around, but I can't think of a situation where you wouldn't like the output value to be correctly interpreted, so why not include this operation directly into the actor (Since this explanation might be unclear, I attached a picture which I hope, will make things limpid! :) )Otherwise Isadora is becoming really amazing! Thanks for everything!
-
The 'limit scale value' issue is a matter of the output range (example, min , max) being auto set to the 'out min' and 'out max'
You simply need to reset it to min, max and it will work as expected.What you can't do is dynamically change the out min' or 'out max', since it overrides the min,, max again.Your adding solution is probably the way to go for a dynamically set range.Re: OSC, you can have addresses that recieve multiple values. If /1 is receiving 4 values, then the 2nd will be on /2, the 3rd on /3, and the forth on /4 -
thanks @DusX
I'll keep using the same trick for the limit scale value then...For OSC, I doesn't seem to work that way since if I set a "OSC multitransmit" actor, sending local on Isadora/1, 3 values.Then i put 3 OSC listener on channels 1 2 and 3, the listener on channel one receive an info and gives a trigger but neither of the /2 and /3 does anything. If I send just one value still with the "OSC multitransmit", then the /1 receive the value properly...But anyway, what I meant was that It could be great for example to listen on address "particles/position/" and receive on that address arg[0],arg[1],arg[2] for the x,y and z coordinate for example. If it's just incrementing the output channel as you said previously, it doesn't have any advantage to me compare to using 3 different messages for each coordinate (which i'm doing now).Also the thing was to be a bit more open about adresses name in Isadora rather than being stucked with the isadora/1 nomenclature.It would help keep things a bit more organize when you start having 20-30 OSC adresses, and also using third party software just to "bridge" the OSC signal into Isadora, when some functions have assigned OSC adresses...I don't know how much of a change it would be on the development part for the Isadora team, but it would be great on my side for sure -
The port Number is the only set element... you can send on any channel name you like.
The attached image show sending OSC to '/tt/1' on port 1234 (where Isadora is set to listen), and receiving all 4 values of the message using the method I mentioned. I have added a feature request to extend the OSC detection to automatically create child settings in the stream dialog for multi value addresses.I hope this helps.
-
Thanks @DusX ! Shame on me I've never used this stream setup window...
That solves a part of my problem and with the feature request you added that will be perfect I guessThanks again!
