ice Posted December 18, 2004 Report Share Posted December 18, 2004 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. Quote > 500 posts, time for a new T-shirt? Link to comment Share on other sites More sharing options...
Paul Posted December 18, 2004 Report Share Posted December 18, 2004 What do you mean by "disabled the autosave"? Which menu did you use to do this? Quote Link to comment Share on other sites More sharing options...
ice Posted December 19, 2004 Author Report Share Posted December 19, 2004 Ah eeeh, good question. I think I meant the recovery mode, but that of course has rather little to do with it. Problems remains though Quote > 500 posts, time for a new T-shirt? Link to comment Share on other sites More sharing options...
Paul Posted December 20, 2004 Report Share Posted December 20, 2004 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. Quote Link to comment Share on other sites More sharing options...
ice Posted December 20, 2004 Author Report Share Posted December 20, 2004 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. Quote > 500 posts, time for a new T-shirt? Link to comment Share on other sites More sharing options...
ice Posted January 4, 2005 Author Report Share Posted January 4, 2005 Any idea on a way to prevent this from happening? Maybe somekind of clever programming style? Quote > 500 posts, time for a new T-shirt? Link to comment Share on other sites More sharing options...
Paul Posted January 4, 2005 Report Share Posted January 4, 2005 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? Quote Link to comment Share on other sites More sharing options...
Laubfrosch Posted January 4, 2005 Report Share Posted January 4, 2005 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!!! Quote Sven Paulsen Klangfarbe Vienna   Link to comment Share on other sites More sharing options...
ice Posted January 4, 2005 Author Report Share Posted January 4, 2005 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! Quote > 500 posts, time for a new T-shirt? Link to comment Share on other sites More sharing options...
Paul Posted January 4, 2005 Report Share Posted January 4, 2005 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. Quote Link to comment Share on other sites More sharing options...
ice Posted January 4, 2005 Author Report Share Posted January 4, 2005 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? Quote > 500 posts, time for a new T-shirt? Link to comment Share on other sites More sharing options...
Paul Posted January 4, 2005 Report Share Posted January 4, 2005 Data can be removed from the palette for example by untagging a fixture. Quote Link to comment Share on other sites More sharing options...
Kirkup_xp Posted January 4, 2005 Report Share Posted January 4, 2005 In which case, an untagged fixture in a pallet would act as an untagged fixture when programming - ie its outputs wouldn't change with that memory (etc). Surely? Quote Peter Kirkup Link to comment Share on other sites More sharing options...
Paul Posted January 4, 2005 Report Share Posted January 4, 2005 >>>>>>>> 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. <<<<<<<< Quote Link to comment Share on other sites More sharing options...
Pipo Posted January 4, 2005 Report Share Posted January 4, 2005 So if you clear your pallettes, the memories made with those pallettes won't change? And if you reprogram the pallettes, then the memories will change? Right or wrong? Quote Den Pipo Pro Light Design Link to comment Share on other sites More sharing options...
Paul Posted January 4, 2005 Report Share Posted January 4, 2005 Correct! Remember to consider palettes on a fixture by fixture basis though. Â If you remove a fixture from a palette, your memories won't change. If you alter a fixture in a palette, your memories will change. Quote Link to comment Share on other sites More sharing options...
LeeStoddart Posted January 4, 2005 Report Share Posted January 4, 2005 >>>>>>>> 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: Quote Lee Stoddart Link to comment Share on other sites More sharing options...
Pipo Posted January 4, 2005 Report Share Posted January 4, 2005 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. Quote Den Pipo Pro Light Design Link to comment Share on other sites More sharing options...
ice Posted January 4, 2005 Author Report Share Posted January 4, 2005 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? Quote > 500 posts, time for a new T-shirt? Link to comment Share on other sites More sharing options...
Haytech Posted January 5, 2005 Report Share Posted January 5, 2005 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. Quote 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 More sharing options...
ice Posted January 5, 2005 Author Report Share Posted January 5, 2005 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? Quote > 500 posts, time for a new T-shirt? Link to comment Share on other sites More sharing options...
K-Nine Posted January 5, 2005 Report Share Posted January 5, 2005 Frog Reference No 5509 - Updating palettes - "Saving Show Please Wait" message appears frequently when it may not need to - to be investigated. Quote K-Nine : Technically Advanced Roving Dog In Space Bran Media | Myspace Link to comment Share on other sites More sharing options...
ice Posted January 5, 2005 Author Report Share Posted January 5, 2005 Maybe all the pallets could have a list of items which contain that pallet. That way the console doesn't have to search items that would change, but just look them up in the list. Quote > 500 posts, time for a new T-shirt? Link to comment Share on other sites More sharing options...
Paul Posted January 5, 2005 Report Share Posted January 5, 2005 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.