No, they aren't currently very used to using it, but I suspect that's largely because it doesn't exist yet..
Keyboards and pointers are good versatile devices, but there are limits to how fast you can use them, especially when the nuke interface doesn't always enforce spacial consistency for UI elements. Combine that with the relatively small hit targets provided by traditional nuke parameter panels and you have room for, well, improvement.. I'm sure many of you remember the dramatic difference between how fast you could drive Shake in the Tremor style interface vs the bog standard sliders and tabs crapfest that was the standard style Shake interface. Imagine for a minute using a panel instead of a normal keyboard in combination with your Wacom. You map a few of the keys to be the most commonly used nuke keys, Ctrl, Tab, Space, 1, 2 etc. You perhaps dedicate the left hand side wheel/ball to viewport and DAG navigation, ball as XY, wheel as zoom. Whenever you select a node in the DAG it's knobs are mapped to the row of soft labeled twist pots on the top of the panel. Think about that in the context of something as simple as a blur node. Right now, I have to click on a node, let my eyes track across to parameters panel, visually lock onto the knob, move my cursor to the slider, get closer, finetune my movement as it gets closer, click, engage the pot. And that's best case scenario using a docked panel and a Wacom, the situation is far worse if I'm using floating panels and a mouse. In the case of the control surface, I click on the Blur node, and reach for the first knob, I know which knob it is because Blur Amount is always the first knob, I know where knob is because I have 3d muscle memory of where things on my desk are, I don't have to look at because I know where it is.. I know this sounds like I'm chasing a lost second here, a scanning glance there, but this is just with a simple node, scale it up to the ColorCorrector node and you are starting to talk about actual time lost. This sort of thing is the difference between being "pretty fast" and "really fast". The J_3Way thing is very interesting, but again, doesn't really exist in the real world outside of a pretty limited beta.. If it became a fully supported 1st party option from the foundry, which isn't impossible to imagine, it would cover a lot of cases (but won't be as good when keeping your eyes on the main screen). Also might be a bit weird to get running in bigger facilities where the user level wifi is isolated from the main network where your production nuke machines live, but that's a solvable problem. As Frank pointed Mac/Win only is a bit of an issue. I wonder how much of that is a technical issue, and how much is simply no application venders with Linux products licensing it. They refer to it as an Open standard, but everything I've read seems likes its not a public standard (prepared to be corrected on that one) On 17/07/2011 <x-apple-data-detectors://0>, at 10:03 PM, Johan Boije < [email protected]> wrote: Don't think the "Nuke crowd" are very used to those type of setups. They like their keyboard and pen, heck I've even seen compers use mouse instead of wacom. Imagine the CTS problems they must have. The closest thing I've seen in Nuke is mr Binks J_3Way with a cool iPad control. http://vimeo.com/14882077 On Sun, Jul 17, 2011 at 7:47 AM, Alex Fry <[email protected]> wrote: > Has anyone here looked at getting the Avid Artist hardware control > panels working with Nuke? > > I can't really find any documentation about Avid's Eucon protocol. > Are there any barriers with nuke/python that make this impossible out > of the gate? > Is there a clear reason this hasn't been attempted before? > > Obviously there are going to be some tricky mapping issues, but now > this style of hardware is under 2k rather than 30k it's seems like it > might be worth attempting. > In my head, an Artist Color panel under my left hand and a Wacom under > my right should be a pretty good combination. > Map the currently active node to the panel, display knob names on the > displays. > You might find it works well with all of the normal node types, or you > may find it make sense to make a few gizmos that are more specifically > tuned to the limits of the panel. > > Anyone else out there looking into the same idea? > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > _______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
