Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

RED ONE build 32

It seems like the priority of the old RED ONE owners is close to zero, since it takes so long to implement the last changes to the beta and make the release build.
It is not a good sign for future releases either.
 
Beta 32 was released on August 14... half a year ago. Even if priority is, naturally, on the Epic/Scarlet... just a little tweaks on this already tested and proven Beta would easily give us a Release Build 32... please guys!
Guido
 
Hi Guido
That is what I mean. It seems to be a little tweak, meant to be released by the end of november, and now we are close to March.
Not even a word about the delay of an estimated release date made by RED in the first place = zero priority
If they don´t mean it...in my book....don´t bring it up.
 
Guys, for what it's worth, even release builds have bugs occasionally. Any release, whether Beta or Release needs to be thoroughly tested by each camera owner to make sure it's working as expected on your camera. Red can't recommend beta releases on paid gigs because it makes the liability go up. In general, release builds are more stable but in this case for example Build 32.2 is stable besides a couple of known issues.

Red One has been EOL'd so developement of new firmware is going to be slower and eventually come to an end. That's just the way it is. But we're not there yet. Still at least one release build to go. Hopefully Red can deliver on it soon. i understand the frustration with the 48gb SSDs.
 
RED ONE firmware dev is not EOL. I can say that we are indeed working on the next version to include 48GB REDMAG optimization on RED ONE. We actually have engineering resources dedicated to this task....
 
Brent@RED said:
RED ONE firmware dev is not EOL. I can say that we are indeed working on the next version to include 48GB REDMAG optimization on RED ONE. We actually have engineering resources dedicated to this task....
Click to expand...

Brent, do you think there is any chance they could open up 2k Redcode42@25fps to "Slow Media" generally while they are in that part of the code base.

It's only 7MB/S rather than 5 and I can't imagine theres many compact flash cards out there that can't manage 7 and certainly not any modern ones!

Should be an easy update that would be helpful!

Freya
 
Brent@RED said:
RED ONE firmware dev is not EOL. I can say that we are indeed working on the next version to include 48GB REDMAG optimization on RED ONE. We actually have engineering resources dedicated to this task....
Click to expand...

That is nothing short of amazing!

I don´t have the 48GB cards, but I am very happy to see you are still working on the Red One, I kept mine, I love it, and it will be used for another decade I am sure!
 
Freya, I can pass along request to firmware dev team - but I am not the most technical guy with media, so I really cannot even guess what is possible there. Just being honest....

Eirik, we feel the same way about RED ONE :)

BC
 
Brent@RED said:
Freya, I can pass along request to firmware dev team - but I am not the most technical guy with media, so I really cannot even guess what is possible there. Just being honest....
Click to expand...

That's okay, I'm preety certain it's totally do-able (only 7 MB/s) and should be easy code wise, but obviously theres all the other stuff that comes into play. It would be FANTASTIC if you could pass it on to the dev team tho! :) Would be a small tweak with positive effects!

Thanks Brent! :hurray:

Eirik, we feel the same way about RED ONE :)

BC
Click to expand...

The Red One is good for red as it is more people using the Red workflow etc. :)

Freya
 
Steve I know what you mean. But this is also about communication. If you as a company tell the customers that something will
happen within a certain period and then you don´t hear anything 3 month after that period, then communication are really bad
and I loose faith in the companys policy to me as a RED ONE owner. Thats why I think the priority is zero.
All RED could do is to tell us what we can expect if there are changes to the release date. I guess the few bugs we are talking about are easy to solve and
then make the release build even for a develop team in that 3 month period.
 
Steen Linde said:
Steve I know what you mean. But this is also about communication. If you as a company tell the customers that something will
happen within a certain period and then you don´t hear anything 3 month after that period, then communication are really bad
and I loose faith in the companys policy to me as a RED ONE owner. Thats why I think the priority is zero.
All RED could do is to tell us what we can expect if there are changes to the release date. I guess the few bugs we are talking about are easy to solve and
then make the release build even for a develop team in that 3 month period.
Click to expand...
Fair enough. I 100% agree that communication is key. Even if it means bad news. I think Red does a good job of this overall. Ocassionally something falls through the cracks.

What I would recommend is that if a release build is not imminent, that Red removes the 48GB compatibility for R1 until that status changes. That would eliminate confusion for anyone looking to purchase those SSDs now.

Otherwise, the current build is useable.
 
Steve Sherrick said:
Fair enough. I 100% agree that communication is key. Even if it means bad news. I think Red does a good job of this overall. Ocassionally something falls through the cracks.

What I would recommend is that if a release build is not imminent, that Red removes the 48GB compatibility for R1 until that status changes. That would eliminate confusion for anyone looking to purchase those SSDs now.
Click to expand...

Think you have a point on that!

Otherwise, the current build is useable.
Click to expand...

Yes everybody I've seen talk about it, have only mentioned the same minor quirk that can be worked around.
I'd rather RED took their time and got it right.
The only reason they might want to rush it is because of the 48gb ssd thing.
There might even be an argument for a second beta there, but then that means someone producing a build and everything that comes with it.

Freya
 
Build 32 Beta fixes possible .r3d file corruption, for when activating Record, if the Magnify option was active simultaneously. For me at least.
 
hey I know build 32 supports red color and gamma 2/3 in camera but i was trying to export a look just to test it but rcx says it's gotta be in reg color /gamma 1 to work. Not really a big issue as i can just save it as red color/gamma 1 and then switch it in camera, but i just thought I mention it.
 
I have been waiting patiently for the official build 32 firmware, but I'm to the point now that I might as well just update to the damn Beta if its stable enough.

Has anyone had any issues with the beta build in a professional setting? That's the only thing holding me back. Is there ever going to be an official build 32 firmware update for us Red One MX guys? Thanks :)
 
no problems to report seams good, it is great to have Redcolor 3 and Red gama 3 when shooting with Epics
 
I think the bug with the camera switching back to RC2 view from RC3 view when toggling RAW and going back to RC view is still existent ? The problem should be covered in this thread a little bit earlier... I'm still sitting on the latest release build because of this (no beta builds allowed over here since we had problems with beta builds too often [even if it only were smaller ones with existing workarounds])... So I'd highly appreciate a 32 release build (when the whole Dragon stress is over)... can't confirm this tho - I'm not using the beta build as mentioned.
 
Damn, I really need the option that causes it to bug out... :-/

Guess I will hold off for now.
 
I can't confirm it as mentioned - but I never heard of it being fixed in the meantime ;)
The beta should be a really stable and useable release otherwise - and if you're exposing with the histogram the RC2/RC2 difference doesn't matter anymore - it's only metadata anyways actually; if you have a DIT with RCX on set to check back on important takes I don't see any problems with this "bug" (it's really only a metadata difference - can be easily fixed upon de-bayering). For me it's more the fact that I'm not _allowed_ to use beta-builds as for company policies.
 
You must log in or register to reply here.
Back
Top