DP9 set to get an update, claiming 4X CPU performance...

[aMUSEd]

Are you sure DP is permanently caching it? I can't see any point in doing that. The cache is there to reduce CPU load in realtime performance so it just needs a temp cache or buffer and something that can be updated on the fly as one makes edits. I can't see how it's a totally different process anyway, even if it is permanent, it's (possible) a refinement of an existing concept, not a completely new one.

[aMUSEd]

OK so Justin is describing here how it works - it is definitely pre rendering to a temp cache:

If you have the "fx render-ahead" mode on, REAPER will render each track (if it is not record monitoring or dependent on a track that is) up to 200ms ahead as well. This data is stored in a track cache.

https://www.gearslutz.com/board/q-justi ... eaper.html

You can also increase the 200ms in options.

[Dewdman42]

yes the whole point of DP's update is to Pre-Gen the track, just like freezing, but automatically and behind the scenes.

I mean think about it, it has always bothered me...every time you hit play on a DAW...it crunches all these numbers and produces buffers full of data that get mixed together by the DAW and ultimately sent to the sound card. Then you stop, rewind and hit play again and it re-crunches all the same DSP algorithms on the same input data all over again. Its a lot of wasted CPU work.

Why not save a lot of that crunched data the first time you do it, so that when you hit play again it doesn't even have to bother the CPU again for a lot of it? You only need to crunch the lionshare of those DSP algorithms once, unless the input midi or audio is changed in some way, then you have to re-crunch it again obviously. This is what Motu is allegedly accomplishing. They claim 10x as many instrument tracks on DP9.02 vs DP9.01, and 4x more then Logic; but to me it just seems like that's how it always should have been. They gave an example of a machine with 150 instrument instances and low CPU use.

Why re-crunch the same audio or midi data through the same DSP over and over and over again if the inputs haven't changed? See what I mean? This is why track freezing was invented to begin with, MOTU's new feature just makes it a lot more automatic and convenient. You get the track freezing without having to sit around waiting for tracks to freeze or being bothered to manually do it, then unfreeze to work on it, etc.

Reaper's, which is also useful I'm not criticizing it, is just something completely different. Its not freezing anything, its just looking ahead so that if the CPU has some free cycles on the various cores to pre crunch some audio data, its trying to force the data into the plugin earlier ahead of time and use the free cycles on the cores to do it. Its really an entirely different feature, though it would not surprise me if Reaper's look ahead is also an area the other DAW's could learn from.

By the way, a 200ms cache is not the same as a frozen track. That still will require all the DSP to be re-crunched every time you hit play. That 200ms number just says how far ahead it will be willing to attempt to look and pre-crunch each time.

[aMUSEd]

It's not clear yet if what DP has is anything more than a pre render buffer either, I think you are trying to make it something 'completely different' when it isn't even clear yet what the difference actually is. All it says in their pdf is 'Digital Performer's Next-generation Pre-gen™ engine transparently pre-renders audio output from virtual instruments
and plug-ins to dramatically reduce their CPU load.' That is pretty much what Reaper is doing, it says nothing about rendering whole tracks permanently which sounds an inefficient way of doing it anyway (since this is essentially about tracks you are working on in real time, hence the difference from freeze and why both are useful for different things). I suggest waiting to see how this works out when people have a chance to try it.

[Dewdman42]

heheh ok. This is how they have described it in various press releases. Its pretty clear to me, but it will be out soon so you can confirm it yourself and we can all wait to find out if it performs as well as they claim.

Check out this press release that was posted on KVR during NAMM, which is a bit different then the PDF on MOTU's site:

http://www.kvraudio.com/news/motu-annou ... -dp9-32453

Some excerpts:

Digital Performer's Next-generation Pre-gen engine transparently pre-renders audio output from virtual instruments and plug-ins to dramatically reduce their CPU load. Disk tracks and instrument tracks automatically transition to real-time operation on an individual basis when necessary, when recording for example, to make the entire user experience seamless and transparent.

(I do notice its not limited to instruments, they say all plugins, so that's cool).

In one bench test, Digital Performer was able to run ten times the number of virtual instruments with the enhanced Pre-Gen mode engaged, compared to real-time operation.

Bench tests also show that Digital Performer can run up to four times as many virtual instruments as another popular DAW

(they were referring to Logic as I understand it)

During the NAMM show presentation, Digital Performer ran over 150 instrument instantiations from the CPU-intensive, Kontakt -based Cinesamples orchestral library on a Mac Pro cylinder. With DP's audio engine buffer set to an ultra-low 64 samples (which produces virtually imperceptible latency for virtual instruments), DP's CPU meter hovered at an efficient 20-30%.

The only way you're going to get 150 instruments at 64 sample buffer size and 20% cpu is with frozen tracks. And by the way, their new 64 sample buffer performance has the same latency as what used to be 32 samples.

[Dewdman42]

I'm also very curious how they were able to cut the latency for any given buffer size in half. I mean, latency is a direct result of the buffer size. For all these years, typical latencies for various buffer sizes have been pretty darn consistent, even between different DAW's. Some of them may be able to handle smaller buffers better then others without drop outs, etc, but at the end of the day, the latency is a directly calculable value in ms based on the buffer size, very predictably and pretty darn consistently across the industry.

Somehow they have eliminated a very dramatic inefficiency in the audio card buffering mechanism to cut the latency in half for any given buffer size. Its not clear to me whether this creates more CPU overhead to accomplish in some way. I would think yes, but we shall see.

[machinesworking]

machinesworking, read MOTU's press releases, its all spelled out. that is what they are doing. As to your suggestion that MOTU may be stretching the truth or lying in some way...no comment.

I posted the PDF above in the post you responded to, in no uncertain terms they mention nothing about cacheing, zero zip, nada. They relate it to track freezing, which is not cacheing, and does require background processing.

Dewdman42 you keep saying pre-rendered (frozen) tracks are cached, which is a term used for things not usually written to disc, whereas frozen tracks are. This is really some serious splitting hairs type stuff, since none of us are actually in on exactly how MOTU is prerendering in an unreleased implementation. Just chasing press releases.

You start in on how it's not really for FX, did they specifically tell you that? I would assume any track based effect would also be pre-rendered, I would also assume not for busses..

To throw you a bone, if you're calling tracks in RAM cached I suppose it's possible that's how they're doing it, but I kinda doubt it considering the RAM overhead that would entail. Most likely they're writing tracks to disc as Virtual RAM and unloading processor cycles when the record isn't enabled and you aren't messing with the audio or MIDI in the track.

all I know is June is a long way away!

[Dewdman42]

ok whatever..you are quite disgruntled about my comments I can see that...sorry if the word "cacheing" confused you. I wrote a lot of stuff, should have been pretty clear from the context. The word cacheing can be taken a lot of different ways I see no reason to assume that can only refer to RAM use, I think perhaps you are splitting hairs because you are disgruntled that I pointed out your lack of understanding on the new enhancements.

Be that as it may...

Bottom line, DP is doing something new...automatic track freezing..I don't know of anyone else doing it yet. Bottom line, they have cut the latency per buffer-size in half. Bottom line, those two features are separate and different features. Bottom line, DP's new enhancements have almost nothing to do with core utilization and have everything to do with eliminating needless CPU crunching altogether. Bottom line, they are claiming 10x improvement in plugin count, which is massive. Bottom line, you can host more instances of Diva on DP9.02.

[machinesworking]

ok whatever..you are quite disgruntled about my comments I can see that...sorry if the word "cacheing" confused you. I wrote a lot of stuff, should have been pretty clear from the context. The word cacheing can be taken a lot of different ways I see no reason to assume that can only refer to RAM use, I think perhaps you are splitting hairs because you are disgruntled that I pointed out your lack of understanding on the new enhancements.

Be that as it may...

Bottom line, DP is doing something new...automatic track freezing..I don't know of anyone else doing it yet. Bottom line, they have cut the latency per buffer-size in half. Bottom line, those two features are separate and different features. Bottom line, DP's new enhancements have almost nothing to do with core utilization and have everything to do with eliminating needless CPU crunching altogether. Bottom line, they are claiming 10x improvement in plugin count, which is massive. Bottom line, you can host more instances of Diva on DP9.02.

I can't be disgruntled at someone who claims to know how MOTU are implementing their new pre-rendering, thinks I don't know what I'm talking about, but calls track freezing cacheing. I'm sorry if you take offense to me stating the obvious, but this is all conjecture, and you're making this claim of understanding what amounts to a few paragraphs of a press release that in no way goes into the details of how MOTU are coding these new features.

Again, my point is we do not know how it's going to play out, and we most certainly do not know how they are implementing it. That, is why I find it odd that you're astounded that DAW developers haven't done it sooner. It's entirely possible that it hasn't been possible before faster processors etc. you really have no way of knowing the details of how this is working or the coding involved. It's fun to go into conjecture, but when you think you know the "new enhancements" well enough to tell people they don't understand them, then make claims about how it's implemented , well, it's hard to be disgruntled at someone that confident in their own conjecture, it's more like amused.

[Dewdman42]

Yes I find it odd that nobody has thought of this before. To me it seems obvious. Sorry if this offends you. Should have been done a long time ago. Really glad to hear MOTU is doing it now and I hope that other DAW's will follow suite in the not too distant future.

[machinesworking]

Yes I find it odd that nobody has thought of this before. To me it seems obvious. Sorry if this offends you. Should have been done a long time ago. Really glad to hear MOTU is doing it now and I hope that other DAW's will follow suite in the not too distant future.

Not at all offended, we're just having a communication breakdown, but at least we're both thick skinned and relatively polite.

I just know I'm not a coder, I can do some basic stuff, and I have a pretty good idea of how computers work after talking with people who really know what they'e doing for the last 20+ years, but mainly that makes me cautious when jumping to conclusions about why X developer of Y product hasn't implemented Z feature.

It's quite possible that DAW developers thought about this years ago, but never got anything coded that was anywhere near stable, maybe some genius came in with some new ideas on how to implement it that got around some serious crashing etc? All that is very likely, considering that CPU has always been and always probably will be a concern for us end DAW users. Freeze tracks is the obvious halfway point isn't it? It's kinda half a feature, almost good but not quite.

Anyway I'm glad a DAW I use all the time is looking to be first to implement this.

[Dewdman42]

Fwiw I was a software developer for 20 years and do have a pretty good idea about how things work. Writing code that avoids cpu crunching as much as possible has been done since the earliest days of computing whenever possible. The kind of optimization that motu is doing is actually going to make it possible to run more tracks on older machines by avoiding redundant DSP calculations. They should have done this a long time ago. More likely it involves complicated engineering to accomplish.

How can you call it a "half" feature? This is a MAJOR feature and I believe other DAWS will soon be crawling all over each other trying to copy it. Or maybe you were referring to the old track freezing as half a feature? Hehe well that was a major feature too when it came out but definitely only halfway to here with this new update!

The thing I am really curious about is how the heck they have cut latency in half for any given buffer size. That is actually kind of amazing and a lot of people have been trying to optimize that particular thing for a long time, so what the heck has everyone been overlooking all this time?

[machinesworking]

How can you call it a "half" feature? This is a MAJOR feature and I believe other DAWS will soon be crawling all over each other trying to copy it. Or maybe you were referring to the old track freezing as half a feature? Hehe well that was a major feature too when it came out but definitely only halfway to here with this new update!

See? communication breakdown. Freeze tracks is a halfway feature. I don't see how anyone would think that frozen tracks that you have to unfreeze to work on, that take time out to initially freeze is a better feature than the PreGen that MOTU have announced? That MOTU have made all that with PreGen supposedly seamless and invisible to the end user, they get the advantages of freezing tracks without the disadvantages, that we have to do absolutely nothing to get the same and even better, that's where the genius lies. I'm curious as to how it all reacts, say when you start messing with MIDI on a track that doesn't have record enabled? They're basically instantly replacing a static track with it's instruments and FX as soon as you engage that plug in in any way, audible mode on in the MIDI window etc.
And yeah if it's bug free and works as well as they showed at NAMM every DAW developer will be scrambling to copy. Thing is, I would guess there's got to be some serious hiccups implementing this, since I don't think any developer could look at the regular freeze track feature and think, "yes this is what musicians want, to not be able to do anything with their tracks".

The thing I am really curious about is how the heck they have cut latency in half for any given buffer size. That is actually kind of amazing and a lot of people have been trying to optimize that particular thing for a long time, so what the heck has everyone been overlooking all this time?

I'm hoping they amaze you with this. My earlier point was that with the PreGen on it's going to be impossible to notice a lower buffer, if PreGen frees up CPU from any track without record enabled on it, then it's going to register as a lower buffer than you would normally have in DP9.01 right now. The only way to test this is to turn off PreGen and compare results to previous versions of DP.
They are flatly saying though that round trip latency in general is cut in half, and yeah that's cool as heck! In the opposite way, Cubase for years had problems in OSX with it's code killing efficiency at lower buffer settings making them one of the most CPU hungry DAWs out there at any playable buffer setting. They within the last couple years solved that problem and are competitive again, well at least until MOTU releases NextGen PreGen!

[Dewdman42]

Agreed, it will make the old freeze tracks method seem positively laborious. I know some people that hate freezing tracks so they bought a $5000 Mac just to avoid it. Heh

I agree about it will be interesting to see how it performs while editing midi on the piano roll while playing back. But even that could be made fairly seamless. If you move a note before the play head gets to that spot then it can seamlessly switch to real time rendering on the remainder of that track, and keeping the results for the next play through, but we shall see.

Regarding the latency, I have to correct you again. Lowering the cpu use doesn't automatically lower latency. It just frees up some cpu time and the latency remains fixed to whatever buffer size is currently configured.

Now with less cpu crunching there is a possibility to manually lower the buffer setting to a number lower then you have used in the past and get some lower latency. For example if enough cpu is freed up if you were running at 256 samples before you might be able to drop to 128 and cut your latency in half from previously.

Ok great but what motu is saying as the other new feature is that the latency of 128 samples is now the same as was previously the latency for 64 samples, which is about 3.5ms one way. They did a test at 32 samples with 1.6ms latency! If you were previously using 256 with around 16ms one way latency and it drops to 128 samples with the new buffer performance at 4ms one way latency, that is 4x reduction and I absolutely think you will notice!

So basically, yes the lower cpu utilization will make it possible for people to lower their buffer settings if they desire, but the new feature, which is separate from the pregen feature is that for any given buffer size they have cut the latency in half. End result will be that if you don't want to lower your buffer size your latency will be half what it was before and much less fan noise. If the freed up cpu inspires you to lower your buffer setting then you could have 4x or more reduction of latency

[ObsoleteAcc99]

[DELETED]