PDA

View Full Version : EMEMs



SteveSpaw
01-21-2013, 03:46 PM
One thing that I really miss and could use are "emems"
I really could use the ability to save and recall snapshots of the switcher setups.
Both full recalls and individual areas such as Vitual layers, Auxes and DDR's and Graphics.
The ablility to preload and have ready different material for different show segment would be great. I am actually surprised that it is not there.

Thanks,
Steve

SBowie
01-21-2013, 04:09 PM
Just fyi - 8000 has 'snapshot' macros for exactly this purpose. Apart from that, note that the session structure also does most of that, with the exception of specific Switcher setups.

kltv
01-21-2013, 06:55 PM
One thing that I really miss and could use are "emems"
I really could use the ability to save and recall snapshots of the switcher setups.
Both full recalls and individual areas such as Vitual layers, Auxes and DDR's and Graphics.
The ablility to preload and have ready different material for different show segment would be great. I am actually surprised that it is not there.

Thanks,
Steve

Some of this is possible in the 8000, with a combination of a few things. Even in the 850/5 & 450/5 you can save and recall presets for your Virtual Inputs, DDR, Graphics and Audio Mixer setups. Those can be saved using the little fly-out presets on the sides of the bins. They can also be recalled that way and recall the setups of the media players and virtual inputs. They can also be saved and imported into different sessions if you need to. You can't do this with the main switcher itself though. In 8000, I believe you could do a snapshot macro that recalled a combination of those setups and get most of what you are trying to do accomplished.

There is a big difference in 8000 macros compared to E-MEMS though. The 8000 macros remember button pushes, not necessarily button states. That does make it potentially difficult to setup the switcher from a potentially unknown state. For example, turning a keyer on while recording the macro records the action of pushing the button, not the state you put it in. So if you run a macro record and capture "DSK 1 TAKE" going from the off to on position, that doesn't mean it always turns the keyer on, no matter what state it was in before. So that same macro could have a different result, depending on what the keyer state is. Basically, it pushes the button, it doesn't say "turn the keyer on" if that makes sense...

Kris

SBowie
01-21-2013, 07:13 PM
I think some, though perhaps not all, of this can be addressed by combining system macros, but that's a good point nonetheless.

SteveSpaw
01-22-2013, 08:20 AM
But, the Fly out bin cannot call clips (DDRs and Graphics) to be loaded can they? That is really the point, that certain "presets" could be loaded for the next show segment. This would include the states of next transition modifiers.
And the process of recording or programming some macro is not realistic, no one would use it. I should just be a simple two button Save and Recall switcher state.

Steve

SBowie
01-22-2013, 09:49 AM
But, the Fly out bin cannot call clips (DDRs and Graphics) to be loaded can they?Unless I miss your meaning, that's exactly what they do.


And the process of recording or programming some macro is not realistic, no one would use it.Well, it's not really particularly onerous to record a macro. You just click Record, set the Switcher state you want, click Stop, and change the playback mode for the macro to Snapshot. You're going to have to set the state and click "Save" anyway, so honestly, your suggested workflow only eliminates two clicks. That said, I do think you're right that "Save Switcher Setup" could be made a lot simpler. This is the first iteration of macros on a TriCaster; I wouldn't suggest it's mature yet. (This is also setting aside Kris's note re: storing states versus simple toggles - haven't had a chance to review that yet, and suspect it may be a bit of a mixed bag at the moment.)

Just to mention it again, btw, sessions do store all of this and more already - though recalling them requires existing live production for a few moments.

SteveSpaw
01-22-2013, 10:32 AM
I meant to say load select clips in the players, the Fly out bins don't do that do they? I will have to look again if they do, I would not expect this and I may say that this is bad if they do, I would hate to be loading clips when I was just looking for a certain clip.

Ok on loading sessions, I understand the issue of changing resolutions, but the idea of "file Open" in a same resolution session is not a bad idea, like an EMEM recall everything except the program bus.

SBowie
01-22-2013, 10:43 AM
I meant to say load select clips in the players, the Fly out bins don't do that do they?I must be missing your point somehow, sorry. They don't perform new imports, but they do call up existing playlists (and retain selection).

SteveSpaw
01-22-2013, 10:50 AM
OK , retain selection - got it.

SBowie
01-22-2013, 11:40 AM
OK , retain selection - got it.Sorry, I'm not 100% sure you do. They don't only retain selection. Each preset can have completely different content as well. What presets don't do is import files that were not in the playlist preset they represent when it was stored. (For that, you have to use Add.)

kltv
01-22-2013, 12:04 PM
It also remembers your settings for autoplay, loop, single and speed.

Kris

SBowie
01-22-2013, 12:15 PM
Right, thanks Kris.

SteveSpaw
01-22-2013, 12:42 PM
OK I just tried it, I did not notice all that the Fly-out bins do before. OUCH - If I am currently playing a clip and select a new flyout bin - it replaces the currently playing clip in Program ! ??????? NOT Expected and big show failure waiting to happen.

Although I like the preset work that it does, Nothing like this should replace what is "ON-AIR". A quick way to be fired from that job. :-(

SteveSpaw
01-22-2013, 12:47 PM
This highlights the fact that PROGRAM is sacred and should never be affected by a recall of a bin or snapshot.

SBowie
01-22-2013, 01:06 PM
Although I like the preset work that it does, Nothing like this should replace what is "ON-AIR".It's a complex topic, and one that has been the subject of endless hours of discussion. The short version of the looping theme of those discussions runs as follows: 'The alternative is that your onscreen playlist no longer represents nor controls what is actually on output, a major and contra-intuitive outcome and at least equally bad thing'. The workflow, then, is pretty simple. You don't normally swap on-stage talent while on the air. Similarly, don't swap a DDR playlist while displaying it on Program - unless that's what you really intend.

Note as well that output doesn't change when you choose another playlist preset if the DDR is playing. But if you press Stop, or deliberately press play for the incoming playlist, the change is performed immediately.

I'm not suggesting there are no other aspects or possible approaches - just illustrating that it's often nowhere as simple as it seems.

SteveSpaw
01-22-2013, 01:19 PM
No sorry, I just tried it. It DOES swap out a PLAYING "on air" clip. This is NOT good.

and yes I may load a new playlist while that one is playing, and I would expect it to queue up next. NOT stop the playing one.

No suggestion that the solution is simple but when it comes to what is "ON-AIR" the model should be - Do No Harm.

SBowie
01-22-2013, 01:36 PM
No sorry, I just tried it. It DOES swap out a PLAYING "on air" clip.It does not do so here. May be a build thing or a bug (I'm running something more recent).


and yes I may load a new playlist while that one is playing, and I would expect it to queue up next. NOT stop the playing one.Then, without further considerations and adaptations, you would have lost your ability to control the currently playing clip. I agree, 'Do not Harm' ... but a corollary is 'You can't entirely fix stupid'. ;)

kltv
01-22-2013, 01:42 PM
I agree, Do not Harm ... but a corrolary is 'You can't entirely fix stupid'. ;)

It's always a good goal! But you are absolutely right.

My suggestion would be to load the other playlist in the DDR you aren't using. We have lots of other equipment with this limitation. Our BitCentral Play-To-Air servers have the same design. You can't load the 5PM show while the 4:30 is still on the air. Our Chyron's are the same way sort of…

I'm all for protecting program when you can, but you also have to strike a balance between easy to understand for everybody and what makes sense to seasoned broadcast folks. There's all kinds of ways to torpedo yourself in any switcher. This one doesn't bother me that much. I have several presets on my DDR2 for different commercial breaks, opens, interviews, etc. Anything with SOT I play from DDR2. I haven't burned myself yet with those presets. If you save your presets by right-clicking on them, you could import them into the other DDR if the current one was already on the air.

Kris

kltv
01-22-2013, 01:52 PM
This highlights the fact that PROGRAM is sacred and should never be affected by a recall of a bin or snapshot.

That's not entirely true. I've built E-MEM timelines on Grass Valley switchers that integrate PGM/PST changes intentionally, reset sources on the DSKs, etc. There is also the possibility of recalling an E-MEM either Master or Local that could effect an M/E that is on the air. That's no different than changing a preset in a Virtual Input while the Virtual Input is on the air. Any other switcher wouldn't stop you from doing that. They assume you know what you are doing and mean to do what you do. I'm sure I've accidentally recalled an effect on the wrong M/E and burned myself. You can do things like SOURCE HOLDS to help protect yourself, but at a certain point you are the one flying the switcher and have to be deliberate and conscious of those kinds of conflicts. On the 8000, you can build macros that will take control of your Program output and switch on their own. I think that is a feature that should be there.

Kris

SBowie
01-22-2013, 02:04 PM
It's always a good goal! :) Again, I'm not saying nothing can be improved; only that, in this case as so often, there are also compelling reasons for the way it is at the moment to consider, and they are arguably at least as valid as the obvious alternative.

We often hear from someone feeling adamant about some aspect of an implementation; actually, I'm the same way (just had a long conversation about the ideal behavior for Next in a replay environment :) ) ... and they will almost certainly be right at times - nay, may well nearly always be right, if only within a certain workflow that they prefer. This is why we truly appreciate all feedback. But at times there are good reasons for things; still other times what would be ideal and what are really reasonably possible are separated by a wide gap. In this instance, the desire to be able to preview and even queue up another preset is well known and reasonable, but a non-trivial solution doesn't seem to have been put forward yet.

All equipment, all software, will impose limitations. When reasonably possible, we remove them. We'd love to eliminate all of them, but ...

SteveSpaw
01-22-2013, 04:11 PM
I just see a situation where I have a 10 minute show open in a playlist by itself, the next segment of the show contains several clips for the first speaker in a bin for that speaker.
During the show open I stupidly want to be ready for the first speaker and click on the bin and BAM I just killed the show open that was playing. BOOM I am fired. Not good.

That is what I see now.

SBowie
01-22-2013, 04:58 PM
Two DDRs ... 1st speaker clips cued up in the second one; problem solved. This will also let you transition into the second group if you wish, which you couldn't do by relying on one DDR.

kltv
01-22-2013, 05:08 PM
I just see a situation where I have a 10 minute show open in a playlist by itself, the next segment of the show contains several clips for the first speaker in a bin for that speaker.
During the show open I stupidly want to be ready for the first speaker and click on the bin and BAM I just killed the show open that was playing. BOOM I am fired. Not good.

That is what I see now.

You aren't stupid to want to be ready. Just plan it differently. Either cue up those clips in the other DDR or wait until the open is finished before loading the other playlist… or if your open is just one clip, put it in the same playlist as the first segment clips. I'd rather have it loaded and ready to go before the first segment starts anyway. Two DDRs are nice.

Kris

Lee-AVP
01-22-2013, 09:24 PM
:) We often hear from someone feeling adamant about some aspect of an implementation

0:-)

Steve, if your DDR doesn't lurch to the first clip in a newly selected bin, that's a new(ish) thing that I look forward to experiencing.

SBowie
01-23-2013, 05:16 AM
Steve, if your DDR doesn't lurch to the first clip in a newly selected bin, that's a new(ish) thing that I look forward to experiencing.I actually have no idea what you're referring to, and would like to hear more - but if you think you've discovered a bug, maybe it would be best to put it in a thread of its own to avoid confusion.

[Edit: I don't want to muddy this thread, which is mostly about other matters, but I've been testing switching presets and transitioning between DDRs, and can't find a playback problem - but that proves nothing, as the version I'm running is way ahead of the release build in many ways. So if you can reliably provoke an issue please report a bug, and feel free to start a new thread on that topic.]

Lee-AVP
01-23-2013, 09:01 AM
I was referring to this behavior:



No sorry, I just tried it. It DOES swap out a PLAYING "on air" clip. This is NOT good.

and yes I may load a new playlist while that one is playing, and I would expect it to queue up next. NOT stop the playing one.

No suggestion that the solution is simple but when it comes to what is "ON-AIR" the model should be - Do No Harm.

When either loading a new playlist or clicking between bins within a playing DDR, the currently playing clip stops and is replaced with the first clip of the newly selected bin. You're right, though, that this is drifting the topic.

SBowie
01-23-2013, 09:58 AM
When either loading a new playlist or clicking between bins within a playing DDR, the currently playing clip stops and is replaced with the first clip of the newly selected bin. You're right, though, that this is drifting the topic.I see, thanks. I'll just note that, in the current context, this doesn't pose an issue in a workflow that takes advantage of both DDRs.