Transition Starting Event?

[Joe Fitzpatrick]

Hi,

Last week a friend asked if I could put together a way for him to control OBS Studio via DMX (a lighting control protocol) and Art-Net (a protocol for sending DMX over an ethernet connection). Overall, it came together quite quickly. I already have a DMX and Art-Net engine that I put together that can be built for OS X, Linux, and Windows, (http://scrootchme.com/x2/) so I created an OBS plugin.

I'm not sure if I did this the correct way, but I linked to both libobs and lib_frontend_api. Triggering scene changes using the frontend api was very straight forward, as was triggering the transport controls (recording start/stop, etc.) Audio Mixer control was slightly trickier. I ended up creating 5 obs_fader instances. Then, in response to the first OBS_FRONTEND_EVENT_SCENE_CHANGED event, I enumerated the sources and attached those faders to the Mic/Aux and Desktop Audio sources that exist. Mapping the DMX input onto the obs_fader deflection then appears to control the UI mixer well.

The only thing that I was not able to figure out was how to remotely control the transition time, at least not in a way that is friendly to the existing UI. That mechanism seems internal to the main window handling itself. If I missed something, I'd appreciate someone letting me know.

But my main question actually came up today. In helping my friend setup DMX control it occurred to both of us that the reverse could be quite useful. I already created a Tool Menu triggered settings dialog to configure the DMX base channel and Art-Net in subnet, etc. for remote control. Providing a mechanism to map Scenes (by name) to lighting cues is very easy. But you would normally like lighting transitions to the start of a scene change, but the existing frontend api events only appear to signal when a transition has finished and a scene change is complete.

It seems like this is a an obvious gap in the FrontEnd API events, but it also appears that I should be able to to get the event activity I need with signals from obs_core and/or specific objects. But since scenes can be nested and reused it is not clear to me what the cleanest mechanism is to observe. I think that I am only interested in the highest level scene/source changes. But when I add a signal handler for source_transition_start, source_transition_stop, and source_activate, the order and count of messages I output to the log is a bit baffling. I guess part of my confusion is it seems that I need to include obs-internal.h to make conditional decisions that I want to make based on the triggered signals. For long term compatibility, etc., this seems like something best avoided. Any feedback anyone could provide in this area would be most appreciated. Sorry for the long post!

 

[Joe Fitzpatrick]

OK, I had a few minutes this afternoon, so I confirmed the following does work on all three platforms:

- Get the list of available transitions
- Register the "transition_start" signal for each transition
- When signaled, get the "source" param (the transition)
- Use obs_transition_get_source for the OBS_TRANSITION_SOURCE_B
- Use obs_source_get_name to recover the name of the scene being transitioned to
- Trigger my DMX cue change from the name association

FWIW, I never could get source_transition_start to signal from the OBS core and couldn't find a usage example in the source.

If there is a better way to do this, I'd appreciate hearing about it.

 

[Joe Fitzpatrick]

A couple of follow up notes to the two posts above:

- To adjust transition duration I ended up getting the MainWindow pointer with obs_frontend_get_main_window(), casting it to a QMainWindow *, then finding the Qt QSpinBox widget by name and adjusting it.

The code ended up looking something like this (note, obsSource is just an RAII style self releasing wrapper I put together for sources)

            // Fixed?
            obsSource transition = obs_frontend_get_current_transition();
            if (! obs_transition_fixed (transition))
            {
                blog (LOG_INFO, "Setting duration to: %d", duration);
                QMainWindow* window = (QMainWindow*)obs_frontend_get_main_window();
                QSpinBox* control = window->findChild<QSpinBox*> ("transitionDuration");
                   
                if (control)
                    control->setValue (duration);
            }

- OBS_TRANSITION_SOURCE_B is not a good mechanism to find the current scene being transitioned to in Studio mode. The sources have empty names (at least on OS X) and the pointers won't match any of the sources in the scene list. If you want to assume that the user is using the buttons studio mode you could get the current preview scene, but that doesn't work with modules calling obs_frontend_set_current_scene(), so I ended up conditionally calling obs_frontend_get_current_scene(). This seems to work on all three platforms, but doesn't seem very robust or safe.

This appears to work inside the same transition_start signal registered with every Transition in the transition list.

        obsSource target;
       
        if (obs_frontend_preview_program_mode_active())
            target = obs_frontend_get_current_scene();
        else
        {
            obs_source_t* source = (obs_source_t*)calldata_ptr (cd, "source");
            target = obs_transition_get_source (source, OBS_TRANSITION_SOURCE_B);
        }
        blog (LOG_INFO, "[DMX] %s", target.getName().toRawUTF8());

- The way the standard audio sources come into existence is a bit unusual. You might have noticed that they don't always show up in the same order in the Mixer. I ended up finding them by name. However, this means you have to keep track of localization settings in your module, then get the strings for "Basic.DesktopDevice1", "Basic.AuxDevice1", etc. in the obs_studio current localization file.

Again, this doesn't seem particularly robust or portable, but it works.

I've just given the DMX plugin to a couple of OBS users that requested it. Once they've rung it out for a bit I'll post it in the plug-ins section here.

 

[braverock]

A couple of follow up notes to the two posts above:
I've just given the DMX plugin to a couple of OBS users that requested it. Once they've rung it out for a bit I'll post it in the plug-ins section here.

Did any sort of DMX bridge code ever get posted for OBS ?

I've considered using something like OLA to do this:

https://www.openlighting.org/ola/advanced-topics/ola-dmx-trigger/

I'd like to have a physical controller attached to control sources and filters, and maybe scenes.