HEAT in Native P Tools. Is this possible?

[sunburst79]

Originally Posted by WernerF

Just say'in, is this an artificial restriction or is it possible to include this function in a Native P Tools software version? Of course this question comes up now as a result of the fact that Avid has included faster than realtime bounce as a feature in P Tools HD 11 and that this feature is implemented in the Native realm. If this feature was made available to potential HD Native system buyers I submit that the sales numbers would skew towards the high side. Correct me if I'm wrong.

Werner as one of the lucky few that's eligible to upgrade my CPTK to HD Software for only 999.00 and trying to balance that verses some type of hardware exchange upgrade to HDN I must say that having HEAT would certainly sway my opinion. I never bought into the explanation that HEAT could only be implemented in DSP. Although its possible that it might not have been worthwhile to do it as RTAS.

Another reason to add it is from the session interchange and recall stand point. Its important to be able to recall sessions and transfer them between systems. I can understand wanting to keep it a HD only feature to draw people to the HD platform. I think implementing this on HDN would be attractive.

[nigelpry]

As someone intrigued by Heat,but hasn't the hardware to see it in action, can someone tell me ....

Can you place heat on a track that you are recording on so you are monitoring that live input through Heat, or can you only have it active on playback tracks?

I'm wondering whether the 'it needs a DSP chip' and 'it works with offline bounce therefore must be able to run native' paradox can be explained by some issue about hearing it in real time in native mode. Maybe it needs a DSP chip in order to process the audio in real time, but can run native when performing non-real time processes, such as offline bounce.

If that's the case though, I can't begin to understand how it would perform in offline bounce. Maybe the offline bounce actually get horrendously slow if Heat is instantiated?

I can't remember precisely what was said in the webinar, would have switched off a little if they said anything specific about Heat (because it was 2am and counting in the UK at the time of the webinar and I don't have Heat).

[bredo]

In one of the videos I have seen, they explained that HEAT switched to a native version when doing an offline bounce (and back when finished).
That means that a native version exist, somewhere

[JFreak]

Originally Posted by nigelpry

Can you place heat on a track that you are recording on so you are monitoring that live input through Heat, or can you only have it active on playback tracks?

Yes.

Originally Posted by nigelpry

Maybe the offline bounce actually get horrendously slow if Heat is instantiated?

No.

[nigelpry]

Succinct as always, JFreak

[JFreak]

Originally Posted by nigelpry

Succinct as always, JFreak

Kimi Raikkonen has learnt this from me

[WernerF]

Originally Posted by bredo

In one of the videos I have seen, they explained that HEAT switched to a native version when doing an offline bounce (and back when finished).
That means that a native version exist, somewhere

That makes total sense. Confused as well

[Emcha_audio]

Originally Posted by zedhed

If that's the case and I'm not doubting you, then it looks like it's more of a sweetener for HD/X rather than anything else....no?

My understanding is that it's actually part of the HD/HDX engine not a plug in and not run on the chips themselves. It's an algorithm that is in the HD/HDX engine.

Originally Posted by bredo

In one of the videos I have seen, they explained that HEAT switched to a native version when doing an offline bounce (and back when finished).
That means that a native version exist, somewhere

If you listen carefully (i've taken a listen back yesterday for this and something else specifically)

They say that it switches to a native-"like" version within the HD/HDX engine. So it's still part of the HD/HDX engine and not a plugin. My understanding at least. It would sure be fun to have it natively no doubt.

[WernerF]

If it can be written into the HD/HDX architecture it would stand to reason that it can written into the Native architecture. That would, once again, make this a marketing choice. If that is the case I would submit that it is not a smart marketing choice.

[Emcha_audio]

Originally Posted by WernerF

If it can be written into the HD/HDX architecture it would stand to reason that it can written into the Native architecture. That would, once again, make this a marketing choice. If that is the case I would submit that it is not a smart marketing choice.

I will say a maybe to the native architecture. I'm not a programmer

As to a marketing choice.. I suspect it's both a technical and marketing choice. But in the end if all that HDX/HDN offers more than Vanilla is higher I/O and track count, Avid might as well stop being a Hardware company don't you think?

As such they have to give something more enticing for people to buy their hardware. With HDN it's the ability to use their converters I/O box and higher I/O than vanilla. With HDX it's the abilities we all know now and those we might not know still {tadaduuuum scary music} . Realistically though think of it with this car analogy. If between a Mercedes benz and a lada, you had the exact same quality, options, power etc etc etc. Why would you want or buy the car that sells for 10 time more? There would be no desirability and it would ultimately hurt the car company, so imagine a hardware company. If we speak strictly numbers (yeah I know..) the software cost 699$ (non HD) A HDX system cost at minimum 9999$ (no trade in and with an omni). The HDX+omni option brings in potentially 14x more revenue with just one sale compared to the software, excluding the retailers cut. So all in all Avid has to give an incentive to sell more of these.


Oh and please! don't start saying I consider pt vanilla a lada... it's just for imagery