Experiencing a lot of lag while editing.

[NCSLLC]

Not sure if anyone else have experienced this in Qlab, but I've been experiencing a lot of lag while editing my project in Qlab. I'm talking about trying to select cues and dragging and dropping audio files into the program.  Sometimes I'll try and select 3-5 cues and it'll take a full 5 seconds before the program will highlight them. 

Not entirely sure why this is happening. The project I am working on does have a lot of cues (currently at 2500, was at 3500 before I went in and deleted a lot of unnecessary cues) and I'm not sure if that's what's slowing down Qlab. Does anyone else experience lag with projects that have a large amount of cues?

I've noticed that restarting my computer can sometimes help. I do have a bad habit of simply putting my computer to sleep and not actually shutting it down for long periods of time.

Using a monitoring software I do notice that when using Qlab it is using 100% of my CPU at times. My lapto is fairly new 16" Macbook Pro 2019, 2.4 GHz 8-Core Intel Core i9.

I have reached out to Qlab support, but didn't wasn't able to find a solution that worked. Figure 53 referred me to this link to prepare my computer. It didn't really help. My project doesn't have problems executing cues. Editing is simply a hassle because trying to highlight or edit cues can have a 5 second delay every time I try to do something.

[heddesweden]

I have a project with 1500 cues and it is snappy and there are no problem to edit it on my new MacBook Pro.

I had similar issues that you describe when I use some plugins. It takes around 10 seconds to load. 

Some plugins are smooth, but others gives me lag. 

SPL Hawkeye is one of those I have to avoid in QLab, but the similar Nugen Analyzer gives me no problem. You have to try out witch plugins/developers that QLab likes to coexist with.

Do you use any plugins in your QLab Workspace?

Best wishes, Erik

[NCSLLC]

The only plugins I have installed are from Izotope, however I don't use them in my programming at all. I do use some of the Apple provided plugins but there are only 5 instances of that.

[jimsta...@zoho.com]

I have experienced latency on what became the editing machine, a 2014 Macbook 13. Not using third-party plugins, but Apple plugins use processing power too.

On that machine I wait through the spinning colour wheel of death (just don't look), save, then restart.

Jim

[sam kusnetz]

Hi there

The workspace you shared with the support team had timeline-mode Group cues nested several layers deep, and it was our theory that this is causing a lot of extra overhead when working in the cue list.

While this is certainly something that can be improved upon in QLab, I think it's important to say that we think we know what the problem is and we think we know how your can work around it, which is to reduce the number of levels deep that you nest timeline-mode Group cues.

Best

Sam 

[NCSLLC]

Decided to test nesting a lot of timeline group cues. And it indeed really lagged.

It's a bit unfortunate because timeline cues are a great tool that I in my programming for organization as well as triggering multiple cues simultaneously. I'll definitely spend some time going through my current project and try to "unnest" these cues.

I've noticed that when selecting multiple group cues, we're unable to change the mode quickly. I need to individually select the group cue and change it's mode. Any word if this will come in a future update?

[jimsta...@zoho.com]

Great info, Sam.

  This is likely key to my situation too. I have quite a few groups within groups.

My show itself was a parent group, easily removed. Crossfade loops are two levels of nesting inside a song group which, if it has a reprise or visuals prior, are in another group.

DOH!

Nested groups make show changes much easier when the set is re-ordered, or a song or part of the song gets a new version at the last minute.

Fortunately the problem is not as noticeable on the newer show machines.

Jim

[m...@stevensokulski.com]

My gut says you might be able to simplify this by using start cues inside of the timeline to trigger other, parallel timelines. I haven't tested performance on that, but it seems like a way forward that wouldn't require you to totally rethink your show file.

[Sam Kusnetz]

Hello

It's a bit unfortunate because timeline cues are a great tool that I in my programming for organization as well as triggering multiple cues simultaneously. I'll definitely spend some time going through my current project and try to "unnest" these cues.

Well, you can call it unfortunate if you want to. From my perspective, timeline mode Group cues offer a lot of flexibility, and that flexibility comes with small drawbacks. Having sluggish UI behavior when nesting large numbers of timeline mode Groups several layers deep certainly isn’t ideal, but there is no measurable impact on the actual playback of those cues, so it feels like a pretty reasonable compromise to me.

As I’ve said before, this is absolutely an area of QLab that we’d like to improve upon. It’s just a matter of balancing the time spent on the many hundreds of other things we like to do as well.

I've noticed that when selecting multiple group cues, we're unable to change the mode quickly. I need to individually select the group cue and change it's mode. Any word if this will come in a future update?

We periodically update and expand QLab’s ability to “batch edit” multiple selected cues of the same time. I don’t know that we have a specific goal of adding batch edit to the Mode tab of Group cue inspectors, but I’ll make sure I add it to the list.

Until then, you can do this:

1. Create a Network cue patched to send OSC messages to “localhost”, port 5300. This is the default network patch for new workspaces.
2. Create a Network cue with the OSC message “/cue/selected/mode 2"
3. Set a hotkey trigger for that Network cue.
4. Select all the Groups that you want to convert from timeline mode to start-first-go-next mode.
5. Hit the hotkey.

Mode 1 sets start-first-and-enter mode, mode 3 sets timeline mode, and mode 4 sets start-random mode.

Best
Sam

––
Sam Kusnetz [he/him/his] (what is this?)
Figure 53
https://qlab.app | https://figure53.com

On Jan 26, 2021, 4:50 PM -0500, NCSLLC <nc...@tavernoftales.com>, wrote:

Decided to test nesting a lot of timeline group cues. And it indeed really lagged.

<Screen Shot 2021-01-26 at 4.42.37 PM.png>

 --

Contact support anytime: sup...@figure53.com

Follow QLab on Twitter: https://twitter.com/QLabApp

User Group Code of Conduct: https://qlab.app/code-of-conduct/

---

You received this message because you are subscribed to the Google Groups "QLab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/1ae17617-bcc9-435d-a6ae-a87308f16c41n%40googlegroups.com.

[NCSLLC]

After some experimentation of removing as many nested cues as possible I did see a little improvement. But as I reach the higher cue numbers (3800 right now) I'm starting to experience a lot of the same lag again. 

I noticed that despite the intense lag from the program my laptop's cpu load was barely breaking a sweat. For reference I'm using a 16" Macbook Pro 2019.

2.4 GHz 8-Core Intel Core i9

64 GB 2667 MHz DDR4

While using the program Activity Monitor reports that 90% of the cpu is Idle and there is about 43 free memory going unused. I actually tried to make Qlab a higher priority by following these terminal instructions. But that did not change anything. Is there a way to make Qlab use up more CPU and Ram? Or am I wrong to think that it is where the lag is coming from?

[Chris Ashworth]

Hi NCSLLC,

If the lag is being caused by UI updates, those must be done on the “main” thread, which can run on only one CPU, so extra CPU and RAM power won’t help.

Thus, if you’re working in a context that is hitting the limitation that Sam described previously, the two primary options are for us to change how the UI updates happen to reduce the CPU load in this specific case, or for you to avoid creating the cuing structure that exposes this limitation of the current UI code.

-C

[Erik Rosales]

Hi everybody, I have had a similar problem. My question in this case is, if it is the timeline view that is causing this problem. The root of the slower UI? If so, would it be possible to have a toggle switch to treat nested cues as a timeline. Also, when I saw your last post Chris, its obvious, that it doesn't matter how many cores or ram you have to somehow fix this matter. Will future versions of QLab be able to use more than one core?

Now for my way of solving this problem. Our latest show runs thee different QLab projects. I first made one show file, but ended up having one project for lights, one for sound and one for midi/osc/scripts. I also made a transition to Vezer for one specific light sequence where QLab was struggling to keep up with the timing (I recorded the DMX from QLab, only running this part in our show). I also tried to run QLab 3, but had a lot of trouble firing OSC cues, since there is no way of changing the OSC port (would love to have that as an option by the way). No matter if I was running a complete fresh install of Mojave or if tons of other programs was running made any differens by the way... I think this is a big issue when people start to build more complex shows in years to come.

Question about my setup. Are the different QLab projects somehow using different cores? Or why is there such a big difference in performance when running 3 different projects? When I translated the show to QLab 3 everything was butter smooth (whole show except lights). 

All the best and looking forward to more insight in this matter : ) 

[Chris Ashworth]

Hi Erik,

Clarifying a few separate things:

1) Just making sure that we’re all talking specifically about nested timeline groups — if folks are having a lag when no nested timelines are involved we’d like to learn about that.

2) We suspect resolving this particular issue is a matter of polishing some of the code that drives how timeline groups are redrawn.

3) QLab will use as many cores and as much RAM as you have available. The limit for CPU cores that I mentioned is only about drawing the UI, which is a limitation of the underlying macOS. macOS does not allow doing UI interaction or drawing anywhere but the main thread.

4) It is difficult for me to know what was happening in your workspace without looking at the workspace, but if QLab was having trouble with a heavy or fast-moving light sequence, then I can offer a guess: in cases where other products offer single lighting “effects” (such as chases, etc.) QLab can currently only offer the creation of sequences of lots of tightly timed cues. When there are a lot of such cues, the cuing structure of QLab (triggering redraws for each individual row, among other examples) can be heavy related to the speed required by the underlying cues. So these are cases where it is currently possible to accidentally hit performance limits that you won’t normally see with most other cueing structures. As we continue to work on lighting, such as working on purpose-built lighting effects or further optimizing the kinds of workspaces people build for lighting, I believe it will help address those kinds of limitations.

-C

[Erik Rosales]

Thanks for such a quick response : )

1) Yes my problem was occurring when I had a nested structure of the cues. We tried to un-nest the cues and the UI was instantly quicker. Still strange that 3 different projects (trigging each other) runs better than one thou, right?

2) Sweeed : D

3) Makes sense...

4) For me the speed difference in running QLab 3 and 4 is significant. Im not sure where the difference starts to show but my general experience running QLab 3 was that I never had any speed issues. When I was trying to solve the issue we had with our latest show I stumbled upon an app called ArtNet Recorder (witch had other issues when running a show, therefor Vezer ended up running in our show). ArtNet Recorder runs the recorded DMX as a small file (like a midi file) and never had any issues to compute or run the DMX sequences. Would that be an option, to somehow pre-process a DMX show file, and play the data in a non changeable manner... Having purpose-built light effects sounds like a great leap forward as well! 

-Erik

[Sam Kusnetz]

4) For me the speed difference in running QLab 3 and 4 is significant. Im not sure where the difference starts to show but my general experience running QLab 3 was that I never had any speed issues.

Erik

Do you experience the same speed difference between QLab 3 and QLab 4 without including Light cues at all? That is to say, if you run the *exact* same workspace in both QLab 3 and QLab 4, do you experience a noticeable issue? If yes, can you describe the symptoms? What is slower in QLab 4? Is it a problem when preparing a workspace, performing it, or both?

The more we know, the more likely we can address it.

Best
Sam

[NCSLLC]

| 1) Just making sure that we’re all talking specifically about nested timeline groups — if folks are having a lag when no nested timelines are involved we’d like to learn about that.

Chris, I did remove a lot of nested groups (both timeline and not) from my current workspace and am still experience lag editing. I still have the version of the workspace with all the nested group cues as well.  I sent an email through my old support ticket, but could share both versions with the team.

| Now for my way of solving this problem. Our latest show runs thee different QLab projects. 

I never considered this and may have to try it myself. How did you get one workspace to trigger a cue in another workspace?

[Christopher Ashworth]

(mobile)

> On Feb 4, 2021, at 11:15 AM, NCSLLC <nc...@tavernoftales.com> wrote:
>
> | 1) Just making sure that we’re all talking specifically about nested timeline groups — if folks are having a lag when no nested timelines are involved we’d like to learn about that.

>
> Chris, I did remove a lot of nested groups (both timeline and not) from my current workspace and am still experience lag editing. I still have the version of the workspace with all the nested group cues as well. I sent an email through my old support ticket, but could share both versions with the team.

Thanks! Seeing both could help us understand what might be at the root.

>
> | Now for my way of solving this problem. Our latest show runs thee different QLab projects.
> I never considered this and may have to try it myself. How did you get one workspace to trigger a cue in another workspace?

I would like to gently discourage this approach. One computer running three separate workspaces will definitely use more resources than running all the same cues in one workspace.

C

[Erik Rosales]

Correct Sam. I tried to find the second best OSC/Midi sequencer, and it turned up to be QLab3 : )

So I copied all the Cues except for the light cues from the main project and pasted them in to a QLab3 project. The QLab3 project was way more snappy than QLab4.

I sent you different videos of this problem in April last year:

http://tiny.cc/QLab_Lights_Problem

http://tiny.cc/QLab_Lights_Problem

http://tiny.cc/QLab_Day3

And my final solution was to run 3 different QLab projects as I mentioned. I would have wanted to run QLab 3 and 4 side by side, but the OSC port mapping was creating to much trouble since both was listening to 53000...

And the thee different projects was trigging each other via Midi. A quite clumsy way of working around this problem. And yes Chris. I don't like this solution either... Id love to be able to run the show within one project. But as you see in the videos above, the situation was not great so to say.

Hope its more clear now : )

[Erik Rosales]

Sorry for all deleted posts . My linked videos were not working the way I wanted...  (isn't there a way to just edit your post anymore, so you don't need to delete the post to have it changed?)

http://tiny.cc/QLab_Lights_Problem

http://tiny.cc/QLab_Lights_Update

http://tiny.cc/QLab_Day3

Here are the three final links

All the best. Erik

[Sam Kusnetz]

On Feb 5, 2021, 7:34 AM -0500, ql...@googlegroups.com, wrote:

Correct Sam. I tried to find the second best OSC/Midi sequencer, and it turned up to be QLab3 : )

So I copied all the Cues except for the light cues from the main project and pasted them in to a QLab3 project. The QLab3 project was way more snappy than QLab4.

Hi Erik

So here’s the point I’m trying to make: in your setup, QLab 3 isn’t running many hundreds of Light cues, but QLab 4 is. So of course QLab 3 is faster in this case; it’s doing much, much less work.

My expectation is that if you open the EXACT same workspace with the EXACT same cues in QLab 3 and QLab 4, you will see very nearly identical performance. If that’s not true, then we can talk about it. But if that is true, then you’re really just saying “when I take all the Light cues out of my workspace, QLab runs faster,” to which my answer is: YES! Light cues require CPU cycles, and you use quite a lot of Light cues!

I want to make sure I’m clear about these two things also:

1. I love when people use QLab creatively, and I love when they talk about it here, and I even love when they talk about the problems they have.
2. I agree that there is a lot of room for improvement in QLab’s performance vis a vis Light cue playback and UI behavior for workspaces with lots of cues, especially timeline-mode Group cues.

So I’m really not trying to shrug anything off or to dismiss a problem. I’m only saying that this specific comparison between QLab 3 and QLab 4 is not very accurate and does not really help solve the problem.

I am thrilled that you use QLab so hard. I think it’s people like you that help make QLab great, so please don’t stop! Let’s keep talking and working together.

All my best
Sam