UI Rant...

[Emery Wells]

Red and I love each other but sometimes you need to give a little tough love. I know it's been discussed elsewhere but the lack of OS conventions in RC is atrocious and feels like an app from 8 years ago. I get that RC is based on the code from Scratch, but many of scratches conventions just don't translate well to RC.

Take for example the 'invalidate' button that shows up after rendering. Im not sure what purpose it served in Scratch but I don't see it serving any purpose in RC. Why must I invalidate my render to render again? Perhaps a safety so as to not accidentally erase a previous render? While that's all fine and good, a modern app would simply warn you once you hit render and give you the option to quit or proceed.

Can we talk about the 'yes/no' convention used throughout the app? The word asinine comes to mind. If I want to delete a stack, I have to click 4 times before its finally gone. First I select the stack and hit delete, then confirm - yes. You'd think this was good enough but then a 2nd delete button shows up. Ok, so delete again, then confirm - yes. If I were to make a mistake and accidentally delete something or change a setting, Id simply visit my good friend Command Z. No need to warn me 4 times.

This is not meant to take away from any of the fantastic work the RED team has been putting out. I've been using RC fairly successfully for quite some time and the app has great potential but I would throw the UI away and start over. Most of the structural/workflow elements of the UI work beautifully but the implementation of sliders, buttons, and mouse events are in the dumps. I would even contribute to the design just to be a good sport about it.

Being the Red fanboy that I am, I find it difficult to say anything negative about this revolutionary company but sometimes you have to call a spade a spade and well... RCs UI is seriously lacking :) Course, that is easy to say from my seat, a designer who gets to work in pixels, not code.

Ahh, there I said it. I feel better now.

[Ariana]

Can you get a money back redfund for RedCine?

[Emery Wells]

I think it's *very* important to note that RedCine is FREE. I obviously wrote that post in the heat of the moment after a long battle of trying to get RC to work like I wanted it to.

[pliny]

OK so it's free -- but it's also the only viable tool for transferring finishing-quality media from Redcode, or in some cases such as 4k 16x9, the only option for even generating dailies.

The camera and the workflow are a single system, and part of what you pay for. Unless Redcode RAW is widely licensed or up on Sourceforge, criticism of the "freeware" Redcine is 100% in bounds.

[Irri]

Can you get a money back redfund for RedCine?

That's a very simplistic view of things. REDCODE is locked down at the moment so there is very little in terms of options for outputing. I sent out 6 commercials yesterday at the settings RedCine was willing to let me.

It's only fair that RED know what issues really make life difficult.

edit, pliny beat me to it

[Dylan Reeve]

I've never been a huge fan of application that disregard the conventions of their host OS. But it's increasingly common, especially with more complex apps, and applications where multiplatform support is required.

Even Apple's own 'Color' throws away all conventions (especially annoying with OS x and Windows where the actual filesystem setup is not the same as it's portrayed through the OS tools).

[Joel Kaye]

Can we talk about the 'yes/no' convention used throughout the app? The word asinine comes to mind.

Bizarre is what came to my mind.

I'm guessing we'll see RedCine and Scratch alternatives appear after NAB if what Jim says is true about codec development being released to 3rd parties. That would be a boon for the camera.

[Lucas Wilson]

That's a very simplistic view of things. REDCODE is locked down at the moment so there is very little in terms of options for outputing. I sent out 6 commercials yesterday at the settings RedCine was willing to let me.

It's only fair that RED know what issues really make life difficult.

edit, pliny beat me to it

I just want to jump in and say that there needs to be MORE of this sort of commentary. Reasonable professionals can discuss and criticize things reasonably. It's called peer review and is an awesome thing.

For anybody reading this... if you've got issues or don't like something, for chrissake say something. If you say something, it might not get better. But if you don't say anything, it definitrely will not get better!

Best,

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

[Joel Kaye]

I just want to jump in and say that there needs to be MORE of this sort of commentary. Reasonable professionals can discuss and criticize things reasonably. It's called peer review and is an awesome thing.

For anybody reading this... if you've got issues or don't like something, for chrissake say something. If you say something, it might not get better. But if you don't say anything, it definitrely will not get better!

Probably the simplest thing would be an hour or so of video training going through a handful of typical corrections and complete workflows. This may be addressed already, but I'd like to see color bars and/or other reference images inside the app so there's a quick sanity check you can bring up on your monitor.

The other feature I'd like is RGB levels and curves. Graeme mentioned that had been nixed, but the reasoning was pretty weak to me. They were worried people would screw up their images.... uh... yeah. I think at $25k for a camera people should be allowed to screw up their image if they choose to... and the best place to do it is with RedCode Raw.

[Mark L. Pederson]

I just want to jump in and say that there needs to be MORE of this sort of commentary. Reasonable professionals can discuss and criticize things reasonably. It's called peer review and is an awesome thing.

For anybody reading this... if you've got issues or don't like something, for chrissake say something. If you say something, it might not get better. But if you don't say anything, it definitrely will not get better!

Best,

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

Glad you feel this way!

How close are we to a new REDCINE build?

I don't want to start a "premature" XML import/export rant because I have been assuming (hoping) we are gonna see it (more) flushed out in the next build - I know you guys are all working hard, but XML is critical - and I'd like a little comfort factor of what's going to get done (or not get done) in that department - anyway, like I said - I would rather see the next build first - but since you want MORE commentary - I'll bring it soon -

[Emery Wells]

I just want to jump in and say that there needs to be MORE of this sort of commentary. Reasonable professionals can discuss and criticize things reasonably. It's called peer review and is an awesome thing.

For anybody reading this... if you've got issues or don't like something, for chrissake say something. If you say something, it might not get better. But if you don't say anything, it definitrely will not get better!

Best,

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


Well, Ill leave bugs and output errors to another thread as this thread is focused on the human machine interface model.

There are two aspects to the model:
1. Beauty
2. Functionality

Im a strong believer in both. If RC was a girl, I probably wouldn't hit on her until I was thoroughly wasted.

The functionality is the bigger, but less sexy issue. One big problem I have is managing clips in the timeline/library. I'd expect to be able to lasso select clips and hit delete. Id expect to be able to shift select a list of concurrent clips. Id expect to be able to command select discontinuous clips (this actually works).
Edit: while experimenting during the writing of this post, I realized I can shift click and ⌘shift click stacks but you have to click in the clip bar. It also does not behave exactly as you'd expect. Play around, you'll see what I mean.

The whole concept of stacks in RC is less useful than it is in Scratch. The 'depth' slider is not intuitive nor needed when importing clips into RC. I can't think of any reason you would not want each clip in it's own stack. I like the idea of a stack for being creative and trying various looks but it could really be confined to appearing as a side stack when using the color tab. On the topic of managing clips, the enable all is also wonky. Id expect to be able to right click and either enable or disable an individual clip. When using the button, you should be able to enable all *and* disable all. Disable all would be more useful for me in the way I've worked with the app thus far. Typically Ill have a whole project loaded and I'll need to export a clip or two. So id have to disable each clip one by one.

The timeline in the library is slightly confusing. Im constantly attempting to click drag the light gray bar (clip selector) that is directly above the timeline which looks remarkably similar to the timeline slider itself. It's not that I don't know which slider is the timeline, but even after using the app for months, I still find myself gravitating towards clip selector. Why is there a clip selector there at all? This convention needs to be revisited.

The yes/no buttons make no sense to me in most instances they are used.

For turning options on and off I'd prefer to see a checkbox.

One of the conventions that is fairly unique to RC that I do like is gestures. However, the gestures should have an off button. Where are the preferences? We would have them if we followed OS conventions :)

Ill think of more stuff later. That's all for now.

[Gunleik Groven]

AS RC is the only practical way to do important stuff with @ the moment...

Apply changes to individual color-channels, including a blur function

[pliny]

Along the lines of Mark's XML feature request: EDL import. I have commercial clients making edits and sending me EDLs of their selects, which I output & pipe back to online or VFX. This over & over & over.

So ... lucky me, I have a Scratch system, so conforming my Redcode to EDL is a snap. Without it, I'd be SOL. But we really need to see this in Redcine as well.

EDL/XML and other basic data management tools are critical for using Redcine as a Digital One Light hub.

We'll talk about distributed rendering some other time .........

[pliny]

Emery is right - we're already hijacking his thread.

I recall a long time ago the stacks in RC were pitched in a shot/take model. Each stack would contain takes from a certain scene.

But since RC is a "digital one light" app, I have to agree with Emery, stacks don't make a lot of sense. I always set depth to 10 before import.

Stacks may be useful for versioning different looks -- 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.

[laguun]

I just want to jump in and say that there needs to be MORE of this sort of commentary. Reasonable professionals can discuss and criticize things reasonably. It's called peer review and is an awesome thing.

For anybody reading this... if you've got issues or don't like something, for chrissake say something. If you say something, it might not get better. But if you don't say anything, it definitrely will not get better!

Best,

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

i fully agree.

[Brent J. Craig]

I have never understood why any software would reject the normal UI conventions we are all used to. WHY throw away the years of experience we all have on Macs and PCs and invent something totally new?

It's like writing a manual in pig latin - sure people could figure it out, but why not just stick with what people know?

I realize once you are over the learning curve that some Scratch conventions could be pretty time-saving, but you could keep those and still have a standard UI. Photoshop is an excellent example of software with a standard UI but also many timesaving shortcuts for people who wish to learn them.

[Ariana]

OK so it's free -- but it's also the only viable tool for transferring finishing-quality media from Redcode, or in some cases such as 4k 16x9, the only option for even generating dailies.

Understood. Where do Redalert and redline fit in?
Do they provide diffferent functionality?

[John Tissavary]

I have never understood why any software would reject the normal UI conventions we are all used to. WHY throw away the years of experience we all have on Macs and PCs and invent something totally new?

It's like writing a manual in pig latin - sure people could figure it out, but why not just stick with what people know?

I realize once you are over the learning curve that some Scratch conventions could be pretty time-saving, but you could keep those and still have a standard UI. Photoshop is an excellent example of software with a standard UI but also many timesaving shortcuts for people who wish to learn them.

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...

Adobe's obsession with nested menus is something I just can't understand. It's like 1980's UI convention... JUST WON'T DIE!!!!!!

[Gavin Greenwalt]

Unique UIs are the domain of high end software period.

It's a question of marketshare and the demands of efficiency. If your entire job is to run a single application then you want it to be as fast as it possibly can be. Sure it takes a few days->weeks to figure it out completely but it's like the dvorak layout once you figure it out then you're golden. But the Dvorak layout argument raises the sort of 'third rule' of a unique UI that I'm not sure REDCine lives up to and that's whether or not your application is complicated enough to warrant getting clever. Sure the Dvorak layout is wicked fast. But some of us can type in qwerty as fast as we can think. The limitation isn't the interface it's the decision maker.

If however you create a tool that is used once a month by a handful of people then you have to use conventions because nobody can justify learning your design philosophy.

I actually greatly dislike high-end software that uses conventional interfaces exclusively. What makes Maya great (and in my mind one of really the only things which makes maya great) is its gestural marking menu. It's possitively amazing and completely nonstandard. A perfect comparison of a piece of software that is "Standard UI" vs "Unique UI" is After Effects vs Combustion. Now mind you in the latest version of AE they've made huge strides to ripping off combustion but they still aren't quite there as far as the UI. Millions of undockable windows was a nightmare.

I think REDCine is kind of on the line. While many of the efficiency improvements are "nifty" I don't know that people spend enough time in REDCine to warrant having to learn the unique interface. It's more of a get in get out kind of application and could possibly benefit from a more conventional UI. For example gestures are still really iffy on dual monitors which makes sense in a scratch workstation where every aspect of the system is under control, but on a standard desktop you have all sorts of crazy layouts and uses.

----

BTW Photoshop's designers have publicly admitted that even with the CS3 improvements the Photoshop's interface sucks.

[Lucas Wilson]

Along the lines of Mark's XML feature request: EDL import.
...
So ... lucky me, I have a Scratch system, so conforming my Redcode to EDL is a snap. Without it, I'd be SOL. But we really need to see this in Redcine as well.
...
EDL/XML and other basic data management tools are critical for using Redcine as a Digital One Light hub....

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

[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

[Harry Clark]

I agree with jeremyn, Emery and some of the others that the lack of basic OS conventions make for a frustrating experience. The image controls are really rich and nice, the basic workflow is fairly straightforward, but Emery is right on when he talks about the need for checkboxes and a better GUI overall. Preferences would be nice. The ability to "Hide" the application in OS X. The ability to toggle gestures like swiping on and off and choose keyboard shortcuts if you like.
Performance could be better too. Scrubbing through the timeline seems like Avid circa 1988. ;) But that could be my machine too.
I'll be interested to see what the next release brings.
Cheers,
Harry

[Bruce Allen]

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.

[ and ] keys lessen the pain!

Agreed, Photoshop UI should be more tablet-friendly like the other-mentioned programs...

Bruce Allen
www.boacinema.com

[Gavin Greenwalt]

[ and ] are behind my tablet though. ;)

Oh well I have an Intuis 3 so my touchstrips have solved that minor aggrevation. But it's still a symptom of a larger problem.

Painter and Alias Sketch on the other hand have got their shit together on the UI.

[pliny]

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


Thanks for the thorough and well-reasoned reply. My response is as follows:

- Don't want EDL support in order to treat Redcine like an online NLE. It's clearly not meant to be that.

- I do want EDL support because that's what my clients send me, it's what they know, and I need to support what they know, not what I know.



To flesh it out, here's a typical scenario:

- Clients shoot 2-3 hours of Redcode on a commercial

- We give editorial offline files the next day. (This is often something tragic like Avid DV. But that's what worked 5 years ago, and that's what they know.)

- Client cuts for weeks and weeks, haranguing over the edit with their clients. Then one day I get a call at 8pm -- here comes an EDL, need this footage in TIFF/DPX/openEXR/whatever tomorrow morning for VFX, please.

<shameless plug>And yes, Offhollywood can absolutely do that. We're they guys to call to process your footage correctly and quickly.</shameless plug>

A number of options here:

1. Why not ask my clients, hey, how about you install an Avid Plugin to export Redcine XML?

Because that will make their heads explode. No, really. *Most* high end commercial clients, in my experience, are high-end creative folks. Not workflow geniuses. They don't want a learning curve. If there is a learning curve, they would just as soon shoot film. And they expect everything to flow with us the way it would with a film lab.

The drum I like to bang is this: Red can compete with 35mm quality and pricing. It also needs to compete with 35mm schedules and turnarounds. In fact, in most cases I need to *transparently emulate* a 35mm workflow. (Explaining the no-tape thing and getting the "which codec would you like" question answered is hard enough.)

So: learning curve = bad; transparently emulating 35mm workflow = good.

Moving on:

2. I can load up their EDL in Scratch, but I shouldn't need Scratch to just process Redcode.

3. I can manually re-create the EDL edits in Redcine.

4. I can run it through an NLE via Ian Bloom's or some other tool.


Options 2-4 all work, with varying degrees of cost and complexity. By "complexity" I don't mean that it's "hard", but that it introduces more variables. If I am servicing one or two jobs, that has a small impact. But if I need my Red workload to be able to scale smoothly, then I want as few variables as possible. More individual steps and manual input = more (inevitable) human error, more time = more cost.

So all of this talk about EDL is really a talk about minimizing labor by managing down complexity. It's probably a hobby horse I will bang on more here. Workflow problems need solutions that work not only from a tech perspective, but also from a business perspective.

Your reply makes tons of sense from a technical perspective: "X works, so why not do X." That's fine if I am post-supering a feature film which generally moves slower than a commerical. (<shameless plug>Why yes, Offhollywood *does* have two Red features in post.</shameless plug>) But it's a different story if I have a company servicing a large churn of Red jobs day-in and day-out.

But if I am servicing a brand new, still skeptical client whom I just spend 3 weeks convincing to "take the plunge" with Red, they want no surprises or scary words like "XML".

And likewise, on my end, I want as small of a margin for errors (and as high of a margin of profit) as possible. It's not a matter of what works at all, but of what works best, and how things work inside a business when you start scaling up the workload.

Does this rambling make any sense?

[pliny]

Just saw this:


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.

This is essentially correct. I brought up the whole topic because I am getting pull lists (selects with handles, not "flash to flash") in EDL format. If I can just plug it in to RC and go, I am golden. Especially if I have to do it 20 times a day. (No we're not there yet but we will be. I see seas of Skulltrail racks receding into the distance...)

[SF Geek]

Just to make it clear. Is Luki the guy who is making and updating RedCine?? If not, then why are there no responses from the Red team? If they can respond to people's posts about their unpacking experience, surely this thread has just as much importance.

[Brent J. Craig]

Pliny, for some reason your shameless plug markup isn't being rendered properly in my browser.

:-)

[John Tissavary]

Just to make it clear. Is Luki the guy who is making and updating RedCine?? If not, then why are there no responses from the Red team? If they can respond to people's posts about their unpacking experience, surely this thread has just as much importance.

Luki is Lucas Wilson from Assimilate, which is the company that develops RedCine for Red (they also are the Scratch folks). Therefore he is a great person to talk to about RedCine, and possibly the most direct pipeline to the actual RedCine coders.


cheers,

jt

[Joel Kaye]

Just to make it clear. Is Luki the guy who is making and updating RedCine?? If not, then why are there no responses from the Red team? If they can respond to people's posts about their unpacking experience, surely this thread has just as much importance.

I've been following this a long time and I'm not even sure what the delineation is.

Clearly this is RED's problem to solve. Luki may be their only conduit to the solution - but the problem is RED's.

Like Pliny and Mark say, you shouldn't need Scratch to use RedCode Raw efficiently. It's a critical part of how the camera was designed to work for optimum image quality. Those tools should absolutely be included as part of the price. For a bunch of guys that are such image quality freaks I don't even understand why there's a discussion on this topic.

Too many knowledgable CUSTOMERS have made solid arguments as to why EDL support is required.

[Lucas Wilson]

... Clearly this is RED's problem to solve. Luki may be their only conduit to the solution - but the problem is RED's.

I am NOT a REDCINE developer and I am not the "conduit to the solution." Oh were it that simple. :)


Too many knowledgable CUSTOMERS have made solid arguments as to why EDL support is required.

No. Some very knowledgeable customers on this forum have solid arguments as to why EDL support is required. I (and many others who just aren't as loud as me) have equally solid arguments why it is a bad idea.

This is the process of development and peer review... constant push and pull between customers and product design.

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

[Brent J. Craig]

... constant push and pull between customers and product design.

Which, as we have discovered, seems to be a great way to put out a product.

I saw a demo last week of the Scratch 'online' process and it is impressive. Now to make it accessible...

[laguun]

I am NOT a REDCINE developer and I am not the "conduit to the solution." Oh were it that simple. :)

come on, you can admit it now!
your little revenge evil masterplan for our sometimes pretty different opinions (screwing up >2 dozens of computers graphic cards here with redcine) worked out successfully, there is no more reason to hide your sinister motives :)



No. Some very knowledgeable customers on this forum have solid arguments as to why EDL support is required. I (and many others who just aren't as loud as me) have equally solid arguments why it is a bad idea.

This is the process of development and peer review... constant push and pull between customers and product design.

Offhollywood (who is a real enthusiastic customer of red and yours) and i (who is a triple red customer and uses systems from your competition) have pretty much the same position.

Its not us who have a problem with redcine/xml or any kind of sophisticated workflow, its the usual customers. They are feared (for good) reason, don´t have yours, ours or offhollywood en detail knowledge and understanding but simply the "i just want to have it to work!"-approach. It is cruicial to win over these folks (which will hopefully make the huge majority of red users summer/winter 2008) asap, and redcine (or redalert or redline) desperately needs EDL support for that.

They won´t complain if we instruct them to deliver a non-timeramp/timefx, non dissolve/wipe, non-audio, handlefree, no fx, singletrack -errorless- EDL (they know that from many situations as film out). But they get nuts if we tell them what they are doing wrong, that they would have to buy another system, install plugins or use non-approved command-line utilities etc.

It makes their first experience with red a terribly complicated one, we dont talk to producers but to editors, we don´t do business / movies but unsuccessful tech support in this situation. Try to convince a 55 year old avidoffline star-cutter lady to install a tool on her holy meridian-basing Mediacomposer (running on OS9) in the middle of a production on which she edited 2 top-ten movies in the recent 4 years (thats a real case) and you´ll understand where we are coming from.

p.s. /shameless plug deluxe/ our digital lab is even better than offhollywoods, delivers hdcam sr, hdcam and blueray dailies along with the files - and is cheaper and we have better looking female employees en masse /shameless plug deluxe off/

[Mark L. Pederson]

p.s. /shameless plug deluxe/ our digital lab is even better than offhollywoods, delivers hdcam sr, hdcam and blueray dailies along with the files - and is cheaper and we have better looking female employees en masse /shameless plug deluxe off/
wait 'till our new facility opens in May ...

[SF Geek]

As far as Laguun was saying, if I'm trying to sell the camera, then I need more info. I don't know how to sell the post workflow. I'm a DP and i know how to sell it production and quality wise. I need, at the least, the fundamentals behind what is actually necessary to edit lower-res proxies or renders and then use RedCine to render out only what is in the final cut. What are my solid options?

Hey Luki you know anything about that new version of RedCine? Release dates, features, fixes?

[Chris Swinbanks]

p.s. /shameless plug deluxe/ our digital lab is even better than offhollywoods, delivers hdcam sr, hdcam and blueray dailies along with the files - and is cheaper and we have better looking female employees en masse /shameless plug deluxe off/all these shameless plugs, deluxe or otherwise, are groundless without photo's :bleh:

I have to agree with many of the posts made though..., creating a directory then having to confirm "yes" and then also "select it" to use it is just creating extra steps, invalidating the previous output before testing a new output is a pita when testing different levels of NR, detail etc on single frames (or clips)... hopefully the next version of Redcine will have sharpening and the other features all working in the preview window so I don't have to render out single frames to see a function is working or having any effect at all...

all in all pretty happy with it so far though...

Chris

[laguun]

wait 'till our new facility opens in May ...

hrrhrr
as youre in NYC and we in berlin i think the competition might be not to hot :)

Our basic layout is 3 DIs, 7 editing and a dedicated backbone of 64 cpus for red with 2 DD sound studios. 3 red cameras, full hdcam gear (vcrs, class 1 crt monitors, cameras etc), full lens selection (zeiss primes / angenieux zooms) and the usual tapeformats from umatic to dbeta. What we won´t offer is filmrecorder and scanner inhouse, undecided are 2K/4K projection. typical small/mid studio if you want so.

[Joel Kaye]

I am NOT a REDCINE developer and I am not the "conduit to the solution." Oh were it that simple. :)


Very helpful clarification. Thanks. See... I knew it was RED's problem. It would be nice if they solved it. Or hired you to since you've already got the code for Scratch. See, I've got your back on this one Luki.




No. Some very knowledgeable customers on this forum have solid arguments as to why EDL support is required. I (and many others who just aren't as loud as me) have equally solid arguments why it is a bad idea.


well... this is where I'm totally weird. I tend to give more weight to people who actually bought the product and are dealing with end clients. Crazy, I know. You make compelling arguments but to me Mark and Co. make more compelling arguments because they are doing it for real.

If someone else at a RED oriented post house that deals with RED footage clients all day wants to weigh in and agree with your points and explain why their non-techie creative clients are doing just fine with XML THEN I think your thoughts would have more merit.

[Ariana]

Like Pliny and Mark say, you shouldn't need Scratch to use RedCode Raw efficiently. It's a critical part of how the camera was designed to work for optimum image quality. Those tools should absolutely be included as part of the price. For a bunch of guys that are such image quality freaks I don't even understand why there's a discussion on this topic.

Too many knowledgable CUSTOMERS have made solid arguments as to why EDL support is required.

Is it really the place of a camera company to provide conform and EDL tools for free? Do sony, panasonic, thompson, jvc, arri, or panavision privide anything close to redcine or even remotely close to conform or edl support?

I'm not sure I want RED to start doing post tools when thats not their expertise. I want to focus on better quality images and faster processing and third party solutions. I don't expect to get everything for free just because I can ask for it here. But I will...

Can I have a free scratch system with every camera?

[Harry Clark]

Because that will make their heads explode. No, really. *Most* high end commercial clients, in my experience, are high-end creative folks. Not workflow geniuses. They don't want a learning curve. If there is a learning curve, they would just as soon shoot film. And they expect everything to flow with us the way it would with a film lab.

The drum I like to bang is this: Red can compete with 35mm quality and pricing. It also needs to compete with 35mm schedules and turnarounds. In fact, in most cases I need to *transparently emulate* a 35mm workflow. (Explaining the no-tape thing and getting the "which codec would you like" question answered is hard enough.)

Yes, Mark. Amen to that. I STLL have to explain P2 import to some editors. The process just needs to be as simple as 35mm to get adopted. NOT harder, or different. Creative people like to create, and not learn new technical tricks every 3 months.
Hey Mark, check your email and PMs. I need more info about rates etc. so I can have some knowledge when I refer my clients to you guys. Or is there someone at the office I should be speaking with?
Yes, Ariana. It IS the responsibility of a camera company to enable post workflow when their camera shoots a new and unsupported format. Both Panasonic and Sony had cross-conversion apps and plug-ins for Final Cut concurrent with the development of digital media formats. They also had very simple workflows for using these cameras in a broadcast environment where (lets face it) 90% or Red One cameras will be shooting for. But you're right. They don't provide an end-to-end solution for free.
But maybe Red should have thought of the high end user and developed a more robust post product for those who would pay. I've posted ad nauseum about a hardware solution so I won't do it again. (but I would probably buy into it!)
It seems like it's almost there with Redcine. I just wish it were as far along as the camera.
Cheers,
Harry

[Gunleik Groven]

For a quick summing up on my side

1. The whole RedCine/RedAlert/CML is "free" thing, is a mute argument as long as they are the only way (besides Scratch) to access the footage. In other words: They're not "free" but "part of the camera". Simply because we have nowhere else to go.

2. (and this is a good thing) Almost all decently shot Red material I've seen, needs a first light/one light treatment before CC. This is especially true if the final delivery is for a lower bitrate medium, like TV. RA/RC is a good solution for that.

3. BUT this makes RA/RC a PART OF OUR CURRENT WORKFLOW. An extra step which implies more than the "capture from tape" idiom from video, and is more similar to filmscans.

4. The difference is that one have a good way to online/offline filmscans, and it's not there yet for Red RAW

5. Yes. I know about the proxies, but the very qualities and advantages of RedRAW is lost when you use them as a base for your whole workflow....

6. .... (and this is for FCP) UNLESS we're given the "RedCine within FCP" workflow earlier hinted at, where you can change the rez and debayering algorithms of the proxies within FCP and do One Light within the app....

7. As long as the above isn't the case, we need a fluid way to get from our NLE to RC for OneLight, and back for online.

8. The alternative Could be to convert/onelight ALL shot material and spit out proxies/online material before editing, but that would be plain silly for anyone but people selling harddisks and/or computing-cycles. And it is counter-intuitive UNLESS you convert to 16-bit TIFFs @ 4k. Do that and have fun....

THUS
For anyone in a (semi-) high throughput environment who, for a number of reasons does NOT want to buy Scratch (and I think price here is a legitimate reason, at least in small markets. There are many more people just in New York than in Norway... :) the workflow is quite... not there... yet. And the "Well, then Shoot F23" thing is lame, as there are none of them here. There will be 20+ Reds, though...

We need (and here are "the external editors" quite important) a simple way to "send to RedCine" from our NLEs, Red Cine needs to controll the CLM, so that we can spit out our onlines through a renderfarm, as we finish the onelight.

I actually am quite buying into the "Scratch is good" thing. But as long as the camera is sold as a cam where you can "edit on any QT enabled NLE (with that NLE's given shortcomings)" not as "The Perfect Partner To Your Scratch Suite", this issue needs to be adressed. Not at least because so much of Reds technical (image wise) advantage lays within this concept. High bitrates , high colorfidelity and high resolutions. I've seen VERY EXPERIENCED POST PEOPLE mess up their Red Footy because of this very issue, and dismissing the camera because of the results they got. They don't want to (and don't need to) "understand Red". They need to get their work done, and HAVE sufficient tools. they just don't want to tamper with those Red Applications. "Hey. They don't even have a proper EDL function".
And if they don't already own a Scratch, but a competing product... or two... with proper support in their area...

So:
RedCines communication with other editing tools is crucial for the cams acceptance as a pro tool, (for others than geeks) - for quite a while.

Untill other solutions exists, we NEED RedCine to send out a 2nd video signal through (preferably dual) HD-SDI for external, proper monitoring. That would also open for playback to tape, given that your system can handle it... If that's NOT acceptable for the Assimilate deal, well, then - put TC or whatever over the output.

If not, there should be a "Red Pro" basic package, sold along with Scratch, which I don't think is a wise option, but would illustrate the "Go Scratch or be on your own" issue a bit more clearly.

All this said:
I really have come to like RedCine a lot. I think it's an extremely clever program that does what it should really well. It SHOULD have some way to work on individual channels, as the blue channel is an issue. That would still not make RC a CC tool, just better at what it does.

AND. I know I'm part ov an evolution within the revolution, and I have patience. I still think these are important issues to address....


Gunleik

[Ariana]

It appears that with XML support in redcine that third parties could now easily support EDLs quite easily. Same for redline too? If redtools can do this I think it's a very positive step forward to enabling thrid parties and allowing red to focus more on their core. That's more important then spreading too thin and trying to solve all the workflows themselves.


With all the changes happening to the camera and software, I think it's obvious red is not dumb and will make the right choices. The expectation to have a finished workflow right now today seem to be ignoring the speed at which the camera is being developed and the constant improvement. I expect the same with the software and look forward to the improvements in each release. I believe the presumption that red needs to be told repeatedly what they need to implement is false. I do believe they know what they're doing because no one else has been able to even come close.

[Gunleik Groven]

Agreed.

There is some evidence that posting to this board has helped solving stuff, though:

hot issue
cold issue
PL mount
PL mount grease
And quite a few UI changes

AND they have stated that they want feedback on the apps.

Don't take this as dismay, just as hopefull hints @ what would make thing better.

(And: No. I don't really think they haven't thought about it first. But maybe when Firmware 15 is out, is a good time to look at these issues...)


Gunleik

[laguun]

Is it really the place of a camera company to provide conform and EDL tools for free? Do sony, panasonic, thompson, jvc, arri, or panavision privide anything close to redcine or even remotely close to conform or edl support?

The main difference is that sony, panasonic, jvc, canon etc basing footage with hdcam/dvcpro/hdv can be loaded directly in its maximum quality and/or offline with full tc/edl support into any professional nonlineareditor on any platform. And this is the industries way of working, and it doesn´t work well with reds solution for >95% of the average joe editors.

This is because
a) there is -no- edl support in reds footage pipeline for avid, discreet, quantel, sony, adobe etc - and these are by far the huge majority of the professional market.
b) red will prevent 3hrd party from the mayor players in professional postproduction support until NAB

Therefore red really needs an edl/tc support in one of its tools - if this will not be available soon any red production in any not really prepared posthouse or collaboration between different houses will be slow, error prone, result in less than optimal results and the camera will gain the reputation of the "complicated and slow camera" in postproduction which cant be in the interest of red or its customers.

Furthermore reds needs -wide- support for their codec. Right now, most of the big suites can´t use native redcode raw, the windows world can´t use their codec, and the linux world can´t. This naturally makes any owner of any posthouse highly skeptical regarding shooting on red, instead of embracing it. "Wait and see" instead of "lets go".



I'm not sure I want RED to start doing post tools when thats not their expertise. I want to focus on better quality images and faster processing and third party solutions. I don't expect to get everything for free just because I can ask for it here. But I will...

The camera is useless without its software, as you -need- redcine (or ra/rl) to use its awesome images. Its an -integral- part of the camera. In a Sony hdcam, Panasonic Varicam, Panavision Genesis etc all this processing is built in the camcorder, red has is on a separate computer - which is great for highend work imho.

But the postproduction workflow as it is now, is more incompatible, challenging, complicated and slow than with almost any camera of the competition, which is sad - as red besides that is an -outstanding- camera.

Its early on in the game, and i (and many others hope) that red now, that they successfully designed the most innovative camera which i ever saw since 1989, also closed the missing gaps in the postproduction. Basic, primitive EDL support for redcine and/or redline and freezing the fileformat to allow the postproduction industry to use the cameras excellent footage. The postproduction workflow, as it is now, reminds me of an lamborghini on bicycle wheels who can only run on -one- special racetrack with real slicks.




Can I have a free scratch system with every camera?
hrrhrr, i would prefer more powerful system for networked realtime 4k - would fit the camera better. i´ll have a dvs clipster with mutliseat 4k san and a filmlight baselight, and if we are at it, could we throw in one sony Srx 4k projector?

[BigLu]

Wow Lucas,

That was such a perfect example that lets me believe and assures me. This entire new everything camera, company, codec, workflow, people, ect.

Is gonna be the future.
I get frustrated with things about RC also.
I just wish we were in ver. 3.1 by now where I know things would be so much more fun, stable and useful.
Everything ver. 1 frustrates me to no ends I understand that.

So, I feel the sliders kinda suck, I wish there were scopes unless im missing something, I don't like the curves only has 3 points I feel like I need 4 minimum, I CAN'T Stand how it completely owns my ass when I open the program, saving sucks, crashing sucks, and 3 way color wheels would be oh so helpful. That's my feelings.

Flip side your program is awesome when I figure something new out.
One of my favorites to play with.

Thank you for giving me the feeling that this company is doing everything they can to do this right.

[Patrick Tresch]

i´ll have a dvs clipster with mutliseat 4k san and a filmlight baselight

Hello Iaguun,

How do you hadle RAW files and more specifically R3D files?

Do you use transcoded files from REDCINE/ALERT?

Thanks.

Pat

[laguun]

Hello Iaguun,

How do you hadle RAW files and more specifically R3D files?

Do you use transcoded files from REDCINE/ALERT?

Thanks.

Pat
for us the workflow is indeed debayer in the beginning, not in the end, as with that approach you can work with -any- system and networked without restrictions. Also, you donßt have to render everything at the end of the pipeline, what you have with the existing R3D basing workflows.

but you quoted me out of context - the baselight/clipster/srx4k should be given free with every camera was a joke regarding a former post.

[Ariana]

The main difference is that sony, panasonic, jvc, canon etc basing footage with hdcam/dvcpro/hdv can be loaded directly in its maximum quality and/or offline with full tc/edl support into any professional nonlineareditor on any platform.

That is very untrue. HDV took forever to be supported by any applications!
When I first got an HDV JVC camera, I could do nothing with it for at least 8 months. There was a sample extraction program that barely worked at all.

[Gunleik Groven]

That is very untrue. HDV took forever to be supported by any applications!
When I first got an HDV JVC camera, I could do nothing with it for at least 8 months. There was a sample extraction program that barely worked at all.

... and I think that made a great blow to the sale of the (at the time of the launch) quite interesting JVC cams.

Gunleik

[laguun]

That is very untrue. HDV took forever to be supported by any applications!
When I first got an HDV JVC camera, I could do nothing with it for at least 8 months. There was a sample extraction program that barely worked at all.

correct, we also had one of the first batch and sold it later on.
Also HDCAM was problematic in the first months (due to the whole 1035 -> 1080 issues).

But all theses issues were fixed within some months, in the case of JVC btw. by cineform, which also would like to support red but shall not until april.

[Joel Kaye]

That is very untrue. HDV took forever to be supported by any applications!
When I first got an HDV JVC camera, I could do nothing with it for at least 8 months. There was a sample extraction program that barely worked at all.

And is was a horrible strategy decision. Until Cineform solved it (for $500) that camera was unusable.

I don't think any rational person would advise RED follow suit BUT RED finds itself in a similar situation but with one major difference.

You seem to be proposing that RED should leave it to another company to solve their post workflow issues. Fine, but you don't seem to be considering that currently RED forbids access to it's codec so this problem can be solved by someone else.

Knowing that, what would you suggest?

People here have been asking for one of two things. RED should do it or they should let someone else do it. Those are pretty reasonable propositions I think.

The only other argument is Luki's - which is "you guys don't need it no matter how much you think you do."

I don't think that as reasonable a position. I don't see how that one's a winner for RED.

[Ariana]

What I am proposing is stating the obvious over and over is not going to help the situation. From talking to the guys at red it's quite clear they intend to do everything we want but they're asking us for a little patience on the software side it not trivial instantly do everything at once.

Condemning and harassing red at every opportunity while they are trying to give us the most they can is a very crude approach IMHO.

[robbo]

What I am proposing is stating the obvious over and over is not going to help the situation. From talking to the guys at red it's quite clear they intend to do everything we want but they're asking us for a little patience on the software side it not trivial instantly do everything at once.

Condemning and harassing red at every opportunity while they are trying to give us the most they can is a very crude approach IMHO.

Sheesh - I really don't think anyone in this thread is doing that.:bleh:

I for one really appreciate reading this sort of discussion - it's very open with tremendous insight into the workflow and needs of those that are on a completely different level than me.

Keep roll'n guys ...

[Ariana]

Everytime I read one of these threads it's the same old broken record whining. Obviously Jim responds to requests here but it seems like people now believe that if they complain enough about something that RED will do it. How long do we expect that to last? The more we abuse it, the less we get heard.

[Cüneyt Kaya]

Everytime I read one of these threads it's the same old broken record whining. Obviously Jim responds to requests here but it seems like people now believe that if they complain enough about something that RED will do it. How long do we expect that to last? The more we abuse it, the less we get heard.

1.we are paying MONEY for the camera and the support.
2.the forum helped red to make their product better in a really really short periode of time based upon the informations they gain through this forum for free.
3.and yes, they are maniacs, and want to deliver the best within their limits, we are maniacs too and are pushing them to their limits, and if something is not possible or will not happen (like 2k scaled) its ok..., but if something happens(like so many times over the last months) its
a milestone for everyone...

[laguun]

Obviously Jim responds to requests here but it seems like people now believe that if they complain enough about something that RED will do it. How long do we expect that to last? The more we abuse it, the less we get heard.

Its not at all about complaining.
This forum helps red knowing and understanding what their customers think, what they are loving about product and the company, what they think is bad or should be improved. thats -real- sci-fi customer relationship management.

many manufacturers do not understand how valuable customer feedback is, red does, and if you look at the whole evolution of the red program, there are -plenty- of excellent improvements which red based on customer feedback. from features to bugfixes, from products to policies, also to new softwares, as redline.

and the post workflow is the main construction area right now, the camera itself now is really leaving its beta phase and the post workflow is basicly entering it. jim wrote on another thread: "We don't know what we are doing.
That is the truth.
We have never done any of this stuff before. Everything is new to us. Every single thing.
...
I guess the point is... try to relax on us a bit. We are attempting the impossible. But we can't do it overnight. We are listening. And changing. And improving. Everyday.
All we ask for is your patience."

And therefore every single post on this forum, every information in these forums helps red to judge, align and improve its strategy.

[robbo]

Articulate and precise, laguun !

<brilliant>

[Ariana]

Its not at all about complaining.

Absolutely the concerns are valid but most of it is complaints and demanding that things happen NOW or why things aren't there NOW. There's very little politeness here. Back to my original point, there are graceful ways to give feedback and most of what happens when it come to the most vocal guys is anything but that. It's our responsibility to each other as users/owners to cultivate a positive relationship with RED so we can continue to get such responsiveness from them over the years to come.

There's a reason why other manufacturers don't do what Red is doing. It's because users turn into cranky brats that expect everything for nothing and then the companies listen less and less and less. I've been in a company where that happened and do we really want that to happen with Red?

If you were to plot complaining/whining/demanding compared to nicely asking, you'll notice that red responds more often in the later thread.

My 8 year old know how to get what he wants better than most people here.

[Joel Kaye]

If you were to plot complaining/whining/demanding compared to nicely asking, you'll notice that red responds more often in the later thread.

If you can post specific examples of what you consider rude or whiny it would be helpful.

I just re-read this entire thread and I didn't see a single person demanding anything "NOW". A couple people asked for an idea of when then next update would be out. I personally didn't see much I thought was whiny or rude. I think the rudest thing in this thread was when I said I thought some of the button conventions in RedCine were bizarre. I think I'm pretty much right about that though.

I'd wager most Internet forums are a lot less friendly than this one.

For instance, is this post to you rude in your mind? Just trying to get a frame a reference - perhaps the culture where you live is different from others who post here.

[laguun]

There's very little politeness here...
My 8 year old know how to get what he wants better than most people here.
ahem. self-contradiction

The red post workflow right now isnt anywhere as elegant and cool as the camera. Its slow, complicated and restrained right now. The word is getting out and its time to solve that.

The customer dont need rhetorics, they need open codecs, edl support and no one complained that it would take a months or two from now. red do far was also as cool as they were listening to dps and camera people. The post crowd right now is scared/suspicious and that should change. I fail to see any impolitenesses in stating these facts.

[Lucas Wilson]

The red post workflow right now isnt anywhere as elegant and cool as the camera. Its slow, complicated and restrained right now. The word is getting out and its time to solve that.

No - the workflow you want is slow. There are many very good and very fast workflows being used by post facilities all over the world.

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

[Harry Clark]

Luki,
Please post step-by-step these "very good" and "very fast" workflows so that we cinematographers can give correct advice to our clients regarding post processing.
Right now my advice to them goes something like, "you should download Redcine, but make sure you're not running Quicktime 7.4 and make sure your machine has an ATI card. Do you know Scratch? No? Welllll... Redcine has a kinda different look and feel than other pro apps you might be used to but don't worry it's OK. Or you can use the Quicktime proxies and online your footage later. EDL support is a little weak, but you've got a kid there writing scripts, right? Hello? Hello? Funny, I lost them..."
Harry
ps- that was meant to be funny, not a flame... Sorry if it's not "polite" enough! ;)

[Joel Kaye]

ps- that was meant to be funny, not a flame... Sorry if it's not "polite" enough! ;)

When I have been talking to likely renters the first questions are almost always workflow questions of some sort. People with any level of experience these days get why workflow is such a big deal.

[SF Geek]

Do you need an intel chip to run the reference files? I tried running the reference files on a friend's computer who has a G5. I couldn't get anything but a white screen. He does have QT7.4 though.

Yes, Luki tell us what to say. Post wasn't my bag, but now it has to be.

[laguun]

No - the workflow you want is slow. There are many very good and very fast workflows being used by post facilities all over the world.


Luki, with all due respect.
The speed advantages of a clipster basing workflow compared to a scratch basing workflow are:
clipster is doing multitrack 4K realtime, as dissolves. scratch has to render them.
clipster is doing multitrack 4K realtime colorcorrection. scratch has to render them.
clipster has 4k realtime output. scratch doesnt ofer that, you have to render, and load it into a clipster (or server/dci player) to see 4k in full 4k.

etc.

therefore i fail to see where our workflow with clipster is slow, as, different from scratch, it doesnt have to render everything in 4K in the end, as are planning the ingest while shooting.

But, that is valid for maybe 1% of the camera customers, and thats the important topic here.

a) The typical user wont have a 4K reaktime system as clipster or baselight, he wont have a 2K realtime system as scratch or speedgrade.
b) If the customer has a 2K or 4K di, they will in have in >95% of the installations here have no scratch, but $$$.$$$ or $.$$$.$$$ in quantel, discreet, nucoda, dvs, iridas, sgo, matrix, davinci, pogle etc etc.

And they have to transcode for Avid, Quantel, discreet, Adobe, Sony etc. That takes time and is therfore slow.

If they are on windows or linux they have to transcode -everything- before editing it.

Then they have to use differen custom written 3hrd party beta applications to embed metadata.

Then, in the case of Avid, they have to import everything.

On the way back to redcine, they once more have to use 3hrd party beta products.

All this takes -lots- of time, is complicated and has to be explained to any AVID editor, and discreet commercial guru, and Quantel 60 year old colorist - and that is what i am referring to.

If you think that it makes sense for a $$.$$$.$$$ company as cineplus, who have baselights, infernos, over 60 avids and are on of the rather important customers here in berlin, then you dont understand what we in the field have to deal with.

There is no one-stop finishing workflow (for hdcam and 35mm there is), there is no 4k display capable DI or editing system (for 35mm there are), there is no single operating system solution (for hdcam and 35mm there are) and thats the competition.

This all will change, Red is pretty aware about many of these issues it seems.

But it makes no sense at all to pretend that it would be different -right now-.

FCP is an offline editor, and scratch has to render -everything- in reds 4K. There are solutions who are online 4K realtime editing and finishing and DI, and they are the benchmark for any red customer as us. And the goal should be to have the optimal 4K camera (which is red for many of our clients) for the optimal 4K workflow (which scratch isnt, as its neither 4K realtime, nor has 4k i/O, nor 4K full display - scratch is a good 2K DI with redcode support and once red communicates the redcode raw format to other di manufacturers, we probably see 2K and 4K redcode raw systems).

Scratch is a good system, i always underlined that, but if the customers want 4K realtime or do have clipster/baselight etc as many do here in berlin and elsewhere, the workflow isn´t as streamlined as with 35mm right now, and thats the competition, and thats where customer go away because their workflow doesnt fit to red (but does with hdcam and 35mm) and that is what should change.

[Sean]

I didn't read all nine pages of this thread. But speaking of keeping with the OS's UI, someone mentioned the handy Command+Z...however, Ctrl+Z (the PC's version of that command) doesn't seem to work with RedCine on my PC. What is the Undo command for RedCine on a PC?

This may be a question only vaguely related to the preceding discussion, I realize. But I wasn't gonna start a whole new thread just to ask this! ;-)

[Gunleik Groven]

No - the workflow you want is slow. There are many very good and very fast workflows being used by post facilities all over the world.

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

Lucas... With all due respect.... Eliminate Scratch from that equation, have a look at this post and tell me... :)

Scratch is probably great, and when I get my cam, a demo-run of Scratch and visiting a Scratch facility with some footage is the next step, but, that doesn't make your statement valid.

Currently the workflow is not here, and that is very much due to RedCine/RedAlert/CommandLines disability to communicate in a rational way with other applications.

As a first step ( :)! ) that's all we ask.

But I may be wrong and would love to be proven wrong.
Please do so.

Gunleik