Lag in S5 that will not go away.

[Box on Rails]

First things first. I have copied this sequence to 3 different computers which all have plenty of processing power and all SSD drives but this sequence I have been working on takes at least 2 hours to Load and any editing that I have done take hours to finish making the changes. I was of the assumption it might be my computer but I have now moved this sequence to 2 other computers with the same result. I can't deal with this anymore. I have been working on this sequence for weeks and The more ME effects I add it just gets worse.  It is not the only sequence I had to deal with this lag. It has to be something in the software. all 3 computers with the same result. Is there any of you LOR software guys who I could send this sequence to and see what you get to happen. PM me please and I'll email it to you. I am pulling out my hair waiting for this crap to load and I'm bald. LOL. thanks for the help.

[dgrant]

Please open a ticket with LOR directly. They'll most likely ask you to email the sequence file to them so they can figure it out. Do you have any video files entered within a Movie  Motion Effect? Those will take longer but not like what you are describing. Also look at the task manager and see if its just the sequencer program that's slowing you down. Do yourself a favor too and check on the network tab of the task manager and see if its going nuts...which would indicate a hacking.

Edited May 25, 2022 by dgrant

[PhilMassey]

One other thing you might try is to set the Audio Info to Waveform Only in Sequence Information in the  Sequence menu. this will stop the calculation of audio spectrum data which can slow things down. Close and reopen the sequence for the change to take effect.

This is a per sequence setting and may be re enabled when you have finished sequencing if you need the spectrum data.

[TexasLights]

yes, open a ticket and send them the details.  It sounds a lot like an issue I had recently with a custom prop that had very large pixel mappings.   Once i reduced it down to a more manageable size the lag went away.

[k6ccc]

What is the physical side of the .loredit file?  i.e. how many megabytes?

 

[Box on Rails]

19 hours ago, dgrant said:

Please open a ticket with LOR directly. They'll most likely ask you to email the sequence file to them so they can figure it out. Do you have any video files entered within a Movie  Motion Effect? Those will take longer but not like what you are describing. Also look at the task manager and see if its just the sequencer program that's slowing you down. Do yourself a favor too and check on the network tab of the task manager and see if its going nuts...which would indicate a hacking.

I will open up a ticket today. There are no video files or animated Gifs in this sequence. I have used the task manager and it always shows the S5 program using a considerable percentage of resources and sometimes I get a "Program is not responding" message. at this point I end the task in the task manager and start over. 

[Box on Rails]

17 hours ago, k6ccc said:

What is the physical side of the .loredit file?  i.e. how many megabytes?

 

7.6M

[k6ccc]

1 hour ago, Box on Rails said:

sometimes I get a "Program is not responding" message. at this point I end the task in the task manager and start over. 

Generally there is not a need to kill a task that is "not responding".  A lot of tasks that have a lot of work to do in the background will show "not responding" for various periods of time while they are working on background tasks.  Just wait a bit and that will usually self clear.

 

[Jimehc]

I always assumed it was just me with the LOR software "Not Responding" it happens a lot.. On a system with 24GB of Memory and a 8 Core Processor... Software seems to Use less than 1GB memory and 25% of CPU

[TheDucks]

1 hour ago, Jimehc said:

I always assumed it was just me with the LOR software "Not Responding" it happens a lot.. On a system with 24GB of Memory and a 8 Core Processor... Software seems to Use less than 1GB memory and 25% of CPU

I don't think LOR makes use of 64bit capabilities (massive RAM), at least S4 does not. I get massive delays using S4 SE almost every action (animated Seq). Sometimes I see 'not responding', sometimes (rare) I see an hour glass. Mostly nothing until it is done doing whatever. FWIW it will collect a mouse click or keystroke, but no feedback until it performs that action.

For a Save, I see a  progress bar almost immediately, then it goes away for over a minute.

(HW: 3 AC, 5 CMB24, 1 Pixie8, 5 Pixie4. Pixies all have 100 nodes, but most will be reduced to 50 to make use of Resolution effects)

[PhilMassey]

From the help file, What's New for 5.6.0.

The Sequencer will now run as a 64-bit application on 64-bit versions of Windows. This means it can use more memory if necessary, allowing you to create larger sequences, control more lights, and/or have more sequences loaded at one time. 32-bit versions of Windows are still supported.

I tested this a while back and was able to load sequences until I ran out of memory at about 14GB. Previous versions would crash at around 5 GB.

[k6ccc]

10 hours ago, Box on Rails said:

7.6M

If a 7.6MB sequence is taking hours to save, there is something screwy with that file.  Matt will likely want to take a look at the file.  As a test, I took one of the sequences I have here, modified a Motion Effect row and then saved it.  It is a 32.6MB file and took 2.7 seconds on a Xeon E5-1603 based Windows 10 computer.

 

 

[dibblejr]

As previously stated earlier this month. It is mostly to due with the size of your custom props grid size. You can try to reduce the size by using the - / + button in the custom bulb placement grid. You will need to change all of them, this will help a tad. The most effective way to drastically reduce the time and you may not like this is to change your grid size to as small as possible and still be able to see your numbers. Once again, you will have to do it to every custom prop.

I personally had the same problem when I first started using S5 with all of my custom props. I made videos of it. Once I started making the grid small it all came together and I stopped experiencing the long load times.

Luckily for me I caught it early but I did have to re create all of the props I had previously built. It meant that when I wanted node numbers that had three digits I could only see 2. I also used a screen magnifier for my laptop.

If you watch the first minute of this video you will see how small my grid is. This was after I found the issue of the slow loading. 

JR

Edited May 27, 2022 by dibblejr

[Box on Rails]

9 hours ago, dibblejr said:

As previously stated earlier this month. It is mostly to due with the size of your custom props grid size. You can try to reduce the size by using the - / + button in the custom bulb placement grid. You will need to change all of them, this will help a tad. The most effective way to drastically reduce the time and you may not like this is to change your grid size to as small as possible and still be able to see your numbers. Once again, you will have to do it to every custom prop.

Jr  you are correct. This is what the help desk stated to me too. I didn't quite understand what you meant at first but the help desk broke it down for me. I sent them a copy of the sequence and they pointed out that there were some custom props that had a large grid number.  350 x 350. I am now in the process of reducing the grid value on at least 9 custom Props to get them under 75 x 75. It's gonna be a lot of work but well worth it and I'm glad I found this out now and not December 1st. I watched your singing face video and I do the exact same thing with my faces (I use 10 mouth positions/ME rows) with one exception. My Physical singing face props are broken down into 2 virtual props. I have the outline as one prop and the eyes and mouths are in there own prop with all of the motion effects rows for movement. The reason I have the outline on it's own prop is account I have the entire display in a group and I want only the outlines of the singing elements to be in that group. If I set up my singing faces Like you do as one prop with Motion effects rows and then add them to the entire display group. All of the pixels in the prop turn on when using that group including all of the mouth pixels. I have not found a way to assign only one motion effect in a prop to a specific group. I can only add the entire prop so this limitation has lead me to break down the singing props into multi props. Now I have been able to make motion effect rows inside a Group do what I want but only in some smaller Groups. My entire display group is to large to create custom Motion effects rows in that group. Once I reduce the props grid size I will see if that fixes the issue. Thanks for your input JR.

Kenny

[Jimehc]

So to be clear > is it the Grid Size ( Number of Columns/Width and Rows/Height  ) and not the Cell Size/Zoom Level using the - / + buttons ?? As the zoom level defaults back to normal, when the customization is reopened, even if it was saved showing a large grid block..

[Box on Rails]

21 hours ago, Jimehc said:

So to be clear > is it the Grid Size ( Number of Columns/Width and Rows/Height  ) and not the Cell Size/Zoom Level using the - / + buttons ?? As the zoom level defaults back to normal, when the customization is reopened, even if it was saved showing a large grid block..

Once I reduced the number of columns and rows the lag was minimal. one thing the LOR helpdesk said to help me understand what is going on in custom props makes a lot of  sense to me. even the blank cells in the grid view of the custom prop has a calculating factor here is what they said. "The problem actually lies in your preview, not your sequence. You have some unnecessarily large custom props in your display that are taking up all the calculation time - this would happen for any sequence you try to open that contains effects. I'll use C069 Face View 2 Eyes as an example. If you open that custom prop, you'll see that it only has 30 pixels, but it was drawn on an oversized 134x117 grid, which means that the sequence has to render a surface area of 15,678 pixels just to get an effect to show up on those 30 pixels of eyes. This same scenario is happening with multiple other props." 

In a nutshell this means that the software sees all the grid cells as a pixel whether they have a number assigned or not and has to calculate accordingly. If you use the Gilbert Engineering Spooky tree as I do, and you download their custom prop definition in S5, It will be 350 X 350 cells That means the software sees a 122,500 pixel grid for calculating the prop even though only 600 will show effects. That means there are 3 channels per pixel and the calculating factor for this prop would be 367,500 circuits. This is where the rendering lag was happening in my sequences. So to be clear It is not the size of the grid view, it is the number of Cells in the view. Reduce the number of cells and you will reduce the Rendering Lag.

Edited May 28, 2022 by Box on Rails

[Jimehc]

So the question is - why doesn't the software just ignore the empty cells...

I will also point out that when you select "Use Preview" as your group setting - if you increase the "Res" - it makes the effects less blockie (for lack of better word), but the processing time increases

[dibblejr]

12 hours ago, Jimehc said:

So the question is - why doesn't the software just ignore the empty cells...

I will also point out that when you select "Use Preview" as your group setting - if you increase the "Res" - it makes the effects less blockie (for lack of better word), but the processing time increases

That answer lies above from the answer in quotes from the HD.

I have heard the issue of resizing is being worked on. 

JR

[ebrown1972]

Size does matter

[Box on Rails]

7 hours ago, dibblejr said:

That answer lies above from the answer in quotes from the HD.

I have heard the issue of resizing is being worked on. 

JR

In my back and forth conversation with the help desk by email, this was also stated about this issue.

"As for the prop size, once you've created a grid in a custom prop, there's unfortunately no automatic button to reduce the size. There will be a slight improvement to this process in S6, but the Beta has not yet been released, and the production version will likely not be released until this fall."

This should mean a better process in editing and resizing for Custom prop setups. This also means for me in 2023 I will be busy transferring from S5 to S6. Maybe the S5 sequences will load right up with no transferring. just load an S5 sequence and then save as an S6. That would be nice.

Kenny