If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Again, I think any critical fixes in 7-0 will already have been added to 6-0, but you could check with QA.

On the other topic, honestly I do not expect the PTZ tab to reappear. We will improve on the current implementation, but each PTZ camera in 7-0 already has its own presets, with thumbnails. In fact, the number of them shown for an individual camera has actually increased.

Does this mean we won't be having any more updates for the AE with the non TC/VMC1 kit or is development continuing on those (fingers crossed)

I am sure you can expect continued maintenance of 5-1.

New features and functions, such as those in 7-0/PA - were these to be offered - would almost certainly come at a cost, however. AE has seen a lot of un-paid revisions already, I doubt we can continue that pro bono until the next millenium!

My initial reaction to the new interface was not positive, but having spent some time with it there are some very nice additions. However there are two things that need fixing before I would consider rolling out to my clients;

1/ There is a way of locking the interface. You need to understand that not every operator is a TriCaster expert or should need to be.

2/ The centralised PTZ TAB is brought back. The new implementation is really a backward step, in fact close to unusable.

The new interface is indeed different, some parts of it are an improvement, some parts may take getting used to (or might be worse, but need to give it time).

One thing though that looks like it could be a bit of a problem for some of our clients is the way inputs are set up now. Previously if you were using fill+key sources via SDI you'd configure the second input as a matte for the first input, and since physical source configuration was done prior to the input stage you would then set up an input on your Tricaster for the first source and it would give you a properly matted version of the source you need. Now, physical source configuration is done apparently downstream of the input. This means you need to assign a source to an input to be able to configure it (and have it available via NDI), and therefore if you're using key and fill it means you need to assign both the key and the fill to inputs on the Tricaster - therefore burning two inputs where you only needed one before. The problem is carried over to NDI, whereby previously if you picked up that source from another Tricaster you'd get it matted already for you, whereas now you'd have to bring both across separately. It's not really a good move, and in our case since we run two sets of key/fill we end up burning four inputs for the sake of two.

One thing though that looks like it could be a bit of a problem for some of our clients is the way inputs are set up now. Previously if you were using fill+key sources via SDI you'd configure the second input as a matte for the first input, and since physical source configuration was done prior to the input stage you would then set up an input on your Tricaster for the first source and it would give you a properly matted version of the source you need. Now, physical source configuration is done apparently downstream of the input. This means you need to assign a source to an input to be able to configure it (and have it available via NDI), and therefore if you're using key and fill it means you need to assign both the key and the fill to inputs on the Tricaster - therefore burning two inputs where you only needed one before. The problem is carried over to NDI, whereby previously if you picked up that source from another Tricaster you'd get it matted already for you, whereas now you'd have to bring both across separately. It's not really a good move, and in our case since we run two sets of key/fill we end up burning four inputs for the sake of two.

I must not be understanding something correctly. The setup of input sources hasn't changed from Rev 6 to Rev 7. NDI inputs with alpha continue to have alpha, you do not need to use two inputs for that. SDI, or course, needs two inputs since that is the only way to do it.

Dejavu! I said the same thing to my client when they told me about it.

The difference is how you tell the Tricaster the source is a matte. Previously you did that without assigning it to a switcher input button. Now you need to assign it and then can select to make it a matte for the adjacent button. Does that make more sense?

To be clearer - previously (on the left) is how you used to set up the second SDI input to be the key. The new is on the right:

Whilst this may seem to make a little more sense from a UI standpoint, this design change goes beyond the UI and has what I think are unintended consequences for how inputs work now;
- To be able to share one of the SDI inputs on a Tricaster via NDI you now need to assign that SDI input to a switcher input/button. This means that if another Tricaster (or other device) on the network wants to use one of your sources via NDI you need to burn a switcher input/button on your Tricaster to facilitate it. This also creates a situation where usability is decreased because the input is advertised via NDI as the switcher input/button number, not the physical input number (so a TC1 will advertise Input 7 via NDI for example which may be SDI input 2, whereas previously it would have advertised Input 2 regardless of which switcher input/button you had it assigned to, which makes more sense since a Tricaster won't readvertise incoming NDI sources), which makes troubleshooting much harder.
- If you're running a fill and key you now need to assign the fill to an odd-numbered switcher input/button (eg; SDI2->Input 5), and then assign the key to an adjacent switcher input/button (eg; SDI3->Input 6) and then tick the use as matte option in the input, and then make sure you never switch to it. Previously you'd just configure the even numbered SDI as a key for the adjacent odd numbered one, and then assign the fill SDI to a switcher input/button. This means you can never accidentally switch to the key, and you only burn one input.
- Any work by the Tricaster to combine a fill and key is done past the switcher input stage. This means (from the previous example) if you picked up NDI input 5 from a TC1 you'd only get a straight fill, rather than a fill with transparency. You'd need to bring across Input 5 and Input 6 via NDI and then tell your receiving Tricaster to combine them for you, which still means burning two inputs when it was previously only one.

I see, you are comparing Rev 5-1 to Rev 6 & 7, since this post is under the Rev 7 features, I didn't understand because this hadn't changed between Rev 6 software and Rev 7.

You are correct in that this is how it now works.

I will point out that when you set an input as a key, both the odd and even inputs are set to show the full video+key input, so selecting the 'key' input will not show you the black and white key, but the same image that you would see in the 'fill' input. I understand this isn't a solution to everything you have listed above, but it does make the issue of selecting the key input not as bad as it could be (at least no worse then selecting an incorrect source).

If you have a NC1 IN or NC1 IO module, they should do the key+fill input on that unit, then the extra SDI input is used up on the NC1 and it will only use one input on the TC1 itself.