Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jmone]

I like how we get two interfaces with MC:
1) StdView - I use this for all my managment tasks as this gives all the control you need (5% of the time)
2) TheaterView - I use this for all my playback (eg 95% of the time)

Unless you plan to spin off a TheaterView only version of MC (which you may be thinking of) I don't understand why you would want to split the View Mgt into seperate areas.  Take my ISO issue for example - I used to have one View in both STD and Theater that worked the same, I worked out what I wanted, played with it and got the outcome needed.  Now I have TWO different implementations of the Views which now work differently even though they have the same fundamentals (eg I can add my ISO to display in a Video in STDView Veiwscheme but not in the TheaterView version).

I like that MC13 will have simplified views (as other thread) for the average users but would advocate that:
1) Have one area for all Views
2) Have a "Display in TheaterView" checkbox is all we need to include the ones we want in TheaterView

Thanks
Nathan

[ThoBar]

I would go for this, but I still don't understand why adding a top-level TheaterView item to the tree unless TheaterView is disabled is so wrong?  Does anyone who's actually using TheaterView want it's view configuration as hidden as it is today?

-John

I dont have a problem with it being 'hidden' (its not really though, is it ), so long we we don't need to manually duplicate an existing view scheme. I actually find myself constructing Theater View specific schemes, and so don't mind the idea of what has being done. I do think we should have an easy way to select/import Std view schemes into the Theater View view scheme system and we should definitely be able to define nesting schemes. The current non-nesting system means I have a plethora of schemes listed under Views, rather than a few which lead logically to the media