Response To Mark's Blog: Thread for Discussing the *NEW* Cue Number Function



  • Re: Mark's most recent Blog Post

    Hello All,

    I cannot overstate how excited I am at the prospect of Q#’s for Scenes in Isadora, so let me express it by writing down everything that springs to mind upon hearing about this exciting development. (I'm sure that I have typos below, but I'll come through and clean this up later.)

    I'd love to see any of the following:

    [EDIT: This is just a list of ideas I came up with, it is not a list of feature requests! This thread was created to see what the Community would like to see eventually. Which of these sound useful to you?]

    Actors:

    (I know some of these may be redundant/easy to program by oneself given a handful of new Q# actors and preexisting Isadora actors, but I’d definitely use Activate Scene by Q#, Jump By Q#, and Q# Comparator Actors in almost every project, so I feel it’s worth asking for them as native Isadora actors.)

    • Get Q# actor 
      • (as an addition to/adaptation of Get Scene Name, and would be nice to have Outputs for the Q# both as text and a value)
    • Current Q# actor 
      • (as an addition to/adaptation of Current Scene Number, and would be nice to have Outputs for the Q# both as text and a value.)
      • If this could output the previous Q# and next Q# as text and/or values, that would be extremely helpful
    • Activate Scene By Q# actor
    • Activate Scene Amount By Q# actor
    • Jump By Q# actor
      • Q# Jump++ actor
      • Q# Jump actor
    • Fire Next Q# actor
    • Fire Previous Q# actor
    • Re-Fire Current Q# actor
    • Q# List as Text actor
      • Outputs all Q#’s in Scene as separate text outputs
    • Q# List as Value actor
      • Outputs
    • Write Q# List to Text File actor
    • Q# Comparator actor
      • Compares current/last fired Q# to a specified Q#, with the math functions of a Comparator

    Functions:

    • Cue numbers that can go to the digits xxxx.xxx, or xxx.xx at the very least
      • The option to include individual Ports, Device IDs, Command Formats, Command Types, Cue Number (as text), Cue List, and Cue Path would be important for MIDI Show Control integration
      • It would be nice to be able to set these on a global level, but also to be able to have a manual override for oddball cues, (such as if you were sending all Lighting format MSC commands, but had one or two Pyrotechnic cues you wanted to hit without having to run them via the lighting desk via Isadora. 
        • (Starburst setups are easier to work with than master-to-slave-to-secondary-slave setups in my opinion.)
    • Being able to give Q#’s to Snapshots as well 
      • (and the ability to rename Snapshots)
      • What would also be amazing is being able to combine the Jump By Q# and jump into Scenes that contain the Snapshot with the sought-after Q# *and* start the Scene *in* that Snapshot. 
        • That seems like pie in the sky thinking, but I have found myself thinking in other instances that I’d love to be able to control, from outside a Scene, what Snapshot will be active when I enter that Scene.
    • Q# Functions added to Edit Go Triggers Menu
    • Q# Functions added to Cue Sheets as an option for something to trigger
      • It’d be even nicer if one could press a button to auto-populate the Cue Sheet with all existing Q#’s (even nicer if it could also read the Scene/Snapshot Name)
        • If linking the Cue Sheet and the Q#'s becomes automated, it'd be great to have a Q# Trigger actor, that would just trigger when that specific Q# is fired via the Cue Sheet or MIDI Show Control.
        • Perhaps it could interact with the theoretical Q# List as Text actor.

    Preferences/Setup/MIDI/OSC/Artnet

    • Something in preferences or MIDI Setup that would allow one to send MIDI Show Control every time a Q# is fired, or fire the matching Q# (if any) when a Q# is received via MSC.
      • MIDI SHOW CONTROL integration would be the top of my list in terms of priorities. I see it as the *most* crucial feature to add after Q#’s are added, (and after Jump/Activate Scene By Q# actors exist), as it will be crucial to make this feature easily interface and communicate with lighting desks and other DMX-controlled devices.
      • It would be nice to have a way to set one or more Ports, the Device ID, the Command Format, and the Command Type for the Scene Numbers in the menu. 
        • It would also be nice to be able to label each of the Devices one is sending MSC to or receiving MSC from. 
      • It would also be nice to have an actor like Capture Control, that would allow one to enable and disable this feature easily (which means the actor would pair well with Control Panels).
        • Being able to easily disable and re-enable MSC communication has proved to be key for me (so the light board doesn't drag me around to different Scene while I'm working on a break during tech). 
        • To this end, it would be nice to have an easy and quick way to enable and disable MSC Communication, either entirely, or to each device individually (for when there's one Master device and many Slave devices).
    • Option to output Current Q# as OSC
    • Option to output Current Q# via Artnet (maybe? Not super-familiar with it to be honest. Artnet Gurus, would this be helpful?)

    I’m sure that I’ll come up with more as I think about this further (sorry[?]).

    Best Wishes (and many thanks to @mark and the TroikaTronix Team for this exciting new prospective feature!),

    Woland (Lucas Wilson-Spiro)

    P.S. Please feel free to respond, add on, or suggest alternatives to anything I’ve mentioned.



  • Hi,

    Yes it is a really interesting development. The specific issue indicated by @mark about what happens to cue numbers when scenes are dragged dropped and copy pasted is an interesting design problem (if I am interpreting the issue correctly). I wonder if it is resolved by introducing a timeline function so that in some way cues are registered in sequence to duration? I have really moved away from linear scenes (particularly for audience interactive works and works that are not performance/theatre/stage focused) so I don't think that scenes should be locked to a timeline, however a cue system could be.

    cheers,

    bonemap



  • I admit that how Isadora handle cues is a bit dark for me, i've tryed to mess a bit while ago but with no noticeable results. What I would like to see in next release is an hybrid mode, linear and non linear. To archive this I my mind the easyer way is to have multiple time line. Each time line can contain it's own scenes controls and so on (so each time line is like a separate instance of Isadora). 

    what is important is to have a common place where all the time lines can notify what is active and what not (the only thing that i admire in qLab). Also scenes must have a unique name and goes into a sort of bin. 

    So more or less what i love to see is like QLC+ handle scenes, chasers and so on. Ok now that i wrote that i've realized that is impossible to do it if you want preserve retro compatibility... :-)



  • Hi,

    My personnal feeling about this:

    I would be very happy with a system like it's used in some lightdesks :

    - One Scene library, where you work like we used to in Isadora. You can create your scenes.

    - A playback sequencer, where each cue calls a scene.

    This way you can have in a project scenes that are not used in the playback ( because you don't use them anymore or because you don't use them yet )

    Fade times should be linked to the sequencer, so you can use two times a scene with different fade times.

    It should be possible to "save as" a scene, in case you end up modifying a bit a scene and want to duplicate it.

    That involves a saving procedure in scenes, that I would find nice.

    Of course we can then think about a playback sequencer integrating multiple timelines, that I think would be a massive plus for isadora.

    I think that's a good way to handle heavy projects, where during production you might want to clean your sequencer, without completly erasing some scenes you've been working on.

    Mehdi



  • @keftaparty 

    Is this sequencer idea something you can explain in a bit more detail? Or is there a particular piece of hardware we can investigate as an example?

    Best Wishes,
    Mark


  • Tech Staff

    @keftaparty

    Do you imagine a "scenes" bin sort of like a media bin? Or like a "cast" in director?



  • Hi,

    let's say something like :

    - The scenes list becomes vertical, DusX you're right, it's a bin. One can think about online and/or offline editor etc...

    - The actual horizontal scene list becomes a place where you can drag&drop scenes. When you insert a scene, you create a Cue.

    Fade times and/or automations are linked to Cues, not to Scenes.

    If you have scenes that you don't use you don't need to destroy them. If you use a scene several times 

    Of course than you have the wish that this horizontal list grows to several layers, with automations and keyframes, but that's an other story...

    Best,

    Mehdi



  • Hi,

    I am thinking of a show/hide timeline interface element that appears across the area of the Isadora UI that currently just has the Scene List. There could be an option for three states 1. just the scene list (as currently exists) 2. both scene list and timeline cue editor 3. just a timeline cue editor. The timeline is playable with a playback indicator (play, pause, stop, jump forward, jump back) and is the master controller for sequencing/cueing scene playback. The interface can be selected to use the master timeline and cue system playback or reverted to the scene activate/deactivate buttons and triggers as currently exists.

    The timeline cue editor could have a stackable series of selectable and duplicatable temporal displays (layer channels) that allow trigger/cue points to be incorporated along it. For example a graphical representation of a specified audio track that can be overlaid with action points or trigger cues associated with time/frame callibration indicators along the timeline. A Bezier channel layer that can be manipulated into ramps and wave patterns that send corresponding data to an output actor and/or external device. A color sequencer that outputs to a color actor providing changes against the playback head in the timeline and can also be output to dmx protocol. Each channel has a network output option that has a selectable set of parameters to send protocol messages from the timeline to external equipment or an internal actor etc. etc. And of course a master cue list channel that transitions between scenes using any of a number of different internal/external triggering options (as is already current in Isadora but might be extended).

    Associated actors would be listening for cue states to be able to differentiate their active status and the timeline cue channel can be triggered (internally or externally) to activate and deactivate multiple scenes simultaneously or in a staggered sequence.

    cheers

    bonemap



  • Hi,

    I find this very exciting!

    I agree with @keftaparty and the playback sequencer or a cue index. I've done a few shows where I've needed to control Isadora via Midi show control from a lighting desk. I've had to create a Background scene that would be active throughout the show to act as a cue index. The Midi show control listener would receive the cue number then compare that to the index and then using the Jump By Name actor that another user created (I can't remember who offhand - sorry about that) Isadora would fire the corresponding cue in any order as per the lighting cues. In this instance the timing of the cues was written in the background scene (in the JumpByName actor). It would be great to have a cue list that auto-populates and will allow you to update the timing in either the cue list or in the scene editor. (If the infrastructure that currently exists for the go trigger timing could update to a cue list and be changed in either location that would be grand).

    Very exciting indeed!

    Cheers,

    Cam.


Log in to reply
 

Looks like your connection to TroikaTronix Community Forum was lost, please wait while we try to reconnect.