PlanetZ forums - scopeusers.com

Okay ,....I hate these discussions and I am mad at myself for such inquiries.

(pause)

Hey I havent been on here in a while, I moved over to Hardware production and loving it, but I have renewed faith in the Scope platform hmm. It sounds pretty good with my Hardware.

How are you guys doing, and when the hell is the new Scope Frontier coming?..LOL

-----

Anyway, To my point, Floating point gives a theoretical, 1500 db of headroom while, "Fixed" gives you a much more reduced amount of head room; 120db I believe, correct me if I'm wrong((All this is based on research, I'm no programmer).

-----

"Analog" is limited to a fixed DB limit under 200db(again Correct me if I'm wrong) (96db maybe),
_____


24 bit/16 bit software mixing is what most "Hardware"(Keyboards, Drum Machines, Dedicated Recorders ex: Roland 1680, are designed under, correct?) These sound IMHO, better than the vst 32bit FP standard(<----token subjective statement here, no need for rebuttal)...Good Floating Point VST sound design or not.

Of course there's the Issue of ADC, DAC, but that can be solved with Hardware(Apogee, Lucid, etc...)

Floating Point was introduced with the PC right?

Before Floating Point most Hardware designers, used fixed point math in there designs right?(Lexicon, etc)

Floating point gives an unnatural state of ability for music purposes(the threshold of pain is 190db right), than fixed, so why should one lean on floating point extreme possibilities? <---No distortion,... huh!?(Turn the damn volume down) Pristine quality,....huh?(24/16 bit sound cards are all thats available right(output of course).

Please excuse my long ramblings, but I am still curious as to why my hardware sampler sounds more real than my software sampler, especially when my hardware sampler is still software, with converters,(16 bit by the way<---another subjective rebuttal expected lol) \

Any comments, good or bad is welcome....But please no million replies of subjectiveness(Oh Boy, Now Ive Really Done It!!)





P.S. A little too much Cognac Perhaps?

yish313 wrote:P.S. A little too much Cognac Perhaps?

Perhaps. Entirely subjective.

yish313 wrote:....But please no million replies of subjectiveness

No problem. I'll just give you just the one.

Don't know, don't care. But I would concur with your findings that products employing DSP units on the whole are preferable if one is concerned about sound quality. Which is entirely subjective. I come from a background in old school recording techinques so all the hullaballoo regarding floating point headroom goes way over my head. I've always had to use correct gain staging on analog systems and digital ones and will continue to do so.

One of the main reasons dedicated chips are favourable, I reckon, is that companies who use DSP's in their devices employ the best talent and thus create superior products.

This is some musings by Dave Gamble @ Sonalksis, the developers of various native plugs.

"Sonalksis Development Blog

Wednesday, October 24, 2007

Dedicated DSP VS Native PlugIn Processing

There is a difference - there are several differences. But they may well not be what you expect them to be.

CPU Performance. Native processors have left all but the most high-end DSPs standing. A deep-pipelined microcoded CPU like an Intel Core chip is at least an order of magnitude faster than, say, a Motorola 56000 class DSP. It's a brutish and inelegant figure with which to make the comparison, but the clock rate of a Core2 can be set at 3GHz, whereas one would expect to see a 56000 DSP running at around 200MHz.

Of course, that comparison is entirely unfair- the DSP can do things that the Core2 cannot. The DSP can fetch two items from memory AND perform a multiply-accumulate in ONE cycle (when coded correctly). That choice of instruction is not arbitrary - the most common DSP task is to multiply-accumulate and fetch two - it's the heart of FIRs, IIRs and all manner of other lovely algorithms. That's either three or four instructions on the Core2, but as for how many clock cycles that would take, it's anyone's guess - somewhere between 1 and 10 seems likely. Anyone care to correct me?

The Core2 is harder to predict the performance because it depends on many things
- whether the numbers to be loaded are in cache or need to be fetched from RAM
- whether the code is in cache or is being fetched from RAM
- what the Core was doing previously
- what the Core is doing next.

Core processors employ what's known as a pipeline. Different parts of the chip handle different types of task, and they do so in parallel as far as is possible. When you write an algorithm for a DSP, at the end, you count the number of lines of assembly, and can state that the code will use N clock cycles. If you have a list of algorithms to run, with a list of how long they will take, it's very easy to schedule them and to know exactly how much processing capacity you need. And it is ENTIRELY reliable and predictable to do so.

Conversely, it's very easy when writing DSP code to know when you have been inefficient. You are going to use too many clock cycles. Working with external DSPs, you always end up optimising to minimise your cycle count - that means using tricks and shortcuts to get the best approximation to what you want, with as few instructions as possible. That's great fun, in a nerdy way. For instance, a lot of dynamics processing requires you to evaluate the mathematical functions log() and exp(). A Motorola DSP doesn't have a log or exp function - though it does have some instructions that can help approximate it. So when you code a compressor for that DSP, one of the fun things you have to do is build a fast log and exp approximator. There are endless tricks. With work, you can get close to the precision of a standard Native implementation - which are, as near as is meaningful, exact. You'll spend a lot of clock cycles doing that on a DSP though, and somewhere you'll find that you can trade off a bit of accuracy for extra speed.

The biggest difference between Motorola DSPs and Native processors is the fixed-point vs floating-point difference. To make clear the difference, a floating point number CONTAINS a 24bit fixed-point number, PLUS a scale that it can use to increase range. A floating point number = fixed point number * 2^scale - that is, a floating point number is a fixed point number, with a scale that can double or halve it many times.

So how can fixed-point sound better than floating, when floating can do more, is far more accurate, and we have more processing power to throw at it? My controvertial answer is - BECAUSE it doesn't have the range. Open up one of your sessions, right now. Insert a clipper at 0dB after EVERY plugin. What happened? Well, it depends on how hot you run your session - but if in general just a /little/ bit hot, you just got an overall shine added to your mix - a noisefloor of digital clip distortion and aliasing that boosted up your high-frequency energy and made everything a touch noisier. And you did it native!

This is the magic of dedicated DSPs - when your channel goes INTO a DSP plugin, and it's pretty warm but not clipping, and you then add a few dBs of EQ, you clip that band on the EQ's output. Clipping means high frequency energy, plus a touch of aliasing noise. The aliasing noise is likely to be very quiet, but the brain doesn't mind /small/ amounts because within a mix, it's just noise, and we, as humans, like a bit of noise. Boosting the high frequency energy is great though - more "warmth" from the clipped bass, more "openness" from the clipped mid and more "air" from the clipped top. As far as I can tell, and I must state that it is only a theory, this is what lies beneath the "bigger mixdowns" sound from using dedicated DSPs. But this is certainly not the ONLY thing.

Developing for dedicated DSP requires an investment cost - it's a filter. The kind of users who have dedicated DSP systems are those who spend more on software. By developing exclusively for dedicated DSP, you enter a part of the market where piracy is small (no 16yr-old kids cry themselves to sleep wishing they could get some new cracks for their pro-DSP rig...), and where customers are wealthy. It's also a filter in that only developers who are serious about their algorithms will bother to afford the buy-in cost for development. Since it's easier to develop for native, everyone and anyone can, and do. People with deep knowledge of how to write good sounding algorithms, however, will go that step further and develop for DSP, paying that buy-in cost in the sure knowledge that the market will receive them.

DSP plugins cost more because the developers need to recover that cost of developing for the DSP - nowadays people generally write code for Native and then port it to the DSP. Recovering the cost of the Native version will spread across many many users, whereas the developer needs the far fewer DSP users to help recover the DSP cost, which would be ill-advisedly passed on to the Native customers. It's also a question of standing. Selling £20 DSP plugins would just seem ridiculous to the market. It would not be likely be taken seriously."

All the waffle about native could do this or that theoretically with a billion instances of mediocrity when someone writes it if only they would is such old hat. If it doesn't run Scope I couldn't care less.

Until my cards get fried. Then master gets some more bigger ones. Yessssss.......

ns

usualy when a company invests tons of money in RnD they wouldn't want to hand it away in vst. hardware is a more "sure" path.

most vst's are created fast and with little or no rnd. most hardware has tones of rnd money invested. thats why they sound good.

the rest, is mumbo jumbo.
32bit integer has 256 times more resolution than 32bit float. because 32bit float uses 24bit resolution, and 8bit for point location. more headroom is very nice, but integer has its advantages. usually algos select the proper type internally (yes scope has 40 bit float and thats what happens in side most of your atoms, and thats the same resolution as the 32 bit integer incase u are wondering). still computers today use 64bit float which has much much more resolution. and it doesn't mean computers will start sounding better.

headroom is something a good developer will consider when programing in float or in integer and is not really an issue. so isn't the rounding logic except for really unstable fir filters, that can have a really slight difference. converters are also not the issue, today the simplest mp3 player sounds better than protools 10 years ago. its all about the product, the algos, the attention to details, and making sure the instrument is musical.

Computers can run realtime today and much faster than dsp chips, but as you know a dsp chip costs 10-50$ while a cpu costs 200-1000$ so thats why hardware developers opt for dsp.

so really hardware decisions are not really the case. its the case on how much one invests to make his product sound good, and the fact that he doesn't want to loose all of his money doing so

computers do what people tell them to. all the rest is just romantic voodoo.

just my two cents.

ReD_MuZe wrote:just my two cents.

Nice. Always good to hear from someone who actually does the spadework in reality.

ns

and the talk of cpu performance always assumes that the cpu has nothing better to do than to handle each plugin. in the real world, resources are not so available. dsps are dedicated processors which only need to do a single job.

got a macbook pro 2.5ghz dual core, i cant seem to overload it whatever i do. its a workhorse.

i love scope because it just sounds so damn good.

exactly.
as you know, all plugins are not equal.

DSP chips don't actually make a sound. I wish SC would develop some HD streaming applications, not just synth sims, ones that are easy to use as well. They also should have at least begun a sequencer by now. Using two mixing boards is an annoyance.

garyb wrote:exactly.
as you know, all plugins are not equal.

In Scope's case it can also be that not all atoms & modules in the library behave as expected. There's more than a few examples of that but naming them specifically isn't important. I seem to remember that certain supposedly high end commercial Scope plugs actually clip internally when they shouldn't be & the reason for that is that some of the modules in the library don't behave as expected & that either hasn't been noticed or has been ignored by the developer. With the Xtreme Cut device I just released it's the latter. I've ignored the problems knowing that with input gain available it's easy enough to avoid internal clipping. I seem to remember the likes of MOVeq having the same issue at one point in it's release history (just for example). Makes me think that Scope plugs which involve chains of modules in series could do with a visual reference for each stage in the chain, like a simple series of clip leds.

if it sounds good why bother?

normally i would say VST sounds worse, but the other day i was using "massive" from NI, and thats actually a fantastic synth. especially when played back through scope mixer and a16. and it is really fun to use. i might even buy it.

i watch my output on a hardware oscilloscope, and the difference between various VSTi is huge. some of it seems to be related to making them sound "more impressive" for people who download a demo and play it on the crappy computer speakers.

Massive uses 4x oversampling when @ 44.1/48khz, which helps considerably if your cpu can handle it. Several other softsynths (for example DiscoDSP Discovery) do this too. I must say that Massive is one of the few NI interfaces I actually like (the UI for mod sources makes adjustments quick).

valis wrote: if your cpu can handle it..

and that's the rub. to write for best sound quality or best usability...the cpu has a lot of jobs, otherwise things could sound much better.