OSC API changes discussion

[DougLawes]

Hello,

I am attempting to control the ATEM production studio 4K through Ableton. I am running a midi network (Mac to Mac) and have midi notes being picked up by OSCulator. I can even see the notes being sent to atemOSC but I keep getting a log error “Cannot handle command: /atem/transition/auto”. Tried several other commands with the same response. I think it may be a null value? Running atemOSC 2.5.3 (1), ATEM 7.4, and Osculator 3.1.2

[DougLawes]

Got it working! Now my current issue is atemOSC crashes whenever I run the command “atem/dsk/on-air/0” the variant “1” works no problem

[DougLawes]

My first issue was a port routing. Set input to 3333 and out to 9000

[SteffeyDev]

Sorry for not responding, I didn't see this come in for some reason. The DSK crash makes sense from the code, though I have no idea why there is no validation on the input. DSK 1 is controlled via /atem/dsk/on-air/1, DSK 2 via /atem/dsk/on-air/2, and so on. If you looked closely on the Readme, you'd see at the bottom of the DSK section where it says

Where $i can be 1, 2, 3, or 4 depending on the capability of your ATEM switcher

Easy to miss though, considering the size of the documentation. Do you have any other issues?

[dappertutto]

I see one general confusion with the OSC syntax. Sometimes, as in on/off air, there is a value bound to the address, and other points, like /atem/program/1 are unbound and interpreted in contrast to other unbound addresses.

It might generally be a good idea to always use bound addresses whose values determine the functionality.

E.g. /atem/program 1 /atem/program 2 /atem/program 3 (etc)

[SteffeyDev]

So generally I always agree with that logic. I believe atemOSC was originally built with TouchOSC in mind, which only sends float values, so it was easier to embed the “values” into the address at that time. By pure-OSC standards, I agree that it would be better to separate out the “values” from the address, though we have to remain backwards compatible for a while. I’ve overhauled the DSK/USK API for what I think it should be per OSC standards, and will definately do the same for the rest of the API when I have the chance. However, with limited time and a lot of other desired features, it is hard to justify currently.

[SteffeyDev]

Actually, an issue with your proposed syntax is that even on more modern OSC clients like Open Stage Control, you can’t map one address to more than one toggle. So if I want the program button to be a toggle, each “button” must have a unique address for feedback purposes.

[dappertutto]

Would you say the strength of OSC lies in its flexibility? Generally we can adapt from one programs OSC syntax to the next as far as its ability to support lists, unboundedness, etc. There's a number of programs that I deal with (touchOSC, qlc+, atemOSC, isadora) and each requires a little bit of futzing with. My primary program for control is Max software, and in particular, a set of externals employed within it called 'odot' which relies on a quite robust set of tools to address functionality of a bundle of osc data. This serves as my glue for making the right connections for each program,

I think odots conventions is what drives my 'boundedness attitude'. No problem if atemOSC stays as is! I'm grateful for this program, truly! ps- open stage control looks cool!

[SteffeyDev]

@dappertutto atemOSC v3.0.0 now allows for /atem/preview <int> as you suggested above, along with many other type changes to be more flexible. Closing this, as it is old and should all be addressed by now. Open a new issue for future concerns in this area.