>> I will not be upgrading to Windows 8 due to the UI being basically a tablet OS

Touch has been available for many years.

The new START-MENU is a full screen. Showing lots of stuff, if ya want it to. Works fine with a mouse and keyboard. Been doing so for about 6 months.

And, although some of the start-menu-screen is stupid, some of it is useful.

Better audio performance? Good. Won't have to buy a faster computer this year.

SX2 on w8 in about 3 weeks.  Meanwhile: learning, and configuring w8, and playing with SX1.

What more can an old man want?  Other than,.....

j

Latency was listed as one area of improvement in X2 in the initial lists by Cake.  Is it true, or isn't it?  If so, how so?  And if not really, why list it?  (Just b.s. advertising?)  The vagueness about this is really bugging me.

@jm24 - Well Windows 8 could be great, but my experience (I have worked for years in the IT sector - especially huge networks and mainframes) tells me to wait until the first service pack is out. There are always "hidden" problems with new systems, that become manifest when using systems for a longer time. So - if you are using an OS like Windows 8 in a mission critical environment I advise to wait until the first service pack is tested. If you are using W8 as personal system I guess you can experiment.

I have heard mixing experiences with W8 until now. Some audio and/or video drivers do not seem to play nice (yet). Also some test seem to suggest W8 itself takes some more processor power (and memory) than W7 in same conditions. That would give some slight problems with more heavy projects. I cannot confirm this at this moment, because I do not have run test myself (hey - there are only seven days in a week ;-)). I think it is best to wait until there is more certainty about this subjects.

@Saxon1066 - What I understood (from the video) is that the engine runs smoother although not gapless (witch is good enough for me). Also a lot of plugins are optimized to have lower latency, so you can make adjustments without those little hiccups that proved to be a little problem with the more "heavy" plugins in the past.

Saxon1066


Latency was listed as one area of improvement in X2 in the initial lists by Cake.  Is it true, or isn't it?  If so, how so?  And if not really, why list it?  (Just b.s. advertising?)  The vagueness about this is really bugging me.

You are not alone here.  I found the vagueness in this area a bit strange as well and the needle on my b.s. meter definitely began to jump around a little.  Such a vague and generalized description could mean just about anything.  

During the live webinar I directly asked: "What exactly does improved low latency audio engine mean?" and "Is there gapless audio?"  Neither question was answered with any real detail, if at all.  

It does come across as a bit of an advertising ploy.   Almost as if to say: "We know many people want gapless audio, but we still haven't figured it out (or flat out can't do it) so we'll throw something vague and noncommittal in there to try and lure those people on board."  

wXP had 3 service packs
wV had 2
w7 had 1

w8 had more than a year of preview releases.

I think the major issues we will have to wait to be fixed are from 3rd parties.

And the service pack for w7 was mostly a roll-up of previous releases.

=================

Fur shur, I will not recommend it to my clients until we know their important programs have been updated.

But some clients do want to upgrade their wXP, wV, and w7 computers. And some will buy new computers with w8 installed.

=============
Meanwhile I am installing, and upgrading, on some of the office computers, new and old, and learning.

The music comp is triple boot OS.  It is the newest hardware. And is more specific and tweaked than the other computers. So, it provides lots of bits of what is working and not. (Korg nano drivers do not work. Is this the drivers, or conflict with other hardware, or w8?)

Don't be afraid.   For $40 bucs it is an easy choice to purchase, add a partition, and start learning.

In general, blind, non-reversable, upgrading of ANYTHING is to be avoided. Imaging is your friend.

This is not how it works with Cubase or Reaper. The exact same one track + stack of effects (in a serial circuit) is balanced across the cores

This is a thought-provoking statement. Can anyone explain how a single data stream might be split across multiple cores? I certainly can't. 

bitflipper

This is not how it works with Cubase or Reaper. The exact same one track + stack of effects (in a serial circuit) is balanced across the cores

This is a thought-provoking statement. Can anyone explain how a single data stream might be split across multiple cores? I certainly can't. 

Im trying to wrap my head around that too.  What is it that plug-in #2 could process in advance, and in lieu of not having, the output of plug-in #1?  That's a brain-teaser, but maybe there's some other explanation to the statement.  I can't imagine what though...

I totally agree, it's hard to understand how it does it (if it does).

But it must. Here is the best evidence I have for this theory (see attached Reaper screenshot).
The processing load in this project is 99% serial mastering chain (everything else is frozen). And as you can see, all 4 (8 virtualized) cores are jamming hard, all about equally. When the project stops, all cores drop to zero. So, it's Reaper that is using them all and it's using them all on one big serial chain of VSTs.

My only doubt to my theory is that the Reaper meters show 24.89% cpu utilization. That's 99.89% of one core. So did it pack all that processing under one core (just)? Then why do we see the task manager hitting all cores so hard? It really does appear to be dividing the work up among them. What I really need to do is add a few more effects (for testing) to push it over 25% (one core of a 4 core system) and see if the project plays as smoothly. :)  If so, it's definitely dividing up the workload. 

UPDATE: To test my theory, I just inserted a stack of Waves API-2500 compressors into the serial chain and got the utilization up to 31% (6% more than a single physical core would be able to crunch) and it plays without a hiccup. (It took 25 compressor instances to do it! These Ivy Bridge processors are no joke.) So, I think it's definitely splitting the workload. To be sure, I should keep adding more fx until I get to some ridiculous amount / margin of error.

I should add that Cubase with this same project (identically recreated) does not perform as well as Reaper. I'm pretty sure it's not fitting all this serial "mastering chain" processing into one core (I don't know that for certain, though). But, the project plays in Cubase, as well. Again, this same recreation in Sonar does not play ("yet," again, I'm working with tech support to suss it out). Hopefully, we'll have success.

Here's the full image link: http://jalcide.com/downlo...perMultiCoreAction.png

bitflipper

This is not how it works with Cubase or Reaper. The exact same one track + stack of effects (in a serial circuit) is balanced across the cores

This is a thought-provoking statement. Can anyone explain how a single data stream might be split across multiple cores? I certainly can't. 

I found an interesting article that touches on it. It sounds like it's probably trading latency for core utilization. "Anticipatory" being that it somehow does some kind of "out of order" pre-rendering, or something. Conceptually, I don't get it. It sounds like witchcraft, but it appears to work.

Update/edit: Oh, wait. I think I get it! Maybe it does small, end-to-end (serial, on a single core) chunks within a higher latency buffer and then "assembles" those rendered chunks into the final stream. A half a second here, a half a second there (out of order). Each "job" gets a small slice of time from a "pool" of what was rendered upstream. In this way, you could "weight" the most "contiguous" rendering toward the start of the signal path, the more segmented parts toward the end of the path. This approach would give you more core balancing toward the end of the path and more raw crunching performance toward the beginning (as it's working with larger chucks). If i'm right, first of all, I'm effing brilliant for figuring that out (hahaha), but more importantly, what a genius algorithm/approach.

http://www.soundonsound.c...es/pcmusician_0108.htm


"Reaper's Justin Frankel told me that he routinely does a lot of his development on a dual quad-core Xeon PC, so it's hardly surprising that the default Reaper settings work well with up to eight-core machines, typically offering over 95 percent utilisation of all eight cores. Reaper mostly uses 'Anticipatory FX processing' that runs at irregular intervals, often out of order, and slightly ahead of time. Apparently, there are very few times when the cores need to synchronise with each other, and using this scheme he can let them all crank away using nearly all of the available CPU power. Exceptions include record input monitoring, and apparently when running UAD1 DSP cards, which both prefer a more classic 'Synchronous FX multi-processing' scheme."

With pre-buffering the algorithm to load the cores more evenly is straightforward. Basically you can pump multiple small buffers through each plugin, queue them, and then process them through the next plugin in the chain and so on. At each stage these buffers can be scheduled on different threads(cores).

Of course since you are pre buffering this can't be done at low latency since you now have N-buffers worth of latency added up. This is probably ok for your use case where you are mastering. SONAR's scheduler was optimized for realtime low latency performance so doesn't have this buffering mode.