UI Rant...

[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