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

[kelldammit]

Yes many software and especially DAW software will run multiple threads per core. This is a complex subject, but the only point is that DAW's are not constrained in the way you implied.

it just depends on how the daw handles them. for instance, dp and studio one seem to take a round robin approach: channel 1 goes to core/thread 1, channel 2 to core/thread 2, and so on. enabling multi-core use in a particular plugin never seemed to make any difference that i could tell. so by virtue of what is on what channel (and thus thread/core), you can bury one core, and get the usual dropouts, etc. despite the others not getting too much use.
cubase does similar, but i think ignores threads, and only uses physical cores. multi-core options in virtual instruments does seem to work, as well. it also seems to work in VEP.

i may have misread or misinterpreted, but isn't there a problem with logic's cpu allocation currently?

also, if memory serves, didn't logic v8 achieve its cpu efficiency with vi's by a clever buffering scheme? if a track wasn't record-enabled, it essentially ran at high buffers. once record-enabled, it'd run at the chosen buffer size for low latency. from what i understand, cubase now works similarly.
i'm not sure how DP's current pre-gen scheme actually works, but it didn't seem to make a huge difference for me either way, and i generally end up running everything real-time anyway (for note scrubbing/preview and better stability).
in any case, 4x is an impressive claim. i'm really dying to see this in action (especially if you can do note preview/scrubbing with it enabled)!
i'd also really love it if the cap were removed on latency compensation, but i suppose that's a drawback of having to wrap plugins into MAS?
anyway, really exciting news, for sure.

[machinesworking]

The low latency and the new pre rendering feature are totally separate..you are conflating them.

You can't be certain if they are or not. MOTU are acting like they are separate, but that could easily be marketing. That, is where we're not seeing eye to eye, you keep on stating your opinions as facts.

You don't know how easy or hard it is to code something like this new pre-rendering feature that MOTU are implementing, that's all my original point was. When you say:

Frankly I don't know why everyone hasn't been doing it this way all along.

It sounds like an accusation, a rhetorical question. My only reason for replying was to say maybe we don't know how hard it can be to do this, and you've since been trying to pick apart my guess's as to why it might be harder than you think it is.

The ad hominum stuff, not interested in your opinion on me at all. I don't know you personally, it's just words on a forum.

[Dewdman42]

MOTU has listed two separate features...

1. They claim to have cut latency in half. The exact wording is:

   DP’s host buffer latency has been cut in half, resulting in industry-leading overall latency performance.

   This does not say they have reduced overhead, etc...... they say they have "cut the host buffer latency" in half. In other words, if a buffer of 64 previously had 5ms latency, now it will have 2.5ms latency. The consequences on the CPU are not indicated in this enhancement.
2. They have created a next gen pre gen system, which is completely new and has nothing to do with the latency enhancement. This new system will essentially cache the rendering of instrument plugins so that when you playback, much less CPU will be required. This is totally and completely separate from the above latency improvement. Yes it will reduce CPU overhead while playing, which may make it possible for people to lower their buffer setting below what they had been using previously due to generally more efficient CPU use during playback... However, that new smaller buffer setting will be half the latency compared to before due to point #1!

So both enhancements are going to improve performance, but one is not causing the other...they are totally separate.

As far as why hasn't everyone been doing it this way before (referring to Next Gen Pre Gen), that is definitely still my point. This should have been done a long time ago. Its cacheing. I'm actually kind of surprised to find out that only now is someone finally doing it! Major Kudos to MOTU for doing it! Hopefully Apple will consider doing something similar in the future. If DP9.02 really can handle 4x as many instruments as LogicX now, due to this improvement, Apple will need to implement something similar soon.

I'm not sure what Ad Hominem you are referring to?

[aMUSEd]

As far as why hasn't everyone been doing it this way before (referring to Next Gen Pre Gen), that is definitely still my point. This should have been done a long time ago. Its cacheing. I'm actually kind of surprised to find out that only now is someone finally doing it! Major Kudos to MOTU for doing it!

It's what Reaper has been doing since it was first developed, one of the main reasons for its efficiency. Of course it sounds like MOTU may possibly have improved on the idea further (or at least on their original implementation of it in the last DP version), but they are not the first to develop and implement the concept.

[Dewdman42]

Yes many software and especially DAW software will run multiple threads per core. This is a complex subject, but the only point is that DAW's are not constrained in the way you implied.

it just depends on how the daw handles them. for instance, dp and studio one seem to take a round robin approach: channel 1 goes to core/thread 1, channel 2 to core/thread 2, and so on. enabling multi-core use in a particular plugin never seemed to make any difference that i could tell. so by virtue of what is on what channel (and thus thread/core), you can bury one core, and get the usual dropouts, etc. despite the others not getting too much use.
cubase does similar, but i think ignores threads, and only uses physical cores. multi-core options in virtual instruments does seem to work, as well. it also seems to work in VEP.

Remember that what the software does under the covers to process plugin data is not actually in real time. That's what the buffer is for. The DAW goes through the plugins as it sees fit, computes the next buffer full of output data and then when the sound card asks for the next buffer full of data, hopefully the DAW has already completed the job of filling it up. If the DAW was unable to complete the work of filling up the buffer with all the computation of the various plugins, then you get an audio dropout. Otherwise the buffer goes to the sound card and the DAW continues working on the next buffer full of data, using whatever strategy it sees fit.

This can be done with or without multiple threads. Multi-threaded programming is a complex topic, as is the use of multi-cores. There are pros and cons. If the DAW knows how to use the N multiple cores, it can process N algorithms in parallel of independent data in parallel and speed things up a bit...whenever possible. its not always possible.

Perhaps a plugin is using multi cores in some way...this may or may not even be a good idea. If the DAW is highly optimized to make use of all the cores to process all the data that needs to be processed, then a seemingly smart plugin could actually just create contention and get in the way of the DAW from doing what it needs to do. On the other hand, if a DAW is not that smart about it, and if a plugin believes it can process some algorithms in parallel, then it very well might be useful. So it just depends.

We can assume for the sake of this discussion, that both Apple and Motu are already pretty smart guys and generally have already been using smart and sound multi-threaded practices to optimize their applications...and when possible using multiple cores to the greatest extent possible to push data through the CPU as fast as is possible while crunching the numbers to fill a buffer.

i may have misread or misinterpreted, but isn't there a problem with logic's cpu allocation currently?

I have no idea about Logic's current cpu allocation... But as I have tried to indicate, DP's new feature is not really related to multi-core or multi-threaded processing. It is related to caching. it is going to reduce dramatically how much the CPU even needs to work at all during playback by caching ahead of time as much of that as possible, so that during playback, practically all that is happening is shoveling data from one buffer to another one.

also, if memory serves, didn't logic v8 achieve its cpu efficiency with vi's by a clever buffering scheme? if a track wasn't record-enabled, it essentially ran at high buffers. once record-enabled, it'd run at the chosen buffer size for low latency. from what i understand, cubase now works similarly.

I'm not sure if Logic does what you describe, but that is not the same as DP's new feature. That is simply an automatic way to switch back and forth between a short latency for recording (at the expense of high CPU use) and longer latency during plackback when it doesn't matter as much (and less chance of a dropout).

i'm not sure how DP's current pre-gen scheme actually works, but it didn't seem to make a huge difference for me either way, and i generally end up running everything real-time anyway (for note scrubbing/preview and better stability).
in any case, 4x is an impressive claim. i'm really dying to see this in action (especially if you can do note preview/scrubbing with it enabled)!

I don't see any reason why it wouldn't be able to scrub with the pre-gen'd data. Where things are going to be interesting to see will be how easily and seamlessly it can adapt to moving stuff around on the piano roll while its playing back. Stuff like that. They claim its seamless, but we'll see.

[Dewdman42]

As far as why hasn't everyone been doing it this way before (referring to Next Gen Pre Gen), that is definitely still my point. This should have been done a long time ago. Its cacheing. I'm actually kind of surprised to find out that only now is someone finally doing it! Major Kudos to MOTU for doing it!

It's what Reaper has been doing since it was first developed, one of the main reasons for its efficiency. Of course it sounds like MOTU may possibly have improved on the idea further (or at least on their original implementation of it in the last DP version), but they are not the first to develop and implement the concept.

Justin is a smart guy and that doesn't surprise me if its true. Would be interesting to do some performance comparisons between the two after DP9.02 comes out.

[Dewdman42]

(accidental dupe)

[Dewdman42]

It's what Reaper has been doing since it was first developed, one of the main reasons for its efficiency. Of course it sounds like MOTU may possibly have improved on the idea further (or at least on their original implementation of it in the last DP version), but they are not the first to develop and implement the concept.

aMUSEd, do you know where I can find some information about what exactly Reaper is doing? (without spending hours searching through their forum for some tidbits of information)??

[machinesworking]

MOTU has listed two separate features...

[*]They claim to have cut latency in half. The exact wording is:

Why do I have to say again that I doubt this to be two separate features? Is it hard to understand that MOTU may be stretching the truth a bit with this claim? Apple used to claim that Altivec made their computers faster, when in reality Altivec only had limited uses where it could beat out intel chips, and was completely skunked when Centrino chips came out. There are many precedents where the software industry has made claims that didn't really pan out. Again, MOTU are probably stretching the truth a bit here. It's going to take specific tests without PreGen on to find out whether they are, so we can go back and forth about it more if you want, but it won't do any good. I do agree with you though they they are flatly claiming lower latency.
http://cdn-data.motu.com/marketing/motu ... 016-pr.pdf

[*]They have created a next gen pre gen system, which is completely new and has nothing to do with the latency enhancement. This new system will essentially cache the rendering of instrument plugins so that when you playback, much less CPU will be required. This is totally and completely separate from the above latency improvement. Yes it will reduce CPU overhead while playing, which may make it possible for people to lower their buffer setting below what they had been using previously due to generally more efficient CPU use during playback... However, that new smaller buffer setting will be half the latency compared to before due to point #1![/list]

So both enhancements are going to improve performance, but one is not causing the other...they are totally separate.

As far as why hasn't everyone been doing it this way before (referring to Next Gen Pre Gen), that is definitely still my point. This should have been done a long time ago. Its cacheing. I'm actually kind of surprised to find out that only now is someone finally doing it! Major Kudos to MOTU for doing it! Hopefully Apple will consider doing something similar in the future. If DP9.02 really can handle 4x as many instruments as LogicX now, due to this improvement, Apple will need to implement something similar soon.

I'm not sure what Ad Hominem you are referring to?

Again, the bold, how exactly are you aware of the technical method they are using to prerender the tracks that aren't record enabled? Where is this cache coming from? You're basing your whole argument on this preconception it seems? There's zero mention of caches or exactly what method MOTU are using in their official press release, so I'm genuinely interested in how you came to that conclusion. You're coming to a lot of conclusions based on this assumption on how they're achieving this and how easy it is.

They do flatly claim lower latency, and like I mentioned above I'll definitely be testing that.

[Dewdman42]

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.

[aMUSEd]

It's been an option in preferences since as long as I can remember and I've had Reaper since V1 - Anticipative FX processing, which the manual states "has benefits for both multiprocessor and single processor systems. On single processors it makes REAPER more tolerant of lower interface latencies (and more resistant to plug-ins that do larger block-based processing, such as ReaVerb and ReaFir). On multiprocessor/multicore systems it also allows for very significant multiprocessor usage'. You can set the 'render ahead' buffer manually (and like anything in Reaper if this doesn't work for your system you can turn it off). Not sure what threads cover this on their forum but it is definitely using pre rendering, doubtless not 100% identically to DP since MOTU don't have access to the Reaper source code, but it sounds like a similar process - from Reaper's perspective they could probably call their version 5th gen since they have been working on it for a long time now.

[Dewdman42]

Thanks for that data point, I will research it. I'm genuinely interested and it does not at all surprise me that Justin did it right to begin with. it does surprise me that it took the rest of the industry all the way until now to catch on to it..

[Dewdman42]

It's been an option in preferences since as long as I can remember and I've had Reaper since V1 - Anticipative FX processing, which the manual states "has benefits for both multiprocessor and single processor systems. On single processors it makes REAPER more tolerant of lower interface latencies (and more resistant to plug-ins that do larger block-based processing, such as ReaVerb and ReaFir). On multiprocessor/multicore systems it also allows for very significant multiprocessor usage'. You can set the 'render ahead' buffer manually (and like anything in Reaper if this doesn't work for your system you can turn it off). Not sure what threads cover this on their forum but it is definitely using pre rendering, doubtless not 100% identically to DP since MOTU don't have access to the Reaper source code, but it sounds like a similar process - from Reaper's perspective they could probably call their version 5th gen since they have been working on it for a long time now.

So I researched this a little bit. This is by no means a comprehensive assessment, but I do think there are significant differences between Reaper's Anticipative FX processing and MOTU's new Next Gen Pre Gen, though Reaper's is also very good. Its not clear to me that other DAW's aren't already doing what Reaper does there, which also seems like a no brainer that every DAW ought to have. That doesn't mean they do.

Basically, what Reaper does is as its playing, it reads ahead, similar to a look ahead compressor plugin;whenever it has a chance, to pre-compute ahead of time the output from FX plugins. What this does is make it so that the CPU load can be spread over time a bit more. It smooths out the CPU usage over time.

What it does not do is cache a pre-rendered version, as the MOTU update will do. Also, Note that Reaper's feature is related to FX and MOTU's is specifically related to Instruments. In other words, Reaper's is looking ahead at the audio stream as much as it can and trying to crunch on the CPU as much as it can ahead of time, at moments when the CPU has some spare cycles to do it. DP on the other hand will look at midi data ahead of time and pre-render in the background the output from instruments. Besides the obvious fact that one is handling FX and the other is handling instruments, one major difference is that in the Reaper version, every time you hit play, the track has to be re-rendered again...albiet in an anticipatory way whenever possible. DP will render the instrument output, more like automatic track freezing, and once that happens for a given instrument track, it will not need to crunch that data again when hitting the play button over and over again...unless the midi data changes or some parameter in the instrument changes....

So I see these as very different features. Reaper is look ahead audio processing, something some compressor plugins have been doing for quite a while also. DP is rendering and caching. Very different. Both useful.

one comment I saw on Reaper's forum about their's:

One bad thing about anticipative fx processing is that all the graphical displays of you plugins like vu meters and stuff are also ahead of time. At the mixing stage this was a problem for me in one situation or the other.

I don't know if they found a way to fix that or not, but that would certainly be an annoyance. Apparantly it has a lot of problems with some sophisticated plugins that use multi-cores....hardware influenced stuff like UAD, etc.. But one interesting question this brings up about MOTU's new feature will be what will we see when we are playing back a pre rendered instrument, will its own GUI be updated while playback, just as if it were receiving the midi? I would guess not. The instrument plugin GUI will appear as if nothing is happening, unless its record enabled and actually being processed by the CPU.

[aMUSEd]

Reaper calls all plugins fx so I'm not sure it does mean literally not instruments. I'm sure there are differences, as I said MOTU don't have access to Reaper source code, and I'm sure they have their own geniuses too, so it can't possibly be identical. I took the 'render ahead' to mean a short term cache though, that is what a buffer is essentially (think 'working memory').

[Dewdman42]

The biggest difference, as I said, is not related to FX vs instrument, its related to the fact that Reaper is not permanently cacheing it. its just looking ahead and using spare cycles on the CPU ahead of time across cores whenever it can. Totally different process. Not even close to the same thing, regardless of the source code used.

Think of Reaper as look ahead processing

Think of DP as background automatic track freezing