1. I hooked up my Mackie 'control and got the faders to work [vital] but compared to say Nuendo which I plan to switch from the functionality is very weak. Is this something that will be improved soon, or should I just dump the Mackie?

As I said, the Mackie is the best supported control surface, but it is still fairly weak compared to other programs. The control surface support is really probably the weakest point of the program. Many folks, though, ditch the control surface when they learn to work with objects.

5. Has anyone tried keyfax with Samp to add extra programmed keys for double commands [Alt +, Shift + etc] or macros?

Standard key commands are all user-customizable. There is not a macro editor, but I don't see why you can't use one. I use the Shuttle Pro for some of my stuff, but by now, I'm so fast on the keyboard, that it is by far the fastest way for me to work.

6. I have a Lynx Two-c card and may get the Aurora plus AES-16. Any issues with these?

Nope. SequoiaDIGITAL builds mostly on Lynx, some on RME. Those are the only 2 manufacturers that we consider reliable enough for the machines.

7. I can't get the Samp 8 demo to work with my UAD-1 card. any ideas?

In what way? For mixing, there shouldn't be issues of any sort. There are lots of UAD-1 users that also use Samp and Sequoia. For tracking, you won't be able to use it because of the latency.

8. Does Samp work best with Asio drivers or WDM?

I use ASIO as I like the monitoring options. The monitoring options are much more limited in WDM. I've also found it to sound better in ASIO.

9. Does it work fine with VST plugins or do Direct x work better?

Either- both are latency compensated.

10 When you say the engine is almost the same in Samp and Sequioa, I know there is extra functionality, but do they SOUND the same or does Sequioa sound better? [I understand it may have more mastering tools to enhance the sound, but just the pure sonic qualities of the program itself]

The summing engine is exactly the same. The only differences come from things like an 8 channel surround project versus a 6 channel project. The way things work is identical. Some edits are possible in Sequoia that are not possible in Samplitude. I bring projects between the two regularly.

Is anyone here in the Arlington VA area or close to it who knows Samp inside out and would consider getting me up to speed for a fee?

I'd say- Ask on the user's forum when you get it.

--Ben

I've also found it to sound better in ASIO.

Now this makes no sense. We are talking drivers here.

DavidSpearritt wrote:

I've also found it to sound better in ASIO.

Now this makes no sense. We are talking drivers here.

Well, this would be the case, except, I notice the same output on CD whether I use ASIO or WDM. However, it does sound clearer and more like the CD presentation when monitored through ASIO.

Is anyone here in the Arlington VA area or close to it who knows Samp inside out and would consider getting me up to speed for a fee?

I can't say that I'm the most knowledgable on the subject, but I have learned an awful lot in the past few weeks using Sequoia. I'd be glad to sit down with you and work a bit. I think Ben is right, you will find yourself selling the Mackie Control real quick.

BTW, I couldn't think of charging you a fee, but bear in mind, you'll get what you pay for. :lol:

Feel free to contact me off-line.

J...

DavidSpearritt wrote:

I've also found it to sound better in ASIO.

Now this makes no sense. We are talking drivers here.

Hey- it is what I heard... Granted it is before I got my DAC-1, but I haven't gone back since.

My conjecture for why this may be... First of all, there are numerous issues with windows and multimedia. For example the famous 16 bit bottleneck. Every program/driver has their own way around it, but it is still there. ASIO is a Steinberg protocol, not a windows one and therefore isn't subject to that.

ASIO also offers a bit more direct connection to the hardware. Does this mean that clocking and other related things work better? Perhaps...

The fact is driver models function radically differently and the way they relate to windows is radically different. Remember, we are talking about a host based system. To think that they may cause a small difference in sound is really not beyond the realm of impossibility.

--Ben

We are moving numbers (data) around in a computer. If they do not move correctly then the thing is broken. There are no timing issues moving digital audio around, its just data. If what you say is correct, the whole computer industry and the devices that depend on it would fall apart.

That's a great theory Dave, but the simple fact is that programmers and subsequently drivers, move this data around differently. Not necessarily wrong, just different. These difference can make for very interesting changes in the sound. It's not as simple as taking a binary bit stream and handing it to the sound card which converts from D to A. If it were, there would be no reason to buy into higher quality cards, etc. Of course, the conversion itself makes up a good part of that, but how the drivers are implemented and how code is called into play can have a profound impact.

If there were "black and white" in the programming world, a lot of programmers would be out on the street. Programming and "code-calling" is an art as much as it's a science. Picasso couldn't paint worth crap. (There, I said it!) However, Dali was a friggin genious. Neither of them were wrong, I subjectively feel that Dali is better.

Same as in the computer world. Just cuz it's different, doesn't mean it's broken.

J...

Cucco wrote: Picasso couldn't paint worth crap.

Hmm. Not quite in agreement there. He did have a classical schooling, but choose to do differently. Sort of like a classically trained musician inventing first jazz, then rock, then disco pop and finally settling down doing death metal. He was one of the great inventors as far as styles goes.

Gunnar

I give up. White flag is hoisted and oscillating.

ghellquist wrote: [quote=Cucco] Picasso couldn't paint worth crap.

Hmm. Not quite in agreement there. He did have a classical schooling, but choose to do differently. Sort of like a classically trained musician inventing first jazz, then rock, then disco pop and finally settling down doing death metal. He was one of the great inventors as far as styles goes.

Gunnar

Bear in mind, I was using this as an example. Though I truly don't like any of Picasso's work from any of his progressive periods, I can't say "officially" that he can't paint work a crap. Hell, all I can do is stick figures (anatomically correct ones though) 8)

I started with Wavelab and tried Samplitude v6 ( back when they had the fully functional 90-day eval) when I had a project that needed multitrack. Bought a competetive upgrade to Samplitude Producer 24/96 v6, upgraded that to Samplitude Pro v7 and recently purchased Sequoia v7 (with v8 upgrade included) from Sequoia Digital.

I love the object-oriented editing and could never go back to traditional automation. Once you learn how easy it is to split a problem area, apply whatever it needs, and keep moving you may also be convinced. The v6 and v7 manuals were absolutely useless for beginners (which I still am on most levels) so I really hope the rewrite proves worth the wait.

Not that I personally know or have any experience with any of these products and am not siding one way or the other.

I have to specifically and emphatically state that Cucco, although maybe not even 100% understanding the underlying "true technical" reasons why he is correct, he is however correct.

32 bit Floats are firstly not the largest number possible, although I wont spend time proving my credentials, albeit be assured its not.
I can say this with 100% certainty

That each application can have an affect within the exact same machine on what the results are of a "result".
Saying that summing up two wave files together would guarantee the same result just because they are floats.. Trust me.. your wrong.

Processors have an affect on this(which means even if you could assure this on one machine, you cannot necessarily on another).

The order that the numbers are added/substracted etc also play a huge role.

Not only that.. but I can show you an easy way to generate wave files and guess what. it has nothing to do with 32 bit anything(especally floats), at least not in your simplistic explanation of how you feel it works. I just allocate memory, and I can do this in VB,C++, C, .Net, J++, whatever) and place what I want there, then I can write the data from memory to a binary format that just happens to match the headers/format required to be a wave.. and it will be a wave.. You can find examples like this all over the net..

Since you are actually using memory and pointers, you dont store all of a "wav" file in a 32 bit float, you may store it in a 32 bit address, they are NOT the same thing.

Since an application can easily generate a float, and then modify it to fit into a non float signed or unsigned (called converting), and then moving it back to a 32 bit float, that certainly doesnt mean the end result will be the same.

Will taking 2 files (at least using your explanation) and "adding" them together, produce for sure the same result. The answer is emphatically NO...

Again, Im not taking sides, im merely explaining.. Especially since you did in fact jump on Cucco for no reason that I could read..

jump on me if u want :-) difference is. i actually know what im talking about code wise.

Btw the compiler itself. has a huge affect. We have literally hundreds of variations of the C++ compiler(although we only sell "per say RTM bits", and each variation can easily affect the outcome of the same "mathematical" equation, even if the code didnt change.(happens all the time.. you should try debugging it).

Any Hoo i like the threar.. and I wont get in a back and forth over what I know is or isnt true. I was looking at just using cubase, but since i need my stuff for vocals mostly.. maybe I should look at other stuff as well.

Excellent stuff here Tenor2B. Of course I won't take it personally that you imply I have no idea what I'm talking about. :wink:

Your explanation is dead on, and it's appreciated. You're right, I'm not an extensive programmer - I do program, but it's only one type of application and that's it. You obviously have a far more extensive background.

Welcome to the forum.

J...

Lol sorry cucco i actually and honestly didnt mean to make it sound like you didnt know what you were talking about at all ;-).

Please dont be offended it wasnt meant to me :-)

and thanks!!

I've found the best sounding software to be SAWStudio.
http://www.sawstudio.com - their support is also the best I've come across.

cheers

omaru

Tenor2B wrote: Lol sorry cucco i actually and honestly didnt mean to make it sound like you didnt know what you were talking about at all ;-).

Please dont be offended it wasnt meant to me :-)

and thanks!!

Don't worry, none taken. I know my limitations and freely admit them. We're lucky to have people with your knowledge and skillset on the site.

BTW...Omaru, tell us more about SAWStudio. I've seen stuff about it, and I believe it's good, but I think their website is awful - there's way too much info on the page and it's hard for people with ADD like myself to follow anything.

Please, share what you like about SAW.

Thanks!

I'm a newcomer to Samplitude, and I bought it because my ears told me it sounded better when I downloaded the demo . That is a conclusion I came to on my own, before I had heard anyone else's opinion so I'm not jumping on the Samplitude bandwagon.

When using an audio engine, you are not just adding numbers together. A lot more goes on in the audio engine than that. You start off with a parallel streams of 24-bit integers. If you were to simply add up the numbers, the waves that are being added together would have to be of a lower resolution than the final target wave. Suppose you have several tracks, and at a particular point they all have a number nearing the highest possible 24-bit integer. You could not add them up to form another 24-bit number, as the result would be a number higher than the highest possible number of this type; they must summed using a number format of a higher resolution. When all of the samples are added together, it is then necessary to decrease the precision again to 24-bit before being output.

There are many ways to approach processing and this has to have an effect on the sound.

Anyone who thinks digital sound quality is just simple arithmetic should read up about the way the Benchmark DAC-1 works (and I'm not talking about jitter). If all fully functional audio engines should sound the same, then it would follow that the DAC-1 is a con.

John

PS this is purely supposition on my part as I've never built an audio engine, but I can't see any way that you can sum numbers without increasing the resolution in the process. Someone please correct me if I'm wrong :wink:

Reading my previous post, I realise that the remarks about the DAC-1 might come across as argumentative, or aimed at particular posters. I've read through this thread and others, but I can't remember who has a DAC-1 and who has not. I just mention it as it does its own thing with the numbers, and by all accounts it's one great piece of equipment. It's nice to see a product hyped by its users and not just by its manufacturer!

John

Oh boy, there is so much to counter here, preparing response now. Stand by.

Tenor2B wrote: I have to specifically and emphatically state that Cucco, although maybe not even 100% understanding the underlying "true technical" reasons why he is correct, he is however correct.

Right. Gotcha. Very convincing.

32 bit Floats are firstly not the largest number possible, although I wont spend time proving my credentials, albeit be assured its not. I can say this with 100% certainty

I am glad that you are certain, but of what? Are you talking about big big numbers on Cray supercomputers? Lets talk PC's, IEEE 32 bit float is the biggest most accurate number available in modern OO compilers used by the DAW companies.

Please NAME the compiler that you refer to that gives more accurate number math in a PC. Name? Manufacturer? DAW company who uses it? Wavelab, as stated and explained carefully by its author on the WL forum uses the MS C++ Compiler and the IEEE 32 bit number representation to do its math. The Sequoia website indicates the same. Some examples of what you are referring to would help me be convinced by your statements.

That each application can have an affect within the exact same machine on what the results are of a "result".

Huh?

Saying that summing up two wave files together would guarantee the same result just because they are floats.. Trust me.. your wrong.

Why? Explanation please?

Processors have an affect on this(which means even if you could assure this on one machine, you cannot necessarily on another).

Really??? So you are saying that an Excel spreadsheet gives different answers on different processors? This is puzzling.

The order that the numbers are added/substracted etc also play a huge role.

Already granted, but not HUGE! Affects very low level waveforms only. Most mixing in a DAW is with very healthy signal levels.

Not only that.. but I can show you an easy way to generate wave files and guess what. it has nothing to do with 32 bit anything(especally floats), at least not in your simplistic explanation of how you feel it works. I just allocate memory, and I can do this in VB,C++, C, .Net, J++, whatever) and place what I want there, then I can write the data from memory to a binary format that just happens to match the headers/format required to be a wave.. and it will be a wave.. You can find examples like this all over the net..

Huh?

Since you are actually using memory and pointers, you dont store all of a "wav" file in a 32 bit float, you may store it in a 32 bit address, they are NOT the same thing.

I am talking about a digital audio 32 bit word representing the amplitude of one sample, I am not sure what you are talking about?

Since an application can easily generate a float, and then modify it to fit into a non float signed or unsigned (called converting), and then moving it back to a 32 bit float, that certainly doesnt mean the end result will be the same.

True, then the program and the programmer is broken.

Will taking 2 files (at least using your explanation) and "adding" them together, produce for sure the same result. The answer is emphatically NO...

Why? 1+1=2 on any computer, on any OS, on any CPU.

Again, Im not taking sides, im merely explaining..

I cannot see many good explanations, plenty of statements.

Especially since you did in fact jump on Cucco for no reason that I could read..

jump on me if u want :-) difference is. i actually know what im talking about code wise.

Not convinced I'm afraid. Where are the clear reasons for your statements?

Btw the compiler itself. has a huge affect. We have literally hundreds of variations of the C++ compiler(although we only sell "per say RTM bits", and each variation can easily affect the outcome of the same "mathematical" equation, even if the code didnt change.(happens all the time.. you should try debugging it).

We are talking math and a floating point representation of a number defined by the IEEE. This has nothing to do with computers, its pure math. If different results are obtained then something is broken.

When using an audio engine, you are not just adding numbers together. A lot more goes on in the audio engine than that. You start off with a parallel streams of 24-bit integers. If you were to simply add up the numbers, the waves that are being added together would have to be of a lower resolution than the final target wave.

If you have two 24bit ints, these are immediately shoved into 32bit floats and then added or subtracted or multiplied to get a 32bit float result, no precision is lost. All DAW's do this, except PT in the early days when they used int math, silly fellas. I believe they now use float math as well.

There are many ways to approach processing and this has to have an effect on the sound.

What are these many approaches? Names?

Anyone who thinks digital sound quality is just simple arithmetic should read up about the way the Benchmark DAC-1 works (and I'm not talking about jitter). If all fully functional audio engines should sound the same, then it would follow that the DAC-1 is a con.

I have one and do all my testing with it. It upsamples, thats all. If I feed the same WAV data to the DAC-1, one thousand times, I will get the IDENTICAL upsampled WAV file out one thousand times, EXACTLY the same down to the last little tiny bit, just before the D/A stage.

Also I am not saying that "digital sound quality" is "simple arithmatic", I am saying that a DAW is a number calculator. As all calculators should do, it adds subtracts multiplies using consistent floating point rep of numbers. These rules will give EXACTLY the same answers, every time, ad infinitum, when fed the same inputs. The same answers equals the same WAV file output and therefore the same sound. If this not occur, planes would fall out of the sky.

Some short notes to earlier discussions.

There are severel different sizes of floats. The most common sizes are probably IEEE 32bit, 64 bit and 80 bit if my memory is correct (used to work on this in early 80-s). The types used to be supported in the Intel processor family Floating Point Units, but it is a long time since I did any assembly language work so that might have changed. There are, in my mind, generally few reasons to go beyond 32 bit for input and output, but internally an algorithm might want to go to longer floats to preserve the precision.

PT LE as far as I Know has always been 32 bit float.

PT TDM (and the other hardware types) is still and has been 48 bit fixed point for the summing bus. I believe parts are fixed 24 bit, most notably in and out for plugins.

Gunnar.

Well, this has gotten real interesting. Everyone agrees that certain programs "sound" different, but Dave wants the cold hard facts. I don't think this should be that hard to provide. I still have a copy of Cubase SX, I can drop the same wav's in both of them, sum them and then determine the difference.

Dave, would this pass the litmus test? (Without causing planes to fall from the sky?)

Let me give just one example of the software that I work with that is "broken" as you put it. Biometrics collection - specifically fingerprint capture and comparison. As many different manufacturers are on the market is as many different variations of programs. All software views the same image (your fingerprint and all of its minutia points), all of them use the same 32bit float compiler to determine the output stream for what's called the "template." (A digital version of your fingerprint - not the image itself - privacy advocates would be all over companies if they actually stored copies of your fingerprint's image) Yet, one "template" cannot be read by a different vendors software/hardware.

They all use the same input and the same data configurator, but they all come up with different results. Not broken - just proprietary.

I'm a newcomer to Samplitude, and I bought it because my ears told me it sounded better when I downloaded the demo . That is a conclusion I came to on my own, before I had heard anyone else's opinion so I'm not jumping on the Samplitude bandwagon.

Yeah, me too. I was actually on board to buy Pyramix. I'd used it, I liked it (still do), but then I put some stuff through the Samplitude demo and it truly sounded cleaner and clearer.

Dave, I'll work on the experiment.
8-)
J...

Cucco wrote: Well, this has gotten real interesting. Everyone agrees that certain programs "sound" different, but Dave wants the cold hard facts. I don't think this should be that hard to provide. I still have a copy of Cubase SX, I can drop the same wav's in both of them, sum them and then determine the difference.

Dave, would this pass the litmus test? (Without causing planes to fall from the sky?)

Bingo. Yes Jeremy, lets do the tests. I will contact you off list first as I know a couple of hi-res wavs we can download to add together. This is progress. :wink: 8-)

I am afraid a lot of people "surmise" what is going on, etc, because they have paid a lot of money etc.

Check out this thread on the WL forum.
http://forum.cubase.net/phpbb2/viewtopic.php?t=4341&sid=20ba15dc184d2b9f200e43532aea457c

ghellquist wrote: Some short notes to earlier discussions.

There are severel different sizes of floats. The most common sizes are probably IEEE 32bit, 64 bit and 80 bit if my memory is correct (used to work on this in early 80-s). The types used to be supported in the Intel processor family Floating Point Units, but it is a long time since I did any assembly language work so that might have changed. There are, in my mind, generally few reasons to go beyond 32 bit for input and output, but internally an algorithm might want to go to longer floats to preserve the precision.

Gunnar, you are right of course. I think there is a double float, an 8 byte (64bit) datatype, but its not used generally due to the speed reduction, ie double clock cycles to process and move around, and its simply not necessary as you indicate.

The 32bit float gives such mind boggling accuracy for calcs down to miniscule levels of voltage/sound that the differences would certainly not be rendered in any file back to 32bit integer and certainly not back to 24bit int, let alone 16bit.

Lets get this stuff into perspective for God's sake. I tell you, if you are turned on by some marketing gumpf that says that internal "engines" are running 80bit and you think you might be able to hear this when its all rendered back to ints of either 24 or 16bit, then you need a holiday.

Lol David, lets at least get into Perspective.. You know nothing about code.. FPU's, CPU's, Memory Registers and all your doing is throwing out IEEE 32bit and "dword" as if thats the end all be all..
Processors/FPU's are not required to have more then a "standard.. if they follow one" of precision. That precision is not every possible decimal of the 32 bit register.

So, does using "up to" a specific precision, on a specific processor/fpu, etc mean your going to get the same value.. i've love to say guaranteed 100% yes but you just cant.

That being said you still cant control "what precision", order or conversions that each application uses/does.

So .. then are the programs using Single or Double, are they emulating MBF standards.. in either Single or Double Precision

Throwing out the Term IEEE 32 bit doesnt mean you will get the same numbers.

69.82! + 1 = Single precision, 70.82.
69.82# + 1 = Double precision 70.81999999999999. Thats just one stupid example in a program language

However they are NOT the same number, they will NEVER be the same number, but they are BoTH using IEEE standards.

Therefor.. can you come up with different results Yes.

Because the same compiler can do both, and since you dont realize that, you will stick with your "absolute mind" set.. Dont believe it.. You are more then welcome to call me at MS.. since you keep throwing out the name like you work there(and umm you dont).

As for not using 64 bit floats. err wow really. I guess we should toss out or 64 bit OS's and Intel/AMD should toss out their 64 bit processors lol.. not..

Anyhoo.. Point is your arguing something you truly dont understand, but your too stubborn to understand that.

Since you also dont seem to understand that YES processors make a difference.. WHY.. well lets see.. each of them has what is called an FPU built into them(at least the new computers since 486 usually do). You could get add ons for those back then too..

Is the precision always the same nope, could adding 1 + 1 in excel give you something different.. no but then your not talking about a float, your talking about a short(or a bit), but adding values in different programs who request("this much precision" versus "this program wanting this"), can have a difference.

just because something is in a 32 bit register doesnt mean it remotely has to have the same result.

But you seem like you always will think that :-) so please, go for that and please for the love of God, dont ever try to get a programming job at MS... at least not next to me.

As for "Gods Sake" perspective.. actually believing that all programs will always come out with the same mathematical outcome(or in this case result) because "you" say they will... lol.. please..

Ohhh and just for "perspectives sake"

http://www.scit.wlv.ac.uk/cbook/chap4.fp.accuracy.html

is a clear example of why floating point math is NOT 100% accurate on all machines, processors or applications.

I dunno maybe david can fix it..

and also this is "not" c++ the inference is 100% the same.. you can also find exact things such as this on the MS site and more so internally. We dont control the cpu/fpu's the precision requirement of an application.

I also want to state that although I do work for MS, I am in no way representing them here or now and these are my own opinions etc etc.

If you can show me that they not only do everything in the same order, have the same CPU/FPU precision and then they also request the same precision and dont sample down(or convert) then yes.. ill agree in that scenario you should get the same information.. none of which you can guarantee..

You want real issues with Floats.. I write graphics programs(games) and have my own 3d engine.. there is NO difference in the sound use of floats and the graphics use of floats.. and they are the biggest pain.. as each machine/cpu etc can have a difference on them, especially if you randomly generate them. ugh

You can also go to msdn.microsoft.com and look up float(there will be tons of information on it), in which case you will see(yes from Microsoft) statements such as the below excerpt talking about singles/doubles and the issues with the inaccuracy warnings of use of float points numbers

Because of these limitations to floating-point mathematics, you might encounter rounding errors when you perform operations on floating-point numbers. If you do not require absolute accuracy the floating-point data types are ideal for representing very small or very large values. On the other hand, if your values must be accurate — for example, if you are working with money values — you should consider one of the scaled integer data types

Wow.. sure sounds like you can get different information to me.. esecially since if one program says " i only want 100 digits past the decimal" and another says "i want 10" and another says "i want 1000".. it changes the outcome... especially once it is finally converted down to the final forat.
anyhoo.. :-) happy vocalizing.

Firing up VS2003 Ent on my desktop, cause I write code during the day... and typing this in and running it ....

sub Main
dim sngNumber1 as single
dim sngNumber2 as single

dim dblNumber1 as double
dim dblNumber2 as double

sngNumber1 = 1.0
sngNumber2 = 69.82

dblNumber1 = 1.0
dblNumber2 = 69.82

console.WriteLine (sngNumber1+sngNumber2)
console.WriteLine (dblNumber1+dblNumber2)
console.ReadLine()

end sub

Gives

70.82
70.82

So I am not sure what CPU/compiler you are using, but its broken. A clue to its broken state was given to you when your double precision result was less accurate than your single precision result. Perhaps a support call to MS might help. :wink:

Hey david :-) firstly at least "read" what people write.
secondly. know your code. your using Visual Basic .Net not even Visual C++..wow. masterful.

singles and doubles with the values you are adding(which btw.. you arent even coming close to specifying any scalar precision) your letting the compiler do auto defaults.

you have all of what 2. decimal places.

Since Microsoft Clearly states that Floats are not mathematically guaranteed to be accruate, just the opposite.. I see you decided to ty to pick on the "single" thing you could try to..

At least use and understand how the language you are working with works.

Microsoft Visual Basic doesnt use the same underlying engine as Microsoft VC++ even in .Net.. Especially between managed/unmanaged code.

Gosh.. i would have figured a genius like you knew that.

Final point is.. since floats, as you have so "blindly" showed, can have an unlimited number of decimal places and then can be rounded later, or converted. you are never guaranteed to get the same outcome..

So adding two floats at different precision wont give you that same number.. eww so close though..

now just to be even more goofy i decided to go your route.. heres some VB Code

Dim a As Single
Dim b As Double

a = 1.1234523452345235
b = 1.1234523452345235

Debug.WriteLine(CStr(a * 0.29387409287340827))
Debug.WriteLine(CStr(b * 0.29387409287340827))

know what though? The answers are
0.330153527251681
0.330153538842299

Guess what those numbers arent.. the same..

But wait.. i know you will say.. but you arent adding.

oh okies lets add them
Dim a As Single
Dim b As Double

a = 1.1234523452345235
b = 1.1234523452345235

Debug.WriteLine(CStr(a + 0.29387409287340827))
Debug.WriteLine(CStr(b + 0.29387409287340827))

Guess what.
1.41732639866717
1.41732643810793

They still arent the same..

Please.. next time at least do some testing.. like you keep telling everyone else..

and learn to code.

Wow and I forgot..(that info i gave you on the floats not being equal was also from a Microsoft compiler)

but.. from MSDN again.

http://support.microsoft.com/default.aspx?scid=kb;en-us;145889

The article talks about how the CPU affects floating point precision..

Wow.. again Im right.. your wrong.. that seems to be a standard though.

Oh and btw genius.. the reason the Double is what YOU are calling not as precise is between double doesnt automatically round the same way as single.. Therefor double would give you exactly what this would(with the Microsoft QBasic Compiler and MSDN article that I copied the info from). Again it was just an example.

Again, please understand how the numbers work.. Double is more precise(meaning MORE decimal places) it doesnt mean the darn number closest to the decimal place is more accurate.. at least not in the term you are associating it..

Sheesh.. "have perspective", your not a coder, your wrong just admit it :-).. I can go at this all day and youll still be wrong.

After reading your link, I also did this.

sub Main
dim sngN1 as single '32bit floats
dim sngN2 as single

dim dblN1 as double '64bit floats
dim dblN2 as double

sngN1 = 1.0
sngN2 = 1/3

dblN1 = 1.0
dblN2 = 1/3

console.WriteLine(sngN1-sngN2-sngN2-sngN2)
console.WriteLine(sngN1-3*sngN2)

console.WriteLine(dblN1-dblN2-dblN2-dblN2)
console.WriteLine(dblN1-3*dblN2)

'Convert back to 32bit ints
console.WriteLine(cint(sngN1-sngN2-sngN2-sngN2))
console.WriteLine(cint(sngN1-3*sngN2))

console.WriteLine(cint(dblN1-dblN2-dblN2-dblN2))
console.WriteLine(cint(dblN1-3*dblN2))

Console.ReadLine()

and got

-2.980232E-08
-2.980232E-08
1.11022302462516E-16
0
0
0
0
0

So if all DAW's use 32bit float they will get the same answers if their compilers aren't broken.

Hey david firstly at least "read" what people write.
secondly. know your code. your using Visual Basic .Net not even Visual C++..wow. masterful.

singles and doubles with the values you are adding(which btw.. you arent even coming close to specifying any scalar precision) your letting the compiler do auto defaults.

you have all of what 2. decimal places.

I just used your example.

How exactly does using the cint function on a double/single that FORCES integer scalar precision.. prove that adding TWO floats.. is always the same.

Lol.. what a joke

But I am not interested in comparing the addition or mult precision results between a single and a double, this thread is talking about a single in one DAW and a single in another DAW. Your example proves nothing as well.

The reason you are still incorrect is because EVEN a single to single can have different values based on the CPU, the precision the person asks for. This is not meant as Double/Single precision

But if you take 1.555555555
If you round it becomes 1.5555556 (im not actually counting spaces here so bear with me)

That automatically makes the single different. Since its BITS we are talking then the ONE bit at a minimum is DIFFERENT making the output DIFFERENT..

Holy sheesh is it really that difficult?

Lets now say you have TWO wavs(which you plan to add) as you said.

Is 1.5555555 + 1.55555555 with a precision of (lets be stupid as again im not counting how much i type) to 9 digits
The same as
1.5555556 + 1.5555556 (lets say they rounded first).
No they arent the darn same thing and I dont care if you use singles, doubles or anything else.

And certainly you arent going to tell me that
1.5555
+ 1.5555
is the same as
1.55555555555
1.55555555555
or are you?

since Singles can easily have this sort of precision, WHICH one are all the programs using.. how do you know? what precision is guaranteed on the processor(again YES it has an affect).

Im not saying programs ARE or should be modifying bits etc.. but sheesh to say without reguard, that they cant be different..

Common.. your just being inflexible on purpose.. and your still wrong :-)

I did want to add, that I totally and happily conceed that if you just take two singles and absolutely did the same thing in both programs you SHOULD get the same outcome.. However your argument is that each program WILL produce the same outcome(for sure) and this is totally illogical as you cant possibly know what order they do things, how they convert, truncate, for each program, and knowing they use "single" doesnt mean squat else.

Tenor2B wrote: But if you take 1.555555555
If you round it becomes 1.5555556 (im not actually counting spaces here so bear with me)

But we are always taking less precise numbers, 24bit ints and making them into more precise numbers, 32 bit floats before doing any math. There is no rounding, so I cannot understand the point of your posts. Then we are using 32bit float throughout and will get 32 bit float answers. I am saying these answers will be the same between different DAW's. If they are not then the differences are orders of magnitude less than we can detect or they are completely removed when the final WAV is rendered.

Sorry to be so thick, you are obviously a well mannered genius, so I am out of place here.

Nod, the precision is more accurate of a representation of the number, but that representation is still only guaranteed to a certain "decimal" and who is to say they didnt convert from an INT to a higher precision float?(more decimal places). Who is to say they didnt do less? What did the processor/fpu return as the starting single?

At least initially.. because lets say you had an int that was

24(being dumb)
then you change it to a float
and on "this" computer it makes it
23.54985794857948754985794 (again making this up as an example)
on this computer
23.54985794857948754763833 (again making this up as an

those are NOT the same number and this can happen. what your not understanding is that floats are NOT guaranteed to the infinite decimal place.

this means that anything past spot xyz is not guaranteed. So you can get different results. This is a fact, not an opinion.

Ok.. now thats a better statement :-).. saying that its something you wont notice because its removed when turned back into an int is possible.. based on the fact that floats are not "hugely" inaccurate.. however.

(btw the rounding part occurs in your processor or at your software layer depending on the coder/cpu, if you go past the requested precision so I was merely using that as another example of how its not guaranteed to be the same).

But again, the point here is that "you" cant gaurantee (and I DID say that if you could guarantee on the same machine you should be ok), that things are happening on the same level.

Thats all.. you cant guarantee just because they use floats that they dont do anything different with the numbers.

Whether its bugs(ones that arent totally noticable) or intentional for affects, it is possible to get different results.

However I do agree, and (with the concession that the programs have no bugs, and do everything guaranteed in the same order, using the same values for modifying the wav) that you have alot less chance, after it is rounded to an int(forced scalar values), that you would see little different in the number.. now whether you can hear it.. im not a voltage/db level expert :-).

So for the sake of ending this :-).

Ill agree that if you could prove they all do it all the same way(not just the data type cause that means squat).
(1.453453453454 * 3) + .15
isnt the same as
(1.453453453454 + .15) * 3

So if such modifications are done(to add affects or whatever) are done in a different order then it does come different.

Anyhoo :-) , I only know that in code(when its written by others), no matter how much they try to use "shared" or "templated" code, can always, always come up with different results.

Bah im tired now :-).. and this is boring now.

Sorry all for the spam posts :-)

Wow… maybe I shouldn’t jump in here, but I think y’all are getting too hung up on math. There are other ways that DAW’s can differ from each other.

Audio engines in the major DAW’s run at high internal bit depth. We apply a high-quality dither when we bounce down to 16/44.1k for final distribution. But what happens when we listen to our monitors during mixdown?

The program I use – Samplitude -- runs at 32 bit float, but my DAC can’t deal with that. So (as I understand it) Samplitude dithers in realtime when passing a 24-bit word to my DAC. I assume this is some kind of proprietary dither optimized for speed, vs. quality. And I’ll bet it’s not the same process used by PT, Nuendo, or Logic. The programmers working with those systems are all going to have their own ideas of how to feed a 24 bit word from a higher bit depth audio engine through a DAC, so we can hear things in the outside world while mixing or mastering. Some programs may even just truncate, for the sake of realtime speed. As we all know, there are lots of different choices in how to do dither/noise-shaping, and if you can hear those differences, then different DAW’s will sound different from each other in a realtime feed to your DAC and monitors.

Another variable is pan law. I read a lot of DAW comparisons where people don’t take this into account. Like many other programs, Samplitude’s pan law can be set several different ways. Which version are we comparing? Different pan law settings can make one program sound slightly louder than another, which shifts your perception of audio quality.

Programmers can also play games with gain staging and metering. For years, there was a sort of urban myth among users of the Emu/Ensoniq Paris DAW that you could push the faders into the red (something like tape), without distortion. It turns out that the designers may have fudged the gain staging and meter calibration -- applying a gain reduction to the mixer section faders so it looks like you can push tracks into the red for a “fatter” sound, while they were applying invisible makeup gain in the master section. This may have fooled people into thinking that the Paris system had more headroom than other DAW’s. And of course it’s difficult to compare a mix with other DAW’s when the clipping point in the mixer section meters actually isn’t the clipping point in the audio engine!

Anyway, I’m no expert at this stuff, but these are just a few ways in which “math isn’t just math” when you’re comparing different DAW’s.

That said, I do believe the differences in current programs are so subtle that you’re better off choosing a program based on workflow preference instead of intrinsic sound. None of the current major programs are so bad that I’d reject them on sound quality alone. I like the sound of Samplitude, but I like the workflow better.

Mike

For the sake of simplicity, let's suppose we are dealing with an 8-bit setup. Each sample is an integer that can't be greater than 256. If one is 200, and another happens to be 200, when these are added together the number will be 400 which can't exist as an eight bit integer. You HAVE TO change these numbers to process them, and then downsample at the end. The simplest way is to represent them with a higer bitrate, supposing that we decide to process them as integers. I know that in practice we are dealing with a much more complex situation.

Can anyone disagree with this? No. It's a statement of fact. You can't use simple addition. It won't work.

You have to do someting else. That's an incontrovertible fact that can be shown without needing to go into the complexities of the way computers deal with numbers. It's going to sound different according to the way it's done. I can't see how anyone can fail to accept this.

John Stafford

A 32 bit DAW, changes the 200 FIRST into 32bit float BEFORE the addition. Then it adds, to get 400 float and then you change the gain to fit it back on a CD. Simple.

maybe someone could postulate this over on the Samlitude forum and see what the developers say. Assuming it's not some huge trade secret, perhaps they can explain what it is they do....

DavidSpearritt wrote: A 32 bit DAW, changes the 200 FIRST into 32bit float BEFORE the addition. Then it adds, to get 400 float and then you change the gain to fit it back on a CD. Simple.

Hi David
Reducing the gain in the digital domain is the same as reducing the precision, and when you are summing several samples, it's very unlikely that whatever comes out at the other end will not have some unwanted side-effects after rounding the numbers up or down. You have to throw away some of the information.

You could also simply reduce the 'gain' to turn a 24-bit sample to 16-bit, and then chop of the unwanted 0s, but most would argue that other ways to do it that sound a lot better.

John