CPU spikes

[mhschmieder]

To be clear, I was suggesting turning down the PART output, not the MSI output. They aren't the same thing.

Based on my own experience, given similar trigger levels, the MSI instruments are not "normalised" with respect to each other.

This is perfectly fine, as it isn't a "General MIDI" library.

I suspect that the levels were set to what allowed for the fullest range of expression with each instrument.

So as users of the library, we simply have to be prepared to adjust the PART output levels now and then while tracking.

These are all assumptions on my part based on what I have experienced. Some people who use MSI a lot more heavily than I do may find my comments very naive and have a more enlightened response.

[David Stephen Baker]

I understand and completely agree with what you are saying about balancing via. part output and completely agree that the parts are not balanced due to the detail of recording multiple timbres. But the "spikes" I am refering to are of the CPU and have nothing to do with gain settings or distortion.

A friend from a list server told me the following as it relates to MAC:

"Floating point mathematics can represent a finite set of rational
numbers in normalized form by using a biased exponent that is encoded
with an implied 1.0. Any numbers which are smaller than this minimum
value use a "trick" to extend that range, to have an implied 0.0
exponent. Certain CPU's cannot process these "denormal" values
without help. I would assume that MOTU's algorithm does not prevent
denormalized floating point values from occurring, and those "random"
spikes are due to a kernel trap being called to handle every
subsequent calculation on these values, rather than being processed
in the CPU. Recursive algorithms can be affected quite easily, such
as reverbs, delays, etc. Once the values become sufficiently small
(and basically inaudible), they can/will decay into denormals if
allowed. The default behavior is to "turn off" denormal handling and
squash those values to 0.0; this is done globally in AltiVec by
simply setting one bit (enabling "Non-Java Mode") in its status
register. Properly written code will eliminate them and/or prevent
their occurrence. File a bug report with MOTU."

All said and done, MOTU needs to fix the program so all CPU's can cruch the numbers equally AND I have not lost my mind.

-Dave

[hugy]

Hi David,

Use a fast reverb when composing.
You can set a convolution reverb if you increase the latency. Try 1024.

Altiverb add some latency that's one of the reason it's stree CPU less.
Try bouncing if you don't trust me.

I think the point of other comments was to say that altiverb is a dedicated
reverb plugin so they have taken more time to develop a better algorithm.

It's like saying that MSI sounds are not as good as vienna ones.
You can't compare things which are not comparable.
And yes it's matter of price.

More time to develop a more effcient algorithm, so products cost more.
Same things applies to sounds.

Less times, less expensive.

sorry to say that, but all is a matter of "Bang for Bucks"
imho MSI really worse it compare to its price.

Hope you get my point.

[David Stephen Baker]

Hugy,

I completely agree with your post and believe I get your point The cost of software is paying for better math. Agreed. My comparisons perhaps have not been fair to MOTU.

I am getting an "adapt or die" attitude from this list which is not going to get MOTU to repair our investment. I know $300 is chump change in computer-world, but some of us have been running on the Ramen-Diet budget wise and expect the most from every red cent we spend.

All of this has made me very irritable and I appologize if I have gone beyond beating a dead horse and have begun saddeling it. I feel strongly that we make a living using this stuff and should expect our tools to work as advertised.

In specific response to your comments: I have not noticed a latency in Altiverb that comes anywhere near what MSI requires to barely function regardless of bounce. Altiverb has obviously build a better algorithm which makes it cost more and sound better but the processing portion of the algorithm (from everything I have been able to gather) uses near identical math without random CPU spikes.

Good comparison on the Vienna series. Vienna uses better musicians in a better environments on better instruments with more options. Dig. But Vienna does what it advertises.

I think we need to make cost go up with sound quality, not the reliability of function. If I were to trade in $1800 Genelec near field monitors for a pair of $150 headphones, I would still expect them to work as advertised.

Convolution reverb sucking up 80 to 90 percent of a 1.5GIG processor and randomly spiking the CPU is indicitave of a problem with the software programming, not the operator. I have been conversing with several MAC audio software deveolpers and they all agree; even those that build $150 plug in's.

Respectfuly,
-Dave

[mhschmieder]

All I can say is that in my experience the gain settings DO affect whether I get Audio Overload or not, which I may have misinterpreted as being a result of CPU spikes. I stopped using the performance metering as watching the problem made the problem worse . I have an EXTREMELY underpowered G4 iMac so probably see problems that most people do not see. But this is good in a way because it forces me to develop specific discipline in how to use each module in the recording chain, which also helps with G5 duals .

[hugy]

Hi Guys,

Just for information.

I can use the convolution reverb on a powerbook 1Ghz with 1Gb of RAM.
You just need to increase latency settings.
512 or 1024 should be ok.

Of course it's hard to play in realtime in that case but playback is ok.

Sure it could be better but at least you could use it on a light configuration.

Regards,

[mhschmieder]

I meant to add that some of the improved workstyle hints that I have picked up over the past two months have increased my headroom a bit, and I was successful for the first time in applying the convolution reverb to the lower-resolution Yamaha bright piano sample, as long as I chose one of the less complex convolutions.

I notice one needs to start the recording more than two measures before the MIDI note data begins, for several of the reverbs, or else it doesn't kick in until after a couple of measures have flown by. Look-ahead algorithm for the pre-delays?

[David Stephen Baker]

Hi Guys,

Just for information.

I can use the convolution reverb on a powerbook 1Ghz with 1Gb of RAM.
You just need to increase latency settings.
512 or 1024 should be ok.

Of course it's hard to play in realtime in that case but playback is ok.

Sure it could be better but at least you could use it on a light configuration.

True-nuff.

Unfortunately this amount of latency renders the quality verbs usless for those of us in a live performance situation.

-Dave

[David Stephen Baker]

I notice one needs to start the recording more than two measures before the MIDI note data begins, for several of the reverbs, or else it doesn't kick in until after a couple of measures have flown by. Look-ahead algorithm for the pre-delays?

I noticed this as well and have been doing the same work-around. Starting in measure 3 seems to do it.

I thought it was simply related to pre-delay. Hmmmm.

-Dave