Page 4 of 5 FirstFirst ... 2345 LastLast
Results 46 to 60 of 67

Thread: TC1/VMC1 V2 (7-0) and Premium Access Released

  1. #46
    Registered User
    Join Date
    Jun 2012
    Location
    Australia
    Posts
    268
    Yeah, this particular client bought a TC1 a couple of months ago and updated it a week ago, and hence have only recently discovered the problem. In their case they have three other Tricasters, so the theory was they don't need an NC1. I'm sure they will live, but I guess it validates our advice to them not to buy any more TC1s given for their use case they are an objectively worse machine by almost all measures (M/Es, NDI flexibility, number of physical inputs, key behavior, interface, Windows 10).

  2. #47
    NewTek System Integrator PIZAZZ's Avatar
    Join Date
    Feb 2003
    Location
    Texas, or wherever the plane drops me off this week
    Posts
    4,214
    Quote Originally Posted by webslave View Post
    I guess it validates our advice to them not to buy any more TC1s given for their use case they are an objectively worse machine by almost all measures (M/Es, NDI flexibility, number of physical inputs, key behavior, interface, Windows 10).
    So let me get this straight, you are telling your client NOT to buy the TriCaster that is going to keep getting updated and improved? Maybe I lost it in the translation. I just do not understand. Our TC1s in operation are fantastic. So much more flexible than event the 8000. Sure if you are stuck in a SDI world then losing 4 hard inputs might be a kick in the pants. A simple box can easily fix that and even give you more inputs/outputs.
    Jef Kethley
    PIZAZZ
    www.pizazz.com

    Using:
    All models of TriCasters + 3Play, IPSeries
    Panasonic UB300 4k cams
    Tactical Fiber/converters, SDI2NDI converters, NDI-Viewfinder, and NDI2HDMI

  3. #48
    Quote Originally Posted by webslave View Post
    Yeah, this particular client bought a TC1 a couple of months ago and updated it a week ago, and hence have only recently discovered the problem. In their case they have three other Tricasters, so the theory was they don't need an NC1. I'm sure they will live, but I guess it validates our advice to them not to buy any more TC1s given for their use case they are an objectively worse machine by almost all measures (M/Es, NDI flexibility, number of physical inputs, key behavior, interface, Windows 10).
    The TC1 is a mainly a replacement for the TC460. From that standpoint, it has the same number of M/E, the same amount of physical inputs, more physical outputs and the same amount of keyers with the current OS. Not to mention that it has two streaming engines, 1080p50 and 60 support, 4K/UHD support, two channels of Skype TX and more NDI inputs. Some people do push it into the TC8000 space (which is does offer a similar number of inputs), but we do have the VMC1 system which would fill out the other 8000 features you are talking about and offers more as well.
    Last edited by kanep; 11-01-2018 at 10:47 AM.
    Kane Peterson
    Solutions Architect
    NewTek, Inc.

  4. #49
    'the write stuff' SBowie's Avatar
    Join Date
    Feb 2003
    Location
    The stars at night are big and bright
    Posts
    19,392
    Quote Originally Posted by kanep View Post
    The TC1 is a mainly a replacement for the TC460.
    Wait, I love my 460s!

    Seriously, 460 and 8000 remain awesome systems, not least because of their versatility. That said, there can't be any serious question that the future is IP, and once you get set up around that, a lot of this becomes a non-issue and TC1's own advantages start to shine. That said, I'll review the current Fill/Key config implementation with the comments from this thread in mind.
    --
    Regards, Steve
    Forum Moderator
    ("You've got to ask yourself one question ... 'Do I feel lucky?' Well, do ya, spammer?")

  5. #50
    'the write stuff' SBowie's Avatar
    Join Date
    Feb 2003
    Location
    The stars at night are big and bright
    Posts
    19,392
    OK, I spent some time reviewing these items this a.m., and have a few thoughts to offer.

    … 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 is true, but:

    • You have 8 additional Switcher inputs to work with on TC1 compared to an 8000 (or at least 4 more if the 8000 is on 5-1).

    • So you can assign the input you clearly don’t plan to use locally (else we wouldn’t be having this conversation) to Switcher 16 (for example), which you probably weren’t using anyway, and still have either 3 or 7 more unused Switcher buttons left than on your 8000.

    • I really feel like customers who might use a TriCaster’s (otherwise unused) SDI inputs exclusively to convert sources to NDI for use downstream and without ever wanting to use them on the local TriCaster is really quite an edge case anyway. I wouldn't say it would never happen, but it seems like a vanishingly small number of customers would encounter this.


    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.
    • It’s true that there is one more abstraction level, but I don’t honestly think it can be said that this makes things much harder.

    • You can easily rename Switcher inputs to avoid confusion; naming them for the original sources would make sense, I think. For example, if I use Switcher input 16 to pass through a camera connected to SDI input 4, I can rename its Switcher button “TC1A SDI4” (or some such thing), and its NDI output appears as such on the network. This makes it pretty easy to identify channels.


    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.
    Much of the above is unchanged, so I’ll skip discussing those bits.

    • It’s true the key source now has to be assigned to a Switcher input; and you could switch to it inadvertently, though this would have no negative impact (as Kane has pointed out). On the other hand you could, I suppose, actually use this key input for something creative - since you can apply ‘post’ effects to it without interfering with its application as a key source. (With Premium Access, you could even animate the key layer, which would support some interesting ‘moving keyhole’ applications.)

    • As discussed earlier, burning the extra Switcher input would matter more if you were stuck with TC’s original 8, or 5-1’s 12. But you’re not. And again, you can locate the key input off on the unused end of the Switcher if you wish.


    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 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 don’t think you could ever get an NDI output with embedded transparency from any version, so unless you just mean that you found some value in an NDI output that shows black where transparency would be, I’m not seeing any practical value lost here.

    Really, using a TriCaster of any type for the purpose of passing a key/fill pair downstream as NDI seems like another edge case. Far better to convert the original SDI pair(s) to 32bit NDI streams, which several of our 1RU systems will do for you.

    So, summing up, yes it's different. And yes the differences call for some relatively minor workflow adjustments. But I'm honestly not seeing a significant, practical downside to anything above, and any there may be have to be weighed against the benefits (listed previously) to the current approach.
    --
    Regards, Steve
    Forum Moderator
    ("You've got to ask yourself one question ... 'Do I feel lucky?' Well, do ya, spammer?")

  6. #51
    Registered User
    Join Date
    Jun 2012
    Location
    Australia
    Posts
    268
    Quote Originally Posted by PIZAZZ View Post
    So let me get this straight, you are telling your client NOT to buy the TriCaster that is going to keep getting updated and improved?
    Yes. It's not that hard of a recommendation to make - the unit today does less than an 8K for their workflow. Updates and improvements are a double-edged sword, because I know this customer has been turned off by software quality and the improvements haven't been relevant to their workflow.

    Quote Originally Posted by PIZAZZ View Post
    Our TC1s in operation are fantastic. So much more flexible than event the 8000. Sure if you are stuck in a SDI world then losing 4 hard inputs might be a kick in the pants. A simple box can easily fix that and even give you more inputs/outputs.
    Their experience hasn't been quite as glowing. I know they have been bitten a couple of times on NDI even though they still rely upon it heavily. Their sources are all coming from SDI somewhere, so ingest is certainly a consideration. Their TC1 hasn't been as warmly recieved as their other Tricaster models have been over the journey - that's okay, it's not going to be ideal for everyone.

    Quote Originally Posted by PIZAZZ View Post
    I would have to say though that not every user uses their TC this way.
    Pretty much nailed it right there.

    Quote Originally Posted by kanep View Post
    The TC1 is a mainly a replacement for the TC460.
    You and I are on the same page with this, as I have said the same thing. Sales and distribution over here on the other hand aren't saying that and instead are pushing people who are replacing/duplicating TC8K's toward TC1s. Haven't seen a VMC1 in my travels yet and am not sure what sort of pricing ballpark they are in here to be able to push people that way. If they need a 460 they end up with a Mini. If they need an 8K they get an 8K at the moment.

    Quote Originally Posted by SBowie View Post
    there can't be any serious question that the future is IP
    No doubt, a lot of stuff is going that way. I guess it depends on the market though - if, like us, you deal with a lot of OB trucks then IP is not going to be the majority of what you're doing.

    Quote Originally Posted by SBowie View Post
    • You have 8 additional Switcher inputs to work with on TC1 compared to an 8000 (or at least 4 more if the 8000 is on 5-1).
    Yes. They would use the TC1 as their main switcher but it doesn't have enough M/E's for them at the moment, hence the difficulty.

    Quote Originally Posted by SBowie View Post
    • So you can assign the input you clearly don’t plan to use locally (else we wouldn’t be having this conversation) to Switcher 16 (for example), which you probably weren’t using anyway, and still have either 3 or 7 more unused Switcher buttons left than on your 8000.
    That's what they will have to do, yes.

    Quote Originally Posted by SBowie View Post
    • I really feel like customers who might use a TriCaster’s (otherwise unused) SDI inputs exclusively to convert sources to NDI for use downstream and without ever wanting to use them on the local TriCaster is really quite an edge case anyway. I wouldn't say it would never happen, but it seems like a vanishingly small number of customers would encounter this.
    One of the more common cases we see where this is happening is on a show with a couple of studios and a couple of Tricasters - they will pass feeds back and forth for things like return lines or beauty shots. Another one we find is customers who prioritise their inputs in terms of importance for taking them locally vs via NDI.

    Quote Originally Posted by SBowie View Post
    It’s true that there is one more abstraction level, but I don’t honestly think it can be said that this makes things much harder.

    You can easily rename Switcher inputs to avoid confusion; naming them for the original sources would make sense, I think. For example, if I use Switcher input 16 to pass through a camera connected to SDI input 4, I can rename its Switcher button “TC1A SDI4” (or some such thing), and its NDI output appears as such on the network. This makes it pretty easy to identify channels.
    We showed them the same thing, and that's the way they name things to aid troubleshooting. It works well enough until someone needs to change over an input assignment for something and then the names are out of sync. Maybe a good case for a feature request for datalink in source names?

    Quote Originally Posted by SBowie View Post
    As discussed earlier, burning the extra Switcher input would matter more if you were stuck with TC’s original 8, or 5-1’s 12. But you’re not. And again, you can locate the key input off on the unused end of the Switcher if you wish.
    To be fair, it does kind-of matter. If you read that it takes 16 inputs you don't expect that the trade-off is some of your inputs will now occupy two inputs where they previously did one. Having more inputs is not a reason to get less efficient with them.

    Quote Originally Posted by SBowie View Post
    I don’t think you could ever get an NDI output with embedded transparency from any version, so unless you just mean that you found some value in an NDI output that shows black where transparency would be, I’m not seeing any practical value lost here.
    Cool trick was that we could! That's the reason for my comments upstream v downstream for setting up the input. Setting up a fill/key would give you a 32bit NDI stream when you took the fill input.

    Quote Originally Posted by SBowie View Post
    Really, using a TriCaster of any type for the purpose of passing a key/fill pair downstream as NDI seems like another edge case. Far better to convert the original SDI pair(s) to 32bit NDI streams, which several of our 1RU systems will do for you.
    They have Tricasters, they don't have the other boxes. Doing it with outboard is completely valid, I agree, but if you're doing cost/benefit on it and you're not using stuff like SkypeTX or need several M/Es then you end up way on the wrong side of that.

    Every customer is not going to be like this customer, but there's for-sure going to be variations on this problem come up. I know you guys are super-proud of the TC1 and you absolutely should be. For some shows it's the perfect box. I just don't see it as accurate to call it an upgrade from a TC8K in all, or even a majority of cases. 460? Yep, totally see it. Mini? Absolutely.

  7. #52
    LiveSet Making Machine joseburgos's Avatar
    Join Date
    Feb 2003
    Location
    NYC
    Posts
    3,333
    So the Dante ASIO at 64x64 and change Options to 1ms, I am getting least latency than I have ever had before Dante in and out. If I send as an example, DDR1 to AUX1 only and AUX 1 change to Dante 1-4, I then bring that into Dante enabled audio mixer and return the main mix of mixer via Dante to Input 1 on TC-1 and the latency is less than a pure analog equivalent in and out of TC-1 by a little. Before using WDM, the latency was much larger.

    KVM is so sweet is all I can say.
    Jose Burgos
    NewTek Certified Trainer
    NewTek Certified on all TriCaster's
    NewTek Training & Certification Testing
    www.burgosfx.com
    FaceBook
    Twitter @NYTriCaster

  8. #53
    Registered User
    Join Date
    Jan 2018
    Location
    Winter Park
    Posts
    314
    I thought I saw someone asking about this but is there a way to get the actual time remaining in the DDR monitor windows instead of just the color? I often operate for the second multi-view monitor and I need to cue talent on time remaining. its color coded but I may miss the start of yellow at 9 seconds and red at 4 etc.

  9. #54
    LiveSet Making Machine joseburgos's Avatar
    Join Date
    Feb 2003
    Location
    NYC
    Posts
    3,333
    Yes right click on window to enable it
    Jose Burgos
    NewTek Certified Trainer
    NewTek Certified on all TriCaster's
    NewTek Training & Certification Testing
    www.burgosfx.com
    FaceBook
    Twitter @NYTriCaster

  10. #55
    Registered User
    Join Date
    Jan 2018
    Location
    Winter Park
    Posts
    314
    Awesome, need to get my vision perscription checked.

  11. #56
    Registered User
    Join Date
    Jan 2018
    Location
    Winter Park
    Posts
    314
    Quote Originally Posted by joseburgos View Post
    Yes right click on window to enable it

    I right clicked and there was a configure and I went to Media Players, DDR and saw timecode. but when I checked that the video in the window was replaced with just the time code. Is this the one you are talking about or is there a way to get the time code down below in the bar of the playback while still showing the video?

    Thanks

  12. #57
    LiveSet Making Machine joseburgos's Avatar
    Join Date
    Feb 2003
    Location
    NYC
    Posts
    3,333
    Yes and you click on other as well can’t remember the name but above or below time code
    Jose Burgos
    NewTek Certified Trainer
    NewTek Certified on all TriCaster's
    NewTek Training & Certification Testing
    www.burgosfx.com
    FaceBook
    Twitter @NYTriCaster

  13. #58
    Registered User
    Join Date
    Jan 2018
    Location
    Winter Park
    Posts
    314
    Thanks,

    Will click more!

  14. #59
    Registered User
    Join Date
    May 2015
    Location
    PA
    Posts
    42
    Quote Originally Posted by joseburgos View Post
    So the Dante ASIO at 64x64 and change Options to 1ms, I am getting least latency than I have ever had before Dante in and out. If I send as an example, DDR1 to AUX1 only and AUX 1 change to Dante 1-4, I then bring that into Dante enabled audio mixer and return the main mix of mixer via Dante to Input 1 on TC-1 and the latency is less than a pure analog equivalent in and out of TC-1 by a little. Before using WDM, the latency was much larger.

    KVM is so sweet is all I can say.
    With Premium Access, are you able to send the DDR's directly to Dante, or do you first need to send the DDR to an aux and then send the aux to Dante?

  15. #60
    Quote Originally Posted by TheMissingLink2 View Post
    With Premium Access, are you able to send the DDR's directly to Dante, or do you first need to send the DDR to an aux and then send the aux to Dante?
    The Advanced Audio IO feature in Premium Access would allow you to send DDRs (and the Sounds and the Transition FX channels as well) directly to Dante without having to assign it to an AUX.
    Kane Peterson
    Solutions Architect
    NewTek, Inc.

Page 4 of 5 FirstFirst ... 2345 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •