UI Rant...

[Brent J. Craig]

OMG - i can't believe that you're using Photoshop - a nightmare of nested menus, a rat's nest of mouseclicks, a complete miasma of tools strewn about the place without regard for workflow or logic...

Hint: use the keyboard.

See, the normal menus are there for casual users and those just learning but the keyboard shortcuts open up a 'single-click' UI for experts.

 

[TCurren]

... then again -- no SDI out, so am I really color grading in RC in any meaningful way? - Nope, just doing the equivalent of a best light / one light.

Biggest issue I see right now. Scratch is THE only way to do this with proper monitoring. Too expensive as a dailies solution.

 

[John Tissavary]

Hint: use the keyboard.

Rather snarkey...

I love hotkeys, matter of fact I stay away from software that doesn't offer hotkey functionality. But that's no excuse for the hunt-and-peck interface Photoshop has been sporting... essentially the same one it's had since inception. When there were only a few tools and tasks the drop menu thing wasn't a big deal, but now that computing power is there to support more tools and better UIs it seems more a concession to a userbase that doesn't want to learn a new UI. Adobe is definitely not the only company afraid to make changes because of that, but it doesn't make Photoshop have a good interface.

As previously mentioned, Maya is a great example of software with a forward thinking, progressive interface.

Thanks to some really clever UI development it went from PowerAnimator, which was a nested menu nightmare like Photoshop, to Maya, which took some of the greatest immersive ideas from Thompson's TDI, mixed it with their own gesture & chord based menus, and now it's possible to 'live' inside the maya UI instead of hunt and peck. No, it's not for the casual user. And no high-end software, including RedCine should be. We are professionals, not consumers, and have no excuse not to learn software. It's our livelyhood.

I'm not saying there's not improvment to be made in Scratch / RC interface design, but I think OS convention is the wrong place to look, because neither Windows nor OSX was designed with our kind of workflow in mind.


jt

 

[laguun]

I have had this discussion many many times. I believe strongly that EDL support in REDCINE is a really bad idea.

EDL support is one of the most important missing features in Redcine.
>99% of all editors deliver EDLs.

You don´t have time to explain every single editor why the workflow which is the proven, accepted and usual method since decades isn´t working anymore.

Here's why:
Walk down the path with me. You import an EDL and it's screwed up, and it has to be fixed. Then what?

You reject the EDL as it is screwed up.
As you would do in almost any other workflow as well.

Then you need a way to show the offline reference vs. the conform - a dual viewer - so you know what's right and what's wrong.

No, if the EDL is screwed up, theres is just one who knows why and what is wrong: the one who delivers the new edl out of his 3 year old avid, his 4 year old smoke, his 5 year old ds, his 2 year old quantel, his 1 year old premiere, his whatever... the editor.

You can´t screw up a basic CMX, even when typing it by hand.

Then edits have to be fixed, so slip/slide/roller capability has to be added.
And since you're also going to be trimming, ripple capability has to be added at both a clip and timeline level. Re-edits and recuts come in, so multiple timeline ability is needed to keep track.

No, the topic is EDL - not editing.

it would be nice to have editing in redcine, but thats not necessary. EDL is not nice, its necessary.
Redcine needs an EDL support in order to support the 99% of editors out there. Anything else means singling out Red as camera - as every other professional camera whichhas sold more than 50 units supports EDL basing editing. No 55 year old highly decorated top-editor will understand why edl wonßt work, so won´t the student, and besides - almost all the installed editing systems base in the market is using EDL.

I have a list of about 30 things that happen *immediately* after EDL support. There is no such thing as "just" EDL support.

Its only about -most basic- edl support. no dissolves/wipes/multitrack, no editing capabilities, even audio is not necessary.

It would be worthless without all the other tools that go with conforming and supporting EDLs.

I completly disagree. Every workflow in every camera in every system uses edl - especially when going between different versions of system or even different manufacturers. Most of the brilliant editors in a-budget i meet, veterans who have more than 10 A-bugets fullfeatures under the belt dont even understand what XML is.


We are getting their EDL lists in our DI suites and they don´t want and don´t need to understand why the proven workflow with any system they are using and have been using in the recent 30 years basing on Arri, panavision, Sony HDCAM or Thomson Viper etc suddenly shouldn´t work anymore. What they do understand is that timeramps, additive crossdisolves and unusual complex edits have to be commented, not included in the EDL.

The process of dealing with EDLs and matching high-rez to low-rez material is conforming and online editing. And REDCINE is not a conforming and online editing application. If you want it to be, that's a different conversation. But REDCINE in its current concept is not designed to do that.

luki, that point i fully understand and i agree - but edl support in redcine isnßt about using redcine as finishing system - its about feeding the online system.

REDCINE has an XML implementation that - right now - allows you to build a list of clips used from in-to-out point and then render those. And that allows users to go effectively from an offline to online system. Avid will very soon release software that exports REDCINE XML from an Avid timeline. Ian Bloom has written software that does the same thing from FCP to REDCINE, and there will also be more formal support eventually. If Avid and FCP support conversion to REDCINE XML, why is that not sufficient for what you need to do?

It is certainly useable for houses who offer in house red workflows - however, with thousands of red in the market: the huge majority of editors using red footage will have no clue about the pretty sophisticated requirements for an xml, will never have made one xml. and this will lead to the public imgae that the red workflow is slow and complicated and cannot be handled by regualr seasoned editors without having to relearn or use more modern tools of their applications. Especially avid (or lightworks) editors often have editerd the recent top-ten blockbuster on software versions which are 4 years old, and you can´t send an assistant to each on of them.

Therefore: basic edl, not finishing/conforming is in my humble opinion a must have in redcine. Forget editing, any FX, forget speedramps, slips, slides, ripple, insert, overrecord - just hardcut is enough, handles would be a nice addition.

If this won´t be implemented, we will see -thousands- of editors fail on their first red online, and they certainly won´t blame it on their systems, and the producers will have a suboptimal impression of the camera for sure, as it has restrictions they don´t know and don´t understand.

 

[Jeremy Neish]

I couldn't agree more with the original poster, Emery. I really don't like RedCine's UI. I get that it's probably efficient when you get adept at it (and it's pretty), but I don't think UI's need to be miles away from standard host OS conventions to be efficient.

I agree it should be thoroughly re-designed. Starting with my #1 complaint. Please give me standard Mac OS X Open and Save Dialog boxes. I am one of those traditional Mac users that HATES column view and I do everything in my power to eliminate it anywhere and everywhere I can. And I find it beyond agrivating that RedCine requires you to use column view. And to make matters worse it uses UNIX pathing, not Mac pathing. ie. If I want to go to a different drive I have to dig into the Volumes folder. This is not at all Mac-like, (unless you are at the UNIX level). To most Mac users their mounted volumes are at the root or desktop level, just like they are "in real desktop world".

#2 complaint (barely), is the full screen-ness of it. The only apps that should completely take over the screen are games. Everything else should be windowed. I am a heavy multi-tasker and it's very very annoying to have to Quit the program to do anything else on my computer. Grrr..!

I don't want sound unappreciative of the efforts Red and Assimilate are putting into the product. But you asked for feedback and so far I like most of what people are saying.

Also, in response to some of the comments above. The Dvorak analogy isn't accurate, at least not in the common misconception that the Dvorak keyboard is actually better. On the surface it seems like it should be, but in fact, studies have shown that those that become adept at it, aren't actually any faster than Qwerty users, and in fact are on average a bit slower.

Also, I happen to really like both Photoshop and After Effects UIs. I'm incredibly fast at both and they managed to stick to OS standards pretty closely. In fact I much prefer After Effects 6.5 and older. I also find that even though older AE's windows weren't docked, I found that it was more space efficient, with the current AE UI I find that even my 30" monitor is too small sometimes.

I have a lot more UI feedback if you guys really want to hear it. And for the record, Emery's comments have been 100% dead on, in my opinion.

 

[Lucas Wilson]

...But you asked for feedback and so far I like most of what people are saying.
...
I have a lot more UI feedback if you guys really want to hear it. ...

Bring it on... but be prepared for the response as well.

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA

 

[Jeremy Neish]

Bring it on... but be prepared for the response as well.

Fair enough.

 

[Bruce Allen]

REDCINE has an XML implementation that - right now - allows you to build a list of clips used from in-to-out point and then render those. And that allows users to go effectively from an offline to online system. Avid will very soon release software that exports REDCINE XML from an Avid timeline. Ian Bloom has written software that does the same thing from FCP to REDCINE, and there will also be more formal support eventually. If Avid and FCP support conversion to REDCINE XML, why is that not sufficient for what you need to do?

What if you're using Premiere?

I would imagine standard workflow for lower-budget folks for the next year or so (due to slowness of conversion on current computers) would be:
1. export everything at low quality in RedCine
2. edit
3. re-export shots used in edit at high quality

If you guys aren't offering this, then what people will have to do is:

1. make selects in RedCine
2. export selects from RedCine
3. edit

So then, you'd obviously want to make the UI *really nice* for making selects, trimming out stuff we don't need, etc since people are going to have to spend days in RedCine.

Also, Red should change the chart on their website. At the moment, for Premiere / Avid workflows it just says "conform from native .R3D files". You should change that to "conform from native .R3D files in Scratch" because there's no other way for them to conform then, right? That would help avoid people becoming frustrated.

Personally, I think RedCine is sweet and like its interface quirks. I like to edit on Avid so I am also fine there. I'm sure that you guys and MichaelP will have something smooth by NAB.

Bruce Allen
www.boacinema.com

 

[Lucas Wilson]

EDL support is one of the most important missing features in Redcine. ... You reject the EDL as it is screwed up. ... As you would do in almost any other workflow as well. ... You can´t screw up a basic CMX, even when typing it by hand.

The responsibility for fixing the EDL is almost always with the Online Editor. EDLs are almost never rejected and sent back to Offline. Most of this is because most offline editors don't know *how* to fix an EDL. Offline Editors' skill and talent is creating stories, not technical conform issues.

And CMX EDLs are unfortunately very easy to screw up. Just a few examples:

1) Illegal characters (happens all the time when transferring a file from OSX to XP)
2) Illegal reel names
3) Illegal spacing (happens a lot with FCP)
4) 30fps EDL for 24fps Online
5) DF / NDF mismatch
6) Record TC discontinuity
7) Illegal or incorrectly formatted M2 lines

There are many more... you get the idea.

Its only about -most basic- edl support. no dissolves/wipes/multitrack, no editing capabilities, even audio is not necessary.

With dissolves and wipes, how will the additional footage necessary on the A and B sides be taken into account? With M2 lines, how will the correct SourceTC be implemented?

Most of the brilliant editors in a-budget i meet, veterans who have more than 10 A-bugets fullfeatures under the belt dont even understand what XML is.

Which is why Avid is writing an export-to-XML and there are existing tools for FCP-to-XML.

Therefore: basic edl, not finishing/conforming is in my humble opinion a must have in redcine. Forget editing, any FX, forget speedramps, slips, slides, ripple, insert, overrecord - just hardcut is enough, handles would be a nice addition.

Even here, you're starting to add features! "...handles would be a nice addition." It would have to be variable, because 4 frames would be perfect for some, bad for others. Then there needs to be error handling in case the handles extend beyond the R3D file. Also would need GUI additions to handle that.

None of this is impossible, but you've sort of proved my point for me... there is no such thing as "just EDL support."

If this won´t be implemented, we will see -thousands- of editors fail on their first red online, and they certainly won´t blame it on their systems,

No, they will blame it on whatever online and finishing facility that cannot finish their project. The Editors won't fail - they will have offline material and will be able to use their tools to tell a story.

Bottom line - REDCINE is not a conforming and online tool. There will be good EDL -> XML conversion tools for the most popular offline systems. So why that is not sufficient?

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA

 

[Dylan Reeve]

I'm torn on the EDL question.

Yes, an XML edit discriptor is a pretty good option, but what I think there might be room for improvement in the way that XML works... If I understand it correctly the clips in the XML are timed based on a framecount from the beginning of the clip, not by timecode. Making it impossible to build an XML from and EDL without additional information (namely the start timecode of each source clip to determine framecount for in and out points.

As for UI - I've said I prefer standard OS-native ones, but I understand some of the reasons for avoiding them. I don't find REDCine's too bad, given experience with discreet tools that have a similar style, but still some of it is somewhat counter to years of UI experience.

 

[Mark L. Pederson]

I have had this discussion many many times. I believe strongly that EDL support in REDCINE is a really bad idea. Here's why:

Walk down the path with me. You import an EDL and it's screwed up, and it has to be fixed. Then what? Then you need a way to show the offline reference vs. the conform - a dual viewer - so you know what's right and what's wrong. Then edits have to be fixed, so slip/slide/roller capability has to be added. And since you're also going to be trimming, ripple capability has to be added at both a clip and timeline level. Re-edits and recuts come in, so multiple timeline ability is needed to keep track. Going back to the offline cut for a minute, that means adding ability to support formats other than R3D in REDCINE, which is a huge architectural change.

I have a list of about 30 things that happen *immediately* after EDL support. There is no such thing as "just" EDL support. It would be worthless without all the other tools that go with conforming and supporting EDLs. The process of dealing with EDLs and matching high-rez to low-rez material is conforming and online editing. And REDCINE is not a conforming and online editing application. If you want it to be, that's a different conversation. But REDCINE in its current concept is not designed to do that.

REDCINE has an XML implementation that - right now - allows you to build a list of clips used from in-to-out point and then render those. And that allows users to go effectively from an offline to online system. Avid will very soon release software that exports REDCINE XML from an Avid timeline. Ian Bloom has written software that does the same thing from FCP to REDCINE, and there will also be more formal support eventually. If Avid and FCP support conversion to REDCINE XML, why is that not sufficient for what you need to do?

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA

Luki -

I hear you and agree with many of your points. HOWEVER, you can also apply much of your logic against XML support just as easy as EDL support.

I think it is clear by all of your posts that you will not offer EDL IMPORT.

Okay, fine. Then let's work on making the REDCINE XML better.

I'm going to be extremely disappointed if the next REDCINE does not include color settings in the REDCINE XML. Anyway, like I said, I will hold back comments until I see the next build.

I think we have really hijacked Emery's thread here - back to UI ...

Emery - why note post a detailed list of everything, point by point you would like changed in the UI. I think that would be constructive.

 

[laguun]

The responsibility for fixing the EDL is almost always with the Online Editor. EDLs are almost never rejected and sent back to Offline.

That seems to be different over here. If someone delivers a defect product, it is usually given back to the one in the pipeline who screwed it up.

Background for this is often also that it is impossible to fix the issues in the online, as only the offline editor knows what was in the EDL, which files have been imported/digitized/generated etc. We easily see 2-4 EDLs a month going back to the offline editors for fixing them a month,

Most of this is because most offline editors don't know *how* to fix an EDL. Offline Editors' skill and talent is creating stories, not technical conform issues.

fully agreed, and this is also the reason why they deliver EDLs, not XMLs.

And CMX EDLs are unfortunately very easy to screw up. Just a few examples:
1) Illegal characters (happens all the time when transferring a file from OSX to XP)
2) Illegal reel names
3) Illegal spacing (happens a lot with FCP)
4) 30fps EDL for 24fps Online
5) DF / NDF mismatch
6) Record TC discontinuity
7) Illegal or incorrectly formatted M2 lines
There are many more... you get the idea.

lets add my personal favorite: reimported files w/o TC, every online editor just loves the popular Shot AIX001 with TC start 00:00:00:00.

Redcine in such a situation should simply signal: EDL parsing error and leave a nice black gap in the TL.

With dissolves and wipes, how will the additional footage necessary on the A and B sides be taken into account? With M2 lines, how will the correct SourceTC be implemented?

Forget wipes, forget dissolves, forget -any- bells and whistles. These have to be redone in online anyhow. Just in and out. Handles would be nice, but even they are not necessary.

Which is why Avid is writing an export-to-XML and there are existing tools for FCP-to-XML.

Hey luki, don´t get me wrong. I know that, you know that. We use XML, and you use XML.

The problem is: 99% of the industry doesn´t.

There will be -thousands- of late night session this spring / summer when redcine will force -thousands- of unprepared and sceptic cutters to, for the first time, work without EDL. They will blame it on red, if their expected workflows don´t work.

They will be reluctant to edit in a workflow they don´t understand. And many of the facilities have millions of dollars in gear which simply -can´t- output XML.
This will damage reds reputation and bring it in the "its complicated to work with it"-gear category, which many clients avoid.

We already have to spend over one hour to explain the average clients editor what to do, and they often feel, for good reason, pretty unsecure and say: "Its a workflow i never did, i can not guarantee for it". If you tell them: give us a naked edl, only in/outs, note the rest, thats the language they understand.

Even here, you're starting to add features! "...handles would be a nice addition." It would have to be variable, because 4 frames would be perfect for some, bad for others. Then there needs to be error handling in case the handles extend beyond the R3D file. Also would need GUI additions to handle that.

I said, even handles aren´t necessary, would be a nice addition. I said: leave out -anything- complex. in, out is the necessary
how much work is that, one-two manweeks and one-two week qa?

None of this is impossible, but you've sort of proved my point for me... there is no such thing as "just EDL support."

No luki. Its as easy as in and out, everything additional is luxe. I know, having EDL in redcine would be reducing one of the silver-bullet selling point for scratch.

Bottom line - REDCINE is not a conforming and online tool.

And thats ok, however it is the way to make raw R3D useable for online systems, and offline systems feed EDL in 99% of the typical scenarios.

There will be good EDL -> XML conversion tools for the most popular offline systems. So why that is not sufficient?

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA

Its sufficient, but its worse than anyone else's work flow (sony hdcam, arri, thomson, panavisison, they all can be easily used with edl), implements many problems with unaware offline editors (as they have to leave their proven methods), locks out anyone who doesn´t use "the popular offline systems" or not the most recent version of it and adds a unneccessary layer of possible screwups to any non supervised edit.

Furthermore, we will see lots of 3hrd EDL to redcine parsing xml tools, type "fast hack, mark II" out in the wild. Probably one from us as well. There will be no version control over these softwares and it will generate another layer of problems.

To close, let me tell you my motivation to -highly- recommend implementing basic edl into redcine.

Our inhouse workflow stands. No problem there.
ANY external workflow is highly problematic.
There will be tons of calls from editors (we never saw before as only producer and dp rented out) asking "WTF where is the edl???". You can´t control 3000 cameras in rental. This summer will be pretty interesting when thousands, or even tens of thousands of editors run into an redcine trying to import their edl.

 

[Mark L. Pederson]

Furthermore, we will see lots of 3hrd EDL to redcine parsing xml tools, type "fast hack, mark II" out in the wild. Probably one from us as well. There will be no version control over these softwares and it will generate another layer of problems.

To close, let me tell you my motivation to -highly- recommend implementing basic edl into redcine.

Our inhouse workflow stands. No problem there.
ANY external workflow is highly problematic.
There will be tons of calls from editors (we never saw before as only producer and dp rented out) asking "WTF where is the edl???". You can´t control 3000 cameras in rental. This summer will be pretty interesting when thousands, or even tens of thousands of editors run into an redcine trying to import their edl.

Yup. The calls are already starting.

Luki - what you, Jim and the REDCINE team need to keep in mind is this:

9 out 10 Scratch customers have in-house proprietary tools - meaning scripts and apps coded in-house.

We do - and I am pretty sure that we are one of the SMALLER Scratch customers.

Selling as many cameras as Red is - I can assure you that 9 out of 10 RED ONE customers are not going to have "in-house proprietary tools". Many Red customers just want to shoot - they don't want to code.

Red extends far beyond the market of Scratch, and the needs are greater than the companies you talk to everyday.

I think it's fine to put a stick in the ground and say "we are not going to do this because we don't think you need it". The third parties will take it from there. The interesting thing with this FREE APPLICATION (Redcine) is that as the third parties go after their slice of the RED PIE - well ... you know what I am thinking ...

 

[CJ Roy]

Back to UI-

The library is almost unusable. I do like being able to scrub through the frames, but I tend to miss 2 out of every 3 times I try to do so.
I would prefer folders, or bins to organize my shots with a thumbnail'ed view.

thanks.

 

[MichaelP]

One of the main issues is that standard EDL formats are too limiting such as have character restrictions, etc. Many facilities are trying to force file-based formats into legacy based formats - XML is just a language that allows the metadata to be expressed in a much more comprehensive manner without the limitations imposed by a CMX 3400 versus 3600 versus Sony, versus Grass Valley, etc.

The conform application needs to see the EDL, but I think the pull list approach for RedCine is the right one since the NLE is in a better position to export the lists for all sources with its own optimizations and handles based on its own composition structure - a single XML representation for a multilayer composition is much easier to handle than several individual EDL's that may or may not represent the same shot and get pulled twice or more.
Of course this brings up change management which is a whole other issue.

At the front end of the process though, I think RedCine GUI could be optimized to better manage dailies as the file-based telecine it is starting out to be.

Michael

 

[Gavin Greenwalt]

What I don't like about the library view is that it seems to believe I have already chosen the "Good" take. But I've never done that when I have REDCine open. All clips are created equal until they hit an edit bay. I would like to have a way to more easily work inside the clips in each column. The current "here is an extremely rough edit of the chosen good takes" is more applicable to a grading workflow than a dailies/review workflow.

 

[MichaelP]

Following is a CMX3600 EDL template that has been modified to allow for 16 characters in the source. Character type is limited at time of tape name creation in the NLE to conform to standards, but tape names imported via Logs can bypass that limitation.

TITLE: REDtest
FCM: NON-DROP FRAME
001 A002_C003_070913 V C 16:25:58:11 16:26:03:17 01:00:00:00 01:00:05:06
002 A002_C003_070913 V C 16:26:10:07 16:26:14:01 01:00:05:06 01:00:09:00
003 A002_C003_070913 V C 16:26:14:01 16:26:14:01 01:00:09:00 01:00:09:00
003 A002_C003_07091B V D 024 16:26:19:19 16:26:24:04 01:00:09:00 01:00:13:09
*BLEND_DISSOLVE
004 A002_C003_070913 V C 16:26:31:17 16:26:37:16 01:00:13:09 01:00:19:08

Of course this would not be imported into any system that adheres to the CMX3600 specification unless it too was modified. The XML allows for much more flexibility and mapping as needed.

Michael

 

[Patrick Tresch]

REDCINE UI - Add Comments

Would it be possible to add small comments on shots in library and in the stack. It's great versioning but sometimes it's confusing. It would be great to be able to add even numbers/letters... any coments, just by writing over a clip.

Thanks.

Patrick

 

[Gavin Greenwalt]

Hint: use the keyboard.

See, the normal menus are there for casual users and those just learning but the keyboard shortcuts open up a 'single-click' UI for experts.

I see you don't use a tablet.

Ideally your application (imo) should be usable with less than 10 hotkeys. At most you should only be using 4 hotkeys for 98% of the work.


Just for example (changing a brush size):
Photoshop:
Right click. Click on tiny hard to click slider. Adjust. Click off of window. See if your brush is the size you want it to be. Rinse and repeat if your guess was wrong.

C*, Painter, Mudbox, etc...:
Ctrl+Click and Drag to desired size.

 

[John Tissavary]

I see you don't use a tablet.

Ideally your application (imo) should be usable with less than 10 hotkeys. At most you should only be using 4 hotkeys for 98% of the work.


Just for example (changing a brush size):
Photoshop:
Right click. Click on tiny hard to click slider. Adjust. Click off of window. See if your brush is the size you want it to be. Rinse and repeat if your guess was wrong.

C*, Painter, Mudbox, etc...:
Ctrl+Click and Drag to desired size.

Amen to that. Even Shake & Nuke have this, and their paint functions are abysmal for the most part. A difference between pro apps and a lot of consumer/prosumer apps: workflow is as important as the fuctions of the tools themselves.

I'm not saying pro apps don't have problems & convention issues either, and I think there's always room for improvement, but it's important to maintain development focus on workflow speed rather than initial learning curve. This is not software for the casual user - we're making a living from it.


cheers,

jt