Jump to content
Vari-Lite Controls Support Forum

Loading times


ice

Recommended Posts

I'm working on a somewhat standard showfile for our rig. I've programmed about 200kb of data into my show, everything works fine. The issue is that when I re-program for instance a position pallet, the console starts saving the show again. That fine, but it takes about a minute or so, and it happens every 2 or 3 times I alter something. No need to tell you that's rather annoying. Is there any way to prevent this? I've already disabled the autosave, but that doesn't seem to help a bit.

> 500 posts, time for a new T-shirt? ;)

Link to comment
Share on other sites

Recovery mode only stores the following states:

 

- current screen

- current and next memory numbers

- submaster page and overlay

- SX button states (Mambo only)

 

When you are editing memories/submasters/SXs/palettes, the changes are stored in a battery backed RAM inside the desk. When this buffer fills up, the desk flushes the changes to internal FLASH memory, which is when you see the "saving show please wait" message.

 

When you edit a palette, this can result in changes to alot of data, which would quickly fill up the RAM buffer and force the flush to FLASH memory.

Link to comment
Share on other sites

That might be the problem... to avoid a lot of work I programmed position pallets, and used those in the scenes/chases. So there's about 15 pallets used in over 50 scenes and chases... Changing one pallet could indeed alter some more scenes and chase-steps, therefore filling the RAM and the desk would flush it...

 

So if I get where you're going there's really nothing I can do to prevent this? It really sucks because actions which would normally take about 10 minutes now take a good half hour because of all the flushing.

> 500 posts, time for a new T-shirt? ;)

Link to comment
Share on other sites

  • 2 weeks later...

Extract from the specification:

 

>>>>>>>>

Clearing Referenced Palettes

If fixture data programmed in a palette is changed to “unprogrammed†or a palette is cleared – for any memories / submasters / SXs which referenced the data in the palette – the palette reference will be replaced by the actual DMX value in the palette before the data in the palette is cleared.

<<<<<<<<

 

This is the reason that the desk needs to check all memories / submasters / SXs when a palette is reprogrammed, which then causes the RAM buffer to be filled up quickly. I can't immediately think of a way of programming around this I'm afraid.

 

However if you could propose an alternative behaviour to that described above, for when referenced palettes are reprogrammed, then it might get looked at in a future software release. Perhaps memories / submasters / SX's could be ignored when palettes are reprogrammed, and if you delete something from a palette that was referenced elsewhere, it's just tough luck, and nothing will be output when that memory / submaster / SX is replayed. Would this be acceptable, or seen as a bug?

Link to comment
Share on other sites

Hi Paul,

 

hmmmmmm :?: :!:

 

I think killing the relation between memories and palettes, is a downgrade and makes the palette to a "live edit function" only.

 

Please keep the software in it´s specs as it is.

 

cheers

 

Sven

 

P.S.: A happy nu 2k5 to all frogfreaks!!! :lol:

Sven Paulsen

Klangfarbe Vienna

 

 

Link to comment
Share on other sites

If I get this right the console works like this:

 

- you program a pallet

- you program that pallet into a memory, the desk knows that and programs a reference to that pallet, as well as the pallet values.

- you re-program that same pallet

- the desk starts searching all items for a reference to that pallet and reprograms all items were that reference was found

- you end up waiting.

 

There is a really simple way of avoiding this using OOP;

- program a pallet; the desk makes an instance of a "position" class containing all options at memory address X

- program a memory; the position pallet gets programmed so it contains only a reference to the same instance of "position" (so it points to memory X)

- reprogramming the pallet will update (or overwrite) the instance @ X and therefore update data in all memories.

- at playback time the console gets the references position data (X) and therefore gets updated values.

 

I hope this makes sense? I'm afraid if you didn't program like this a software update wouldn't be possible because that's gonna take loads of work.

 

Maybe you could give us a little explanation of the coding style that was used? Like a sequence diagram or something...

 

Oh; killing that link is no option by the way, it's the only way available to keep your programming clean and simple. Otherwise I should reprogram all memories, and that takes a lot more time than waiting for the buffer to clean out!

> 500 posts, time for a new T-shirt? ;)

Link to comment
Share on other sites

The problem is not the data that is in the palette, this is referenced as you say.

 

The problem is the data that might have been removed from the palette. This is why the desk has to search all memories / submasters / SXs that reference the palette.

Link to comment
Share on other sites

If data was removed from the pallet that was caused by the user pressing "clear" I think? I never do that :)

 

If it's nicely referenced, updating it would only cause an update of the pallet, so searching isn't necessary at all I think?

> 500 posts, time for a new T-shirt? ;)

Link to comment
Share on other sites

>>>>>>>>

Clearing Referenced Palettes

If fixture data programmed in a palette is changed to “unprogrammed†or a palette is cleared – for any memories / submasters / SXs which referenced the data in the palette – the palette reference will be replaced by the actual DMX value in the palette before the data in the palette is cleared.

<<<<<<<<

Link to comment
Share on other sites

>>>>>>>>

Clearing Referenced Palettes

If fixture data programmed in a palette is changed to “unprogrammed†or a palette is cleared – for any memories / submasters / SXs which referenced the data in the palette – the palette reference will be replaced by the actual DMX value in the palette before the data in the palette is cleared.

<<<<<<<<

 

 

 

If I understand the specification you want the result of removing something from a pallette to leave all memories / submasters / SXs in the same state as they would have been had you not made the removal.

 

However, consider the situation where some thing is removed and later re-instated - the link to the palette has been destroyed so any subsequent edits to the pallete won't have effect.

 

Perhaps as an example... we have four fixtures, Colour Palette 1 sets all four fixtures to green, Colour Palette 2 sets all four to blue and Colour Palette 2 sets all four to yellow.

 

If memory 1 sets all four fixtures to open white

memory 2 sets all four to colour palette 1 (green)

memory 3 sets all four to colour palette 2 (blue)

 

If Colour Palette 1 is edited such that the colour is CYAN rather than Green and (by mistake) fixture 4 is untagged the current specification would change memory 2 such that three fixtures referenced colour pallete 1 (cyan) and the fourth fixture had the dmx value for green. Editing the pallete to include fixture 4 will obviously not correct the problem in memory 2 as the reference has been removed.

 

My preference would be that the reference to the pallete be retained but that on execution no output happens (for fixture 4 in this example) That would remove the requirement to look for palette references on changes.

 

Perhaps there could be an option on editing the palette - retain previous effect of removed parameters.

 

Of course it could be possible that there is a bug in the code which is doing this search for references even when the changes made are NEITHER untag NOR clear. :wink:

Lee Stoddart

Link to comment
Share on other sites

Perhaps there could be an option on editing the palette - retain previous effect of removed parameters

 

I think the onboard memory is too small to keep record of all changes.

 

Saving a large showfile takes already enough time.

Den Pipo

Pro Light Design

Link to comment
Share on other sites

Yeah I don't really know how, but this should be done diferently. For instance the software could check if fixture data was deleted (cleared or untagges), and if not: just alter the pallet and leave the rest alone. I guess that would save some time right? Now you've mentioned that, I don't really know if I programmed everything or just some fixtures in the pallets.

Is there any way to find out which fixture were programmed? If I select all (untagged) fixtures, and bring up a pallet, will only the fixutures affected be tagged again?

> 500 posts, time for a new T-shirt? ;)

Link to comment
Share on other sites

and bring up a pallet, will only the fixutures affected be tagged again?

Happy new year Ice,

No, all fixtures that are tagged will be affected by the pallette call.

I.E. 6 MAC 500 Color is setted to open stored on pallette 1

all Color is setted to red sored on pallette 2

now home color data for all fixtures tag fixture 2, 4, 6 press p2 and violá

Mac 2,4 and 6 are red.

This circumstance is very useful as you can store one pallatte for each color

for all fixtures used.

Sebastian H.

Pro - Sound Showtechnik

The secret to creativity is knowing how to hide your sources.

Albert Einstein

"You can get a lot more done with a kind word and a gun"

Al Capone

Link to comment
Share on other sites

I think you mis-read my question :)

 

I mean: program a pallet using only fixtures 1&2. Now home data and make sure that no fixtures were tagged. Now select fixtures 1,2&3 and bring up the pallet. Will only fixtures 1&2 be tagged, or will all fixtures be affected? The 3'rd one should also stay at the home parameters right?

> 500 posts, time for a new T-shirt? ;)

Link to comment
Share on other sites

It's not the searching that takes the time. It's the commiting of memory/submaster/SX edits from the battery backed RAM buffer to the Flash memory if data has been removed from the palette. It might be that the desk is thinking that data has been removed when it hasn't, and is hence making more work for itself than it needs to. This is what we shall investigate.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.