• State Not Answered
  • Date
    CONGO Kid
  • Date
  • Replies 5 replies
  • Subscribers 56 subscribers
  • Views 3954 views
  • Users 0 members are here

How to take priority on a template's parameter via sACN input ?

Hello, 

Sorry in advance if I make some mistakes, english isn't my native language.

I worked succesfully on a VVVV program allowing the user to easily calibrate multiple moving lights, in order to follow together an actor with a mouse, tactile screen or camera tracking. It controls only pan/tilt and is acting like a pointing device, and not like a control software.

The program is generating  a sACN stream, wich reach the "Artnet" Input of my Congo Junior's Cobalt without problem.

BUT : The sACN is re-interpreted by the console with its own patch and triggers channels instead of outputs. I tried to work around by attributing channels to the pan/tilt outputs in the outputs list, but since the moving head's template is blocking its outputs, the channels are effectless. 

Here I must precise that I don't want to delete the templates and work with a straight patch, because the light designers must be able to control the others parameters of the moving heads (color, focus, blades, etc..) via the console the way they are used to, and because my modest program isn't able to do so and is only designed to point the beams.

Sooooo... the question :  is there a way to setup the templates in order to allow the channels to take control, LTP style ?

OR to setup the "Artnet Input" (wich is in fact a E1.31 input) to be merged with the console DMX stream, with higher priority or LTP ?

Thankful for your time, and hoping, 

R.D.

  • 0
    Hi R.D.,

    Is your program trying to pass the pan/tilt information to the Congo jr. to store in presets/palettes or are you just wanting to take control of pan/tilt while the console retains other parameter control?

    If you are wanting to have the console record the data, setting it up as an input to control the channels is the only way to do that via sACN. (You could look at OSC commands instead if you want to control the channel's attributes so the console can store the data.)

    If you are wanting to take control of the pan/tilt parameters away from the console just for your program, I would recommend that you look at having both your program and the console on the network with an sACN gateway and implementing per address priority (0xDD start code) packets in your sACN code. That way, you could send data at a higher priority for the addresses you want to control and no data (or data at a 0 priority) to the addresses you want the console to retain control over.

    Hope that helps,
    Kirk
  • 0 in reply to starksk
    Hello Kirk,
    Thank you for your quick answer. As you wrote it, my purpose is to take control of the pan/tilt and let the other parameters to the console. And yes, ideally, I wish the console could record the data.
    I've already set up a merger with LTP priority, and I can take the control of the heads apart from the Cobalt, I even take the data from the console via Artnet to determinate the actual position to have a smooth transition when the computer take over, but it can work only one way, and doesn't allow the recording.
    I played with OSC in a previous project in wich the console and a video computer sent data both ways, and it seems that there is a big limitation on the Cobalt in this matter : you can only control the board. I mean, if you want to change a parameter, the device must be selected, so there is no way to control 2 moving heads (or any multiple devices) at the same time with different values, and that's precisely what I intend to do with my program.
    So I must understand that there is no way to do neither of my fisrt thoughts (merging or take over the parameters by the channels) ?
    Thank you again,

    R.D.
  • 0 in reply to CONGO Kid
    Hi R.D.,

    You are correct that inherently it is a choice between one or the other. If sending streams of OSC (one for each channel & parameter) is not responsive enough, you could look at a solution that combines the two methods.
    Use your program with sACN values going directly to the fixtures to handle the live moves and then also send an OSC command to update the console as to the current position at intervals or on demand so that when you execute the record action on the console, it knows the position of the fixtures at that moment. Recording is always a snapshot in time, so you only really need to have the console know where the fixture is at the time of the record action.
  • 0 in reply to CONGO Kid

    (This isn't Art-Net, which is good because Art-Net could never do this due to protocol limitations - the generic term is "DMX-over-Ethernet".)

    The DMX-over-Ethernet protocol you're using is E1.31 (sACN).

    Merging is best done by per-channel-priority on the network - set the "special" controller to a higher priority than the console for the specific DMX addresses you need.
    - You can read the pan/tilt values from the console by having the "special" controller ignore itself when reading the network DMX levels, and thus fade nicely to and from the console and the "special" controller.

    You're right that this approach alone wouldn't allow the console the record the values, as it doesn't know what they are.

    In order to record them into the console:
    Use OSC to select the channels one at a time, and update their Pan/Tilt parameters:
    Select channel 1, set values, then select channel 2 etc.

    You could do that to record a "snapshot" of the Pan/Tilt values for all the fixtures.

  • 0 in reply to starksk
    Hi again,

    Ok, nevermind. I'll try a mixed OSC/sACN option, but it's not really what I expected.
    Thank you so much for your answers.
    Regards.

    R.D.
Related

www.etcconnect.com