Question about MSP7.0 internals....

[Kris1]

Probably the beta testers will be able to assist here, if they feel like it and if their NDA allows them to do so.

I was wondering what kind of mechanism is used with Instant Play, and the effect of enlarging the system's memory on the overal power of the RT capabilities of MSP. I've noticed, as stated in the manual, selecting a high-performance instantplay profile results in a delay of a couple of seconds before playback starts and which it will try to keep filled as the playback advances. I therefor presume MSP may use some kind of internal playback buffer which it will fill prior to playback, a bit like the RT idea behind so many Canopus products.

If so, what kind of influence can be expected by enlarging memory and to what extend ?

Thanks in Advance for any answers given,
Kris

[Brian Ellis]

Kris

You read it as I do. I think that up to 512 Mb will hold true. IOW, if you have less, there may be more problems. OTOH, having more probably will have little or no influence. CPU speed is also important, possibly more so.

I conclude that it is the combination of 2 GHz and 512 Mb as minimum requirements that will allow you to have 5 deep RT: reduce either and you will lose some RT functionality. Increase either, you will have little improvement for 5 deep RT, although you may be able to go deeper.

However, I may not be right; I'm going only on what I've observed with a 1.6 GHz system with 512 Mb.

Another point not yet considered is the FBS. My system is 400 MHz: if I were to increase it to 533 MHz, would not the 512 Mb operate better?

[Kris1]

... yes, since your 1.6 would start to run at 2.1 then. Providing you've got a Northwood 1.6A and a fairly decent motherboard, you should be able to get away with it.

Seriously, no idea if it would pose a _noticable and measurable_ difference, stricktly speaking FSB and real world preformance keeping everything else identical. From the experiences I had with Canopus (2.4 Gig using 400 FSB Vs. 533 FSB type), no impact nor difference was to be observed.

[Dr Mordrid]

A lot of work went into MSPro7, which is why the interface wasn't changed much this time.

MSPro7 does use an internal buffer, but that isn't what really pulls it off. I can set up long & deep effect stacks that would overflow a buffer and it still plays in realtime.

Basically the core was recoded to multithread and several other internal changes made to speed things up including a realtime DV encoder, though this latter feature works better with an SSE2 capable CPU. Also new are support for HT and dualies.

It may look like MSPro6/6.5 but it's a whole other bird....

Dr. Mordrid

[Hulk]

Doc,

Your comment about a RT DV encoder brings a question to mind, is the RT preview of lesser quality than a normal preview? If so, how noticable is it?

-Mark

[Dr Mordrid]

RT quality losses reflect as frame drops with a too slow CPU for a given stack depth. The image quality is the same.

Dr. Mordrid

[Kris1]

Thanks for the insight, Doc.

Something struck me though just now. I've toyed with RT-out on a G550 now for 2 days, and I'll be tossing the G550 out in exchange for a ATI for test purposes tomorrow. Suddenly I realized I did not test, nor see the possibility of RECORDING A RT-DV OUT STREAM. Oh yes, I can have RT-DV preview out using instant play, but does that setting also influence RT-DV out at the recording stage to a DV device ? (I'll know it by tomorrow myself, but my next stop will be my bed, and not the keyboard).

[Dr Mordrid]

To do RT out to IEEE-1394 requires more CPU horsepower, and as noted a P4 is better clock-for-clock because it has SSE2...which the RT engine supports. IMO for RT IEEE-1394 I'd go with an AthlonXP 2400 or 2600 or a dualie 1800+ or better.

This will eventually change with the Athlon 64's as they will have SSE2 as well, but for now....

Dr. Mordrid

[Kris1]

I'm currently running an overclocked P4 at 3.2 Gig. (No HT) As my sig says on the Pinnacle forum "my next one will probably be a K8", but I hope to be able to do most of the things I want with my current rig till the second generation of K8 boards arrives.

[Hulk]

Doc,

Please clear this up for me, I though MS Pro (at least up to version 6.5) used a MS DV codec. Is this something new in version 7, in that MS is using thier own DV codec? I guess that would account for part of the speed up in rendering? How is the quality compared to the MS DV codec?

Kris1,

Please let us know how the TV out RT preview works with an ATI card compared to the g550. I'm very interested...

-Mark

[Kris1]

WilCo. Tomorrow, same place. (*can't bl***y get to sleep, bursting headache and nothing helps*)

[Dr Mordrid]

For disk rendering it uses MSDV, but for realtime to IEEE-1394 its my understanding that an SSE2 capable portion of the realtime engine handles that.

Dr. Mordrid

[Hulk]

Interesting. If I understand what you are saying that means that a project rendered to a dv camera from the time-line would be rendered using the Ulead DV codec.

But, a project already rendered to one file and then exported to a dv camera would have been rendered using the MS DV codec?

Not a big deal, you just made me curious why they would use the MS DV codec at all, unless it has higher quality.

-Mark

[JackHu]

I know users will have concerns towards UI, because it hasn't been modified since version 5 (not sure about this, but that is the info I got) which means the UI has been around for 6 years.

There are pros and cons on this topic. The advantage would be the learning curve is small. The disadvantage would be users would like to have a fresh feeling of things.

This matter would be in my internal discussion soon.

Jack

[wkulecz]

IF it ain't broke, don't fix it!

Steal a few features from Vegas Video and add them to your existing UI -- like being able to grap the "thumb" of the timeline scrollbar and by adjusting its width scale the timeline zoom (scale factor), add an efficient keyboard shortcut for cut at current timeline position.

In most all your dialog box controls the sliders minimal movement interval appears to be some fixed percentage of full clip length, this makes it way too "twitchy" on longer clips, so add a modifier key or two for precise adjustments so the minimal mouse movement move 1-frame and perhaps another for 1 second.

Please don't adopt the XP-FisherPrice look that wastes too many pixels on eye candy. Buttons and controls should be large enough to be effective as click targets but not so large as to waste screen pixels that'd be put to better use displaying video and bigger adjustment previews.

Improved UI functionality I'm in favor of. Cosmetic changes to look like everyone else does, I'm not.

--wally.