When linking to a new cue list from a cue in another cue list all existing values go to zero/home

is there an allfade flag on the first cue of the second cuelist?

Thanks for the suggestion that was initially what I thought it must be but there wasn't the all fade flag as far as I could tell.

To make sure there was nothing complicated I created a new show with 1 light patched. Created cue 1/1 that turned it on and set link to 2/1 which was a completely empty cue. Press GO light comes on press GO again light goes off :(

(EOS 2.5.2.9.0.8)

Hi Mike,

Simply put...what's happening is you're linking a cue from another cue which is only going to playback what is in that linked that cue.
With Cue 1/1 loaded on the Master, have you tried [Cue] [2/1] [Execute] [Enter]?

Best,
Johnny

This is currently the expected behaviour with links.
I assume you want to keep both list active.

The only work around is to Manually override this by using load.
To do this have both list mapped to faders on a fader page. So for example have list 1 and 2 mapped on faders 1/1 & 1/2.

You can have list 1 mapped on the Master fader and keep pressing Go.
If you now want list 2 on the Master Fader you have to Shift+Load on the master fader, this will just Unmap the master Go from list 1, then Load List 2/X.
The next Go on the master will just play list 2 on top of list 1.

Sadly this is not very flexible at the moment and this is the only work around.

Nick,

Thanks for this, it works, brilliant.

I'd actually been doing that process with macros from a magic sheet rather than the simple link in my example.

BUT the bit that I'd missed out on was unloading the master fader before loading it with the new cue list. It seems that step makes it store the current values back with the cue list on the other fader rather than forgetting them when you move to the next cue list.

I've added the "Fader Master_User 1 Mapped_To " to unload the master fader, to the front of my macros and it works.

Thanks, Nick. Very good to know. I've made a test show file and it works great. I appreciate the support and shared knowledge. :)

We had it working differently in 2.4 beta (last summer) but not everyone agreed on the changed and it returned back to the current behaviour.
We're still trying to find a solution without needing to do the unmap as long as the list are living on a fader page somewhere.

All this wouldn't fix the link though, I'd like to have this as an option and just manage channels being own by a lists.

Hopefully after we have fixed the mapping issue we can revisit the links 4 years down the road.

Glad you got something to work.

It is a little weird as it kind of breaks the whole "move fade" philosophy, in that the behaviour is as if I had put an all fade on the first cue of the list.

What really got me was any manual light movements were reset on the move to the new cue list, which made it pretty impossible to handle a transition between one song and another if you had each song in a new cue list. I had a semi fix with doing a capture on the lights which were likely to be manual and un capturing them before a cue that wanted to change them, but that was hard work. I'd also had some success with a make manual of all lights and a release just prior to the cue list change with a background cue list with all lights cued to something in it, that kind of transfered the current values to the background cue and then I could do the link, but it required the make manual macro adding to the cue before the link and then the release to be added to the cue with the link.

An ideal solution would be if an attribute could be added to any link to say don't do what the manual says "In general applications, the entire contents of the cue (both moves and tracks) will be asserted on an out-of-sequence cue." as even within a cue list this can be a pain. I had to move to using separate cue lists as parts of the show I wanted to be moving moving heads from cues and part was adlib busked movements, and if there was a cue that had values for the light when I linked (looping through a set of cues for a song type) the desk would track back to the earlier cue in some other song and do something annoying to the moving head.

So a don't assert on link would be a very nice attribute to have against a link, if any developers are listening :)

Anyway your solution works great although the macro is a little annoying as you can only record it and not edit it in as codes it as "Fader_Load Master_User Cue 11 10000" and both the 11 and the 10000 are single symbol not what you get if you type them in, if you type it you get Cue 1 1 1 0 0 0 0 which obviously doesn't work. So I cant just copy the macro and change the cue list number from 11 to 12 and so on. Don't know if there is a magic button I can press that says treat all of what I type as a single symbol?

Are you using Capture Mode (double hit Capture) this will capture any channels that become manual so you don't need to select them.
Sneak Enter then just releases them.

I can assure you I've spent many hours, days, weeks trying to change Eos multi cue list rules.

I don't know why it's releasing manual channels which aren't owned by the new list, sorry this isn't something I run into but justed look at it.

We need different rules if you're managing your cuelists by owning channels and having them mapped to faders, and other rules if you're not.
We had different behaviour in 2.4 beta for a good few months and then it was removed at the very end. I don't think this behaviour would be different with manual values.