• I'm looking for an alternative for receiving midi notes from qlab for triggering specific scenes.

    I currently have a user actor with note-on actors that listens to specific pitces that then trigger a specific jump actor. It did not take too long to program and it's easily updated for each scene.
    I have the user actor in all scenes, and is working great, except that the more instances I have in the patch, the longer it takes for isadora to save the .izz file. It now takes over 10 seconds and the program is frozen during that time. 
    MSC Watcher seems to receive the cue as text, so I'm not sure how to convert that to a number without bloating the user actor.
    I submitted that as a bug but I'm wondering what is a more elegant way to link midi  triggers to individual scenes
    I'm on windows 8 isa 2.1

  • Dear @LPmode,
    Well, the MSC Watcher receives the cue as text because that's how the midi specification defines it. To quote:
    "Q_number, Q_list and Q_path are expressed as ASCII numbers 0-9 (encoded as 30H-39H) with the ASCII decimal point character (2EH) used to delineate subsections."
    The reason I didn't just convert this to a number, is to allow the possibility to distinguish these cue numbers
    Arguably, they are not the same. But converting them to a floating point number would yield the same result, making those two cues indistinguishable.
    Still, it's pretty easy to use a Parse Text actor to convert the text into a floating point number. Just beware of rounding errors. You can enter this into the Text Parser actor
    Then, assuming you'll never use more than one decimal, multiply by 10 to get an integer that can be used to jump.
    Best Wishes,

  • Tank you Mark, It's what I was looking for.

    I also remembered the jump_by_name actor posted here. I think that's the easiest. I'll only need to update the MSC cues in qlab 

  • I have a similar, although different, problem, but I have it with the Send MSC actor. The problem is that the "Cue number" input is expecting a number, so in fact cue numbers 123.4 and 123.40 become the same cue.

    I'm using this actor to control a Lanbox LCX. Of course, an easy work-around is to not record any cues that end in zero, but I'm wondering if there's another solution. BTW, I already reported this bug.