scratchcine controlled like a VTR

[Mat@imageWork]

Hi Lucas,

Just to know, could we control scratchcine like a VTR or telecine with RS422 (sony protocol)? Could be nice for us as we need it to import directly into many other system (smoke and flame) without having to put it on tape. If not how is it possible to dump 2K (let's say on HD-D5 with 2K board) on tape? Crash rec???

Thanks Mathieu

 

[Adam Glick]

There have been many requests for this sort of functionality but to my knowledge no products currently exist.

 

[Lucas Wilson]

Hi Lucas,

Just to know, could we control scratchcine like a VTR or telecine with RS422 (sony protocol)? Could be nice for us as we need it to import directly into many other system (smoke and flame) without having to put it on tape. If not how is it possible to dump 2K (let's say on HD-D5 with 2K board) on tape? Crash rec???

Thanks Mathieu

Hey Mathieu,

No remote capability right now. Crash-rec is the only way to go directly from systemA to systemB... unless your Smoke and/or Flame can be controlled like VTRs.

Also - no need to go to a D5 w/2K. The NVidia SDI cards can output 2048x1080 4:4:4 directly from SCRATCH.

Lucas

 

[M Korek]

This was a great feature in good old DPS reality.

If you can "slave" the Scratch "currently open construct/timeline" say from a Symphony machine for an HD or SD delivery project, while recording in the same time the scratch timeline timecode it could result in efficient and very quick offline/online process,

I am far from being an expert, but I think that making the external control available through RS_422 just as a trigger for an open timeline is something that might be easily implemented

Just an idea

 

[Mat@imageWork]

Hi Luki,

Do you think it would be implement in the future? Been abble to act like a VTR make scratchcine much much more attrative to me, and "useless" without in our workflow...I mean tools are great, but a "crash rec workflow" for tape base...Tricky when you think that rendering in DPX is 10:1 in 2K, and realtime in VTR emulation workflow.

Many thanks Luki, nothing personal here, I just want to understand why such a simple tool is not there yet...

BTW smoke and Flame have a VTR emulation.

 

[Lucas Wilson]

...I just want to understand why such a simple tool is not there yet...

BTW smoke and Flame have a VTR emulation.

Because it's not simple!

Implementing very basic 422 is easy. Implementing 422 correctly is hard. Dealing properly with sync reporting, duplex communication, error reporting, ballistics, etc. is non-trivial. The presentation is simple - implementation is not.

And if Smoke and Flame have VTR emulation, then this particular problem is solved! : )

Lucas

 

[Mat@imageWork]

Because it's not simple!

Implementing very basic 422 is easy. Implementing 422 correctly is hard. Dealing properly with sync reporting, duplex communication, error reporting, ballistics, etc. is non-trivial. The presentation is simple - implementation is not.

And if Smoke and Flame have VTR emulation, then this particular problem is solved! : )

Lucas

How???

The worklow I expected (maybe others?) is to primary grade or apply LUT or none of this on red footage inside scratch cine, give head and tail to footage then connect to smoke (or other packages) via HSDL to conform project, apply design, comp etc...

Then you can say scratch is a telecine or VTR for red footage. Otherwise it's a "only" a review system. With all respect Lucas, nothing personnal.

Mathieu

 

[M Most]

The worklow I expected (maybe others?) is to primary grade or apply LUT or none of this on red footage inside scratch cine, give head and tail to footage then connect to smoke (or other packages) via HSDL to conform project, apply design, comp etc...

Then you can say scratch is a telecine or VTR for red footage. Otherwise it's a "only" a review system. With all respect Lucas, nothing personnal.

When was the last time you controlled a telecine from a Smoke? And what telecine was it?

Telecines are originators of material. They are usually used as the master in terms of recording paths, with the recorder being the controlled slave device. I don't see where Scratch is any different. It acts as the master and directly controls the recorder. That's how it's designed. If you're talking about scanners - which sometimes can be directly controlled - that's a bit different in that they're not real time devices. But as a real time device, the Scratchcine approach is intended to feed single or dual link output to other real time recording devices, be they VTR's, or disk based recorders with VTR emulation, such as RaveHD or Clipster. It's not designed as a VTR emulator itself, only as a controller.

 

[Evangelos Achillopoulos]

Mike what they asking is very legitimate...

Scratch cine is NOT telecine...

People wants a VTR for R3D...

It is a stupid little feature, that makes everyones life much easier...

Luki just go and buy licenses for a VTR SDK from Drastic Technologies Ltd they are very good guys... Ask for James...

http://www.drastictech.com/sdk.html#MediaCmdEmulationSDK

I have used in the past very successfully...

I hope they (Assimilate) will use it and stop the excuses... it seems that they can write software of a certain kind and not anything else...

Thats odd for cutting edge software developers... No offense Luki but you sound more like a marketeer than an engineer...

 

[Lucas Wilson]

Mike what they asking is very legitimate... Scratch cine is NOT telecine... People wants a VTR for R3D...

It is a stupid little feature, that makes everyones life much easier...

Luki just go and buy licenses for a VTR SDK from Drastic Technologies Ltd they are very good guys... Ask for James...

http://www.drastictech.com/sdk.html#MediaCmdEmulationSDK

I have used in the past very successfully...

I hope they (Assimilate) will use it and stop the excuses... it seems that they can write software of a certain kind and not anything else...

Thats odd for cutting edge software developers... No offense Luki but you sound more like a marketeer than an engineer...

Evangelos,

I know James and the Drastic guys and they make a really cool product. Their SDK is based on ActiveX, which SCRATCH does not use at all. So it is far from an easy task for us to implement. And then there are the licensing and business discussions, etc.

You underestimate the amount of work it takes to do this and to do it well. Of course we have received 422 emulation as a feature request. And we have looked at it very carefully.

Implementing 422 emulation correctly is actually a difficult task. There are a ton of corner cases that have to be taken into account, and it's just hard. Ask the Drastic guys - they'll tell you! : ) It doesn't mean it's impossible and that we'll never do it. But we have to budget our time and resources just like any other company.

Since you are not a SCRATCH customer, it would be difficult for you to know what sorts of things our users are beating us up for, and what is important for them. Remote emulation is a request we get a lot, but is pretty far from the top of the list.

Best,

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

 

[Evangelos Achillopoulos]

Luki, I won't get in to the specific way that you can simply (within couple of hours) create a handle (even from within the ancient Pascal!!!) to use an Active-X external library in Windows...

I just want to say that yes I know how difficult is, to make a VTR emulator... that's why I bought it last time that I needed it... its just 500$ per seat...your app. is selling 17K$... Your clients doesn't deserve it?

Yes, I will never be a client of Scratch neither Loustre for my reasons, but what your clients are asking is just a transport to your timeline... you don't have to be a user of Scratch to understand this! how complicate is it?

I thing your software developers are having to much fun in the Bahamas lately... its time to work for couple of days...

When I read the announcement of Scratch Cine I thought that it will be a VTR emulator for R3D's... I was wrong...

Luki you sound very arrogant, you have to respect your clients, you can't fool them... With this kind of thinking, you will end up one of these new golden boys that will lose the ground under their feet very soon...

 

[M Most]

Luki, I won't get in to the specific way that you can simply (within couple of hours) create a handle (even from within the ancient Pascal!!!) to use an Active-X external library in Windows...

I just want to say that yes I know how difficult is, to make a VTR emulator... that's why I bought it last time that I needed it... its just 500$ per seat...your app. is selling 17K$... Your clients doesn't deserve it?

Yes, I will never be a client of Scratch neither Loustre for my reasons, but what your clients are asking is just a transport to your timeline... you don't have to be a user of Scratch to understand this! how complicate is it?
..............
Luki you sound very arrogant.......

Reread what you just wrote and what you seem to be (ironically) accusing Lucas of.

Scratch was an existing product with a rather significant (for its market) user base before Red even came into existence. Their product has a feature set that is well known and not misrepresented. If it does not include a feature you personally think it should have (even as a non-user of it), and thus does not suit your needs, then don't buy it. But I would refrain from telling others how to run their company, particularly when they don't tell you how to run yours. You have no idea how their code base is designed, how their play functions operate, and what it would or would not take to incorporate what's being discussed here - and neither do I.

 

[Evangelos Achillopoulos]

Mike, I thing we ware talking about a software called ScratchCine that was introduced for RED in the first place and it was marketed as the solution for fast turnaround of RED footage, if I'm not mistaken...

So where in the picture is involved Scratch (the full package)?

They announced a product specific for RED, but they didn't want to work for it at all, so they just cut features and changed the name and thats it... dinner is served!

Clients when they giving us their money, we (manufacturers/engineers) have to honor them!

If this is not the case, then ScratchCine is an opportunistic product...

And as such, clients they should avoid to throw their money to it.

To say what am saying Luki/Assimilate give me the trigger in the first place, by creating false expectations to RED users... Is the way of thinking behind their decision, I don't like at all, to me it sounds totally opportunistic. Its the same behavior that is still keeping REDCine in a BETA state (which is the longest Beta period in the industry) and makes so many users angry... For me this is bad business, that keeps down RED cameras for way to much time...

And as for the accusation of not having a Scratch Cine or a RED camera... every day I'm supporting at least 3-4 RED users to print their movies to film, I'm solving their problems, I'm facing their problems, so I have all the right to say what I'm saying, since crippled apps like REDcine are busting my balls in a daily basis...

So please don't put in my mouth things that I didn't tell, the thread is about Scratch Cine, not Scratch.-

 

[Mat@imageWork]

When was the last time you controlled a telecine from a Smoke? And what telecine was it?

Telecines are originators of material. They are usually used as the master in terms of recording paths, with the recorder being the controlled slave device. I don't see where Scratch is any different. It acts as the master and directly controls the recorder. That's how it's designed. If you're talking about scanners - which sometimes can be directly controlled - that's a bit different in that they're not real time devices. But as a real time device, the Scratchcine approach is intended to feed single or dual link output to other real time recording devices, be they VTR's, or disk based recorders with VTR emulation, such as RaveHD or Clipster. It's not designed as a VTR emulator itself, only as a controller.

Mike, really?

When you plug a cintel DSX to a quantel iQ, to conform before online and finish the project, you need to control the telecine throw an RS422 protocole. Same for DaVinci with a spirit, same for every VTR. Same with smoke. Smoke can be pluged to a spirit in the same way.

"Think of SCRATCH-CINE as a RED Deck, or a Virtual Telecine."

"Now... if you think of this as a RED Deck and compare... try to get even something simple like a Digibeta for 30K. How about D5, or HDCAM-SR? : )"

These come from the thread http://reduser.net/forum/showthread.php?t=11351, posted by Lucas.

If you want to use ScratchCine to be used as a VTR as said bellow, you need a RS422 protocol to control scratchcine before ingest material into anythink else. Ohterwise it's a crash rec worklow...ScratCine would be perfect for us if it can act as virtual telecine with RS422. And I haven't said anythink else in this thread since the beginning.

As always, I have nothing against assimilate nor Lucas. I just push to see this tools in the futur. ScratchCine can play realtime 2K full rez material in realtime. Throw HSDL, it make a realtime telecine for scratch to rely to a well known workflow with RS422. Render DPX is way slower....

Mathieu

 

[M Most]

Mike, I thing we ware talking about a software called ScratchCine that was introduced for RED in the first place and it was marketed as the solution for fast turnaround of RED footage, if I'm not mistaken...

And that's exactly what it provides for a number of users, some of whom are even on this board. Just because you don't happen to like the design doesn't mean that everyone else has a problem with it. They don't.

They announced a product specific for RED, but they didn't want to work for it at all, so they just cut features and changed the name and thats it... dinner is served!......
If this is not the case, then ScratchCine is an opportunistic product...

So is the Red One. Gee, just imagine - coming out with a product for which there is already some built in demand! What an evil business concept!
The purpose of a business is to be profitable. That's it. It's not to make the world a happier place, or provide free stuff for those that can't or don't want to pay for it. If doing those things enhances profitability, that's very nice. But the basic premise of a business is to find a need and fill it. That's what Red did. That's what Assimilate did. That's what you do. Why is one "opportunistic" (and I assume from your tone that you attach a negative connotation to that) and the others not?

To say what am saying Luki/Assimilate give me the trigger in the first place, by creating false expectations to RED users...

Read the specifications of the product. Nowhere in those specs does it state that the product will do what you happen to think it should do in exactly the way you happen to think it should do it. I don't see any "false expectations," all I see is something that does what the company says it does.

Its the same behavior that is still keeping REDCine in a BETA state (which is the longest Beta period in the industry) and makes so many users angry...

Everything in the world of Red is essentially in a state of perpetual beta. The software, the firmware, the camera itself. Even the things Red designates as "release" are replaced within weeks (or less) on a continual basis. This, to some, is Red's greatest strength. To others, it's Red's greatest weakness. Take your pick.

And as for the accusation of not having a Scratch Cine or a RED camera... every day I'm supporting at least 3-4 RED users to print their movies to film, I'm solving their problems, I'm facing their problems, so I have all the right to say what I'm saying......
So please don't put in my mouth things that I didn't tell....

Nobody "needs" Scratch or ScratchCine. There are at least 10 different ways to process, cut, finish, and deliver Red footage. All of them work, with different degrees of difficulty, different sets of issues, and different time frame requirements. You select your methods based on equipment choices, budgetary restrictions, turnaround requirements, client expectations, and personal choice. If you don't like any one way, there are a whole lot of other ways. And everyone has a right to say whatever they want. You have that choice. So do I.

 

[Lucas Wilson]

"Think of SCRATCH-CINE as a RED Deck, or a Virtual Telecine."

"Now... if you think of this as a RED Deck and compare... try to get even something simple like a Digibeta for 30K. How about D5, or HDCAM-SR? : )"

These come from the thread http://reduser.net/forum/showthread.php?t=11351, posted by Lucas.

Hi Mathieu,

I was just trying to draw an analogy that would make some sense to people unfamiliar with the product. That's the best I could do at the time.

If you (or anybody) is interested enough in SCRATCH or SCRATCH-CINE to contact us, get a demo, etc., or even just ask the question, we would certainly never try and convince you that it does something it does not do! : )

Best,

Lucas

 

[M Most]

When you plug a cintel DSX to a quantel iQ, to conform before online and finish the project, you need to control the telecine throw an RS422 protocole. Same for DaVinci with a spirit, same for every VTR. Same with smoke. Smoke can be pluged to a spirit in the same way.

Really? Are you actually doing that (because I've never heard of anyone else doing it)? The only data based color correction system that I know of that can control a Spirit is Baselight (OK, Resolve as well, but I don't know that they're actually delivering that yet). Since a telecine is normally operated with a color correction device attached to it, why would one want to control it with a Smoke (rather than the other way around)?

I wouldn't compare this to a DaVinci situation. A DaVinci is a real time color corrector that is designed to work in a specific workflow situation in which the material passing through it is being recorded to some type of recorder that is controlled by the TLC. The only situations I've seen where a telecine is controlled as a "source deck" have been in data recording where a Spirit is being used as a data scanner, and controlled by software specifically written for the purpose. In most cases, since the telecine is being run by a colorist, the colorist will have control over the recording device, regardless of whether the recording device is a disk recorder, a nonlinear editor, or a VTR. I just don't see a need to go the other way, but that's not to say that others would necessarily agree.

 

[Mat@imageWork]

Mike and Evengelos,

I'm a little bit confusing by the way this thread get into...I have some expectation regarding scratch cine, and ask question. Assimilate can run their business as they want. We can just "feel" here the need to an RED VTR with RS422 protocol with a product that can play back 2K at full rez log data in realtime and output it throw HSDL with remote control. This worklow would skip the need to process DPX frames. It also permit to get back into a more common worflow where any other package can be used.

These specific tools doesn't need to have conform capability. Just understand what an EDL list is, in fact a pull list, and playback.

Thanks to all of you.

 

[Lucas Wilson]

They announced a product specific for RED, but they didn't want to work for it at all, so they just cut features and changed the name and thats it... dinner is served!

Hi Evangelos,

I guess that's one way to look at it. Another way would be...

We listened to the demands of hundreds of users, including a large section of Reduser, that wanted SCRATCH capability at a lower price. Then, we looked at what would really serve the needs of the market we were interested in. After hundreds of hours of research, talking to users, talking to camera owners, talking to RED, we developed a product that seemed to be something a lot of people wanted.

Turns out, we were right. SCRATCH-CINE has been a successful product, and the people who have bought it are very happy with it, and very happy with its capabilities.

Its the same behavior that is still keeping REDCine in a BETA state (which is the longest Beta period in the industry)

You clearly were not a part of the beta for XSI v1. : ) Or Gmail, which is still in beta 3 years after its launch!

Evangelos, you are not a SCRATCH or SCRATCH-CINE customer, so how can you really know what it does and does not do? If you are interested in testing it and finding out for yourself what SCRATCH can or cannot do for you and your business, then that can be arranged. : ) At ASSIMILATE, we try very hard to listen to our customers and respond to their needs.

Best,

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

 

[Mat@imageWork]

Really? Are you actually doing that (because I've never heard of anyone else doing it)? The only data based color correction system that I know of that can control a Spirit is Baselight (OK, Resolve as well, but I don't know that they're actually delivering that yet). Since a telecine is normally operated with a color correction device attached to it, why would one want to control it with a Smoke (rather than the other way around)?

I wouldn't compare this to a DaVinci situation. A DaVinci is a real time color corrector that is designed to work in a specific workflow situation in which the material passing through it is being recorded to some type of recorder that is controlled by the TLC. The only situations I've seen where a telecine is controlled as a "source deck" have been in data recording where a Spirit is being used as a data scanner, and controlled by software specifically written for the purpose. In most cases, since the telecine is being run by a colorist, the colorist will have control over the recording device, regardless of whether the recording device is a disk recorder, a nonlinear editor, or a VTR. I just don't see a need to go the other way, but that's not to say that others would necessarily agree.

There is many package can control a telecine as VTR. DaVinci 2K and 2K plus can do it and need to do it. Resolve, Baslight, Matrix (with Cintel), Quantel (iQ and Pablo) and Lustre. The advantages are really good too when output 2k log data from TELECINE throw HSDL:

1: faster than scanner
2: No need for colorist intervention. Since 2K log data into DPX is a calibrate SMPTE format, you can swing the reel into telececine, and ingest material.
3: Conform permit in context grading, much better.

When you work in a classic Spirit to DaVinci worklow, you are using both telecine and Color grading system and colorist, it is not cost efficient.

When taking the HSDL 2K log untouched from telecine, you are using telecine in almost continuity, without the need of a colorist. One ride of telecine, you can conform, apply 3DLUT of print stock and start grading in context without the need of telecine anymore...It is cost efficient. One telecine could serve many other package. Like with RED TELECINE when avaible

Mathieu