Hi ShinOBIWAN,
I have one more question on your building procedure. You are painting all speakers box parts appart then glue them together. Can you discrib the glueing procedure with glue type and how you manage the glueing from differents parts without damage the painted surface.
Marc
I have one more question on your building procedure. You are painting all speakers box parts appart then glue them together. Can you discrib the glueing procedure with glue type and how you manage the glueing from differents parts without damage the painted surface.
Marc
Idefixes said:
Sorry Marc, I'm not sure what you mean.
The cabinets are fully built before and glued together before spraying. No gluing occurs after the paint job.
Could you elaborate?
ShinOBIWAN said:
Sorry for my approxamativ english. On these pictures the grey part was painted appart from black part No? So how do you glue them together without damaging painting work since you have to press them together when using conventional white wood glue.
Marc
The baffle is held in place with 3x 5" screws. Then between the baffle and enclosure are sorbothane damping and double sided gasket sealing strip(stuff used for temporary window insulation).
m0tion,
I suppose you're right, it probably should go in a separate thread. I posted in here first just because it struck me how beautifully it could lend itself to shinobiwan's project. I'd also be very pleased to play a part in such a brilliant project, even if it is just a small one 🙂
I will start a thread for this at some point, although I might wait until the code is a little more polished (I'm not an experienced C++ programmer and the state of the code right now is almost embarrassing). I'm also looking into making the code multithreaded, since I know a lot of people have dual-core CPUs and whatnot. The machine I'm using it on is actually a dual-PIII 700 so this would benefit me also.
Beyond that, I'm looking into optimizing for SSE2 but haven't started that actively as yet. Will be trickier to test in the short term since PIIIs don't have SSE2. But we'll see.
Still a long ways to go!
Of course, if anyone would like to get hold of it in the meantime then you are welcome.
M0tion, are you interested in a tutorial showing how I wrote the code for this? If so, the PortAudio website already has truly *excellent* tutorials on how to use PA for your own applications, so I really don't think there's a lot for me to say on that front.
I suppose my part of the work was really in writing the classes for the various DSP modules. But anyone who's coded a biquad or an FIR filter will know that these are not complex beasts to write code for. All that's needed is a little care with numerical precision and ensuring you dither things correctly. It definitely helped me having an Audio Precision instrument to verify the system with, though. In testing I found more than one bug which destroyed all the careful number handling that had gone before it.
All sorted now, though 🙂
If you want to know how I put my specific crossover together, then it's a simple-ish process involving MATLAB to produce the relevant filter kernels.
I came up with my specific layout of FIR between tweeter and mid, and fourth-order IIR between mid and woofer partly out of experimentation - I think the tweeter-mid integration really really benefits from a linear-phase crossover, but the mid-woofer integration requires it less. At these lower frequencies (200Hz in my case) the FIR kernels have to be very long which saps up CPU power and may well suffer more from the ever-feared pre-echo effects. I'm not in a position to be able to comment on the audibility of that with any authority.
Regardless, I personally don't feel the sound suffers using IIR for the lower crossover. The room will play a big part in how the phase at the listening position turns out at these frequencies also.
It would be nice to get some feedback on what people think is the best way of doing things. One of the nice things about my program is that you're really free to implement things however you want, and that you really know what is happening to your audio.
I suppose you're right, it probably should go in a separate thread. I posted in here first just because it struck me how beautifully it could lend itself to shinobiwan's project. I'd also be very pleased to play a part in such a brilliant project, even if it is just a small one 🙂
I will start a thread for this at some point, although I might wait until the code is a little more polished (I'm not an experienced C++ programmer and the state of the code right now is almost embarrassing). I'm also looking into making the code multithreaded, since I know a lot of people have dual-core CPUs and whatnot. The machine I'm using it on is actually a dual-PIII 700 so this would benefit me also.
Beyond that, I'm looking into optimizing for SSE2 but haven't started that actively as yet. Will be trickier to test in the short term since PIIIs don't have SSE2. But we'll see.
Still a long ways to go!
Of course, if anyone would like to get hold of it in the meantime then you are welcome.
M0tion, are you interested in a tutorial showing how I wrote the code for this? If so, the PortAudio website already has truly *excellent* tutorials on how to use PA for your own applications, so I really don't think there's a lot for me to say on that front.
I suppose my part of the work was really in writing the classes for the various DSP modules. But anyone who's coded a biquad or an FIR filter will know that these are not complex beasts to write code for. All that's needed is a little care with numerical precision and ensuring you dither things correctly. It definitely helped me having an Audio Precision instrument to verify the system with, though. In testing I found more than one bug which destroyed all the careful number handling that had gone before it.
All sorted now, though 🙂
If you want to know how I put my specific crossover together, then it's a simple-ish process involving MATLAB to produce the relevant filter kernels.
I came up with my specific layout of FIR between tweeter and mid, and fourth-order IIR between mid and woofer partly out of experimentation - I think the tweeter-mid integration really really benefits from a linear-phase crossover, but the mid-woofer integration requires it less. At these lower frequencies (200Hz in my case) the FIR kernels have to be very long which saps up CPU power and may well suffer more from the ever-feared pre-echo effects. I'm not in a position to be able to comment on the audibility of that with any authority.
Regardless, I personally don't feel the sound suffers using IIR for the lower crossover. The room will play a big part in how the phase at the listening position turns out at these frequencies also.
It would be nice to get some feedback on what people think is the best way of doing things. One of the nice things about my program is that you're really free to implement things however you want, and that you really know what is happening to your audio.
Hi wingfeather,
Cool stuff you've got going on there. A year or so back and I'd have jumped all over this, however I've let things slip since then. I'm not sure I fancy the idea of messing around with all that again, I've become really accustom to the convenience of the DEQX, even though it might not be the most flexible, most powerful nor the best sounding solution.
I'd certainly vote for you opening a thread to dedicate to this promising project. I'm sure many would be interested and I'll probably check it out at some point too(especially if the user interface was brought up to speed).
OK now a fairly long, boring rant not directed at anyone in particular:
I was delighted to hear of a new DEQX, rather boring called the PDC3.0 which will replace the 5 year old PDC2.6(that an awfully long time in technology terms). I think the reason the 2.6 has stood the test of time so well is because it revolves around its software which has continually been updated throughout its tenure. The hardware inside the 2.6 is extremely basic by todays standards; dual SHARC's(found inside £300 AV receivers), bog standard delta sigma DAC's(which offer a paltry ~106dB SNR compared to 120dB high end stuff), switch mode PSU, plain old op-amp based analogue outs and the list just drones on. It makes you wonder just why the DEQX hasn't dropped in price since its initial inception, well the answers is your really paying for the software. The hardware in this case is merely a means to an end, at least by todays yardsticks.
The new model looks to bring the DEQX up to date hardware-wise although details are very scarce at the moment but this box will form the heart of these speakers. Unfortunately, despite a showing at CES 07, no firm release date is set.
All in all although these will be ready for the meet in July but I don't believe they will be playing, if I say that now then I'll avoid disappointing folks. I sincerely hope they are playing come then but my PC XO is a shadow of its former self since I have no fancy soundcard just a Creative X-Fi Platinum and I was going to pull the trigger on a DEQX PDC 2.6 before I found out about the new version but I believe that would be financial suicide. So with no sensible XO options it looks like a wait for the new DEQX box.
Wow, three paragraphs which could have been summed up in three sentences, can you tell I'm feeling guilty? 😀
Cool stuff you've got going on there. A year or so back and I'd have jumped all over this, however I've let things slip since then. I'm not sure I fancy the idea of messing around with all that again, I've become really accustom to the convenience of the DEQX, even though it might not be the most flexible, most powerful nor the best sounding solution.
I'd certainly vote for you opening a thread to dedicate to this promising project. I'm sure many would be interested and I'll probably check it out at some point too(especially if the user interface was brought up to speed).
OK now a fairly long, boring rant not directed at anyone in particular:
I was delighted to hear of a new DEQX, rather boring called the PDC3.0 which will replace the 5 year old PDC2.6(that an awfully long time in technology terms). I think the reason the 2.6 has stood the test of time so well is because it revolves around its software which has continually been updated throughout its tenure. The hardware inside the 2.6 is extremely basic by todays standards; dual SHARC's(found inside £300 AV receivers), bog standard delta sigma DAC's(which offer a paltry ~106dB SNR compared to 120dB high end stuff), switch mode PSU, plain old op-amp based analogue outs and the list just drones on. It makes you wonder just why the DEQX hasn't dropped in price since its initial inception, well the answers is your really paying for the software. The hardware in this case is merely a means to an end, at least by todays yardsticks.
The new model looks to bring the DEQX up to date hardware-wise although details are very scarce at the moment but this box will form the heart of these speakers. Unfortunately, despite a showing at CES 07, no firm release date is set.
All in all although these will be ready for the meet in July but I don't believe they will be playing, if I say that now then I'll avoid disappointing folks. I sincerely hope they are playing come then but my PC XO is a shadow of its former self since I have no fancy soundcard just a Creative X-Fi Platinum and I was going to pull the trigger on a DEQX PDC 2.6 before I found out about the new version but I believe that would be financial suicide. So with no sensible XO options it looks like a wait for the new DEQX box.
Wow, three paragraphs which could have been summed up in three sentences, can you tell I'm feeling guilty? 😀
ShinOBIWAN said:
I agree with you. I had a chance to listen DEQX on really nice TAD horns and big box speakers. I wasn't impressed at all. Very average sounding unit. There is only one option that I like with DEQX - ordering it with digital outs, which will let you put your own DA converters and analogue outs. Quite honestly I do not see any reason of having price that it has. The well modded Behringer DCX (completely replaced or transformer substituted analog circuitry) will outperfom DEQX in factory form. The difference in price between the two is just unreal and unjustified.
AR2 said:
The software and filtering algorithms running the show are a quantum leap ahead of the pedestrian stuff found in the DCX and so was the development cycle. The DCX uses textbook filters tied together in the most unimaginative fashion, its has 1/10th the functionality and power of the DEQX so I'm not surprised when I see it priced similarly. No comment on sound quality though, I'm talking about feature set here. The current DEQX is waaay over priced though, I'd say it should be £1000 vs. the £2000 it has always sold for.
When the DEQX was first introduced all those years ago, the hardware was fresh and fairly cutting edge for the application. The software was just massively left field for a consumer unit, brilliant stuff for 2002 actually and through the updates its still the only real choice out there for an all in one box of tricks that covers filtering and correction. But this is 2007 and you can pick up the bits of hardware that make up the DEQX for nothing now, I can only surmise that the development costs of the DEQX were substantial and they still consider their software, rather than the hardware, to be worth the asking price. Since its the only product in its catagory, they've got a niche and their exploiting it.
Despite update hardware, the new PDC 3.0 isn't going to turn what was average for you into something great, I think you do describe the DEQX sound well. Its average because its creates an accurate loudspeaker and by extension of this accuracy the burden is shifted more to the recording and, because of this, rarely is the event captured. Having done some searching I have to conclude its the type of sound I most prefer. Being really honest, I'll hold my hand up and say that the building, creating, trying things out and the thought of how something might sound are quite often more appealing than music itself. I'm quite jaded these days.
I guess thats the beauty of building loudspeakers - you take from it what you will.
Shin,
That is of course fine 🙂 It was just a suggestion, and I understand perfectly why you'd go for the convenience of the DEQX. Doing it the way I want to is fiddly at the best of times.
Had a quick look at the graphs on the DEQX website, and I see what you mean about the hardware! They don't seem to say how many FFT bins they used to make their plots, but assuming it was of the order of 16K then their unit appears to provide not much more than 16-bit performance (16-bit would place the noise floor around -135dBFS with 16k bins). They also have some weird stuff going on immediately around the input frequency with their D-D graph (figures 16 & 17), but that's probably just the window they used.
I don't like the look of the random spikes jutting up out of the noise floor in fig. 16 & 17, either. Those shouldn't be there.
Let's hope the new one does better 🙂
That is of course fine 🙂 It was just a suggestion, and I understand perfectly why you'd go for the convenience of the DEQX. Doing it the way I want to is fiddly at the best of times.
Had a quick look at the graphs on the DEQX website, and I see what you mean about the hardware! They don't seem to say how many FFT bins they used to make their plots, but assuming it was of the order of 16K then their unit appears to provide not much more than 16-bit performance (16-bit would place the noise floor around -135dBFS with 16k bins). They also have some weird stuff going on immediately around the input frequency with their D-D graph (figures 16 & 17), but that's probably just the window they used.
I don't like the look of the random spikes jutting up out of the noise floor in fig. 16 & 17, either. Those shouldn't be there.
Let's hope the new one does better 🙂
Ah. They freely admit to using 32-bit floating point. Might explain their noise floor problems.
(I say problems... note that I'm not of the opinion that many people are going to actually *notice* a distortion product that's at -150dBFS. I'm speaking more from a theoretical point of view here)
(I say problems... note that I'm not of the opinion that many people are going to actually *notice* a distortion product that's at -150dBFS. I'm speaking more from a theoretical point of view here)
Wingfeather said:
That's just it. I've traveled both roads - the hardware boxes such as the DEQX/DCX and also a multitude of PC based setups from the Waves to Frequency Allocator to Acourate+Pristine Space.
Ideally we could take idea's like yours and the whole ideology, power and sheer flexibility of the best PCXO implementations and plant it in a tidy standalone hardware solution. That hasn't happened yet so we either get to spend 50 seconds of each minute tweaking or pampering with the remaining 10 seconds spent listening to music that is made that much better because of it or we can spend 50 seconds out of minute listening to music thats enjoyable and only 10 seconds on the bit that you've grown to not take much pleasure in.
After my PC XO journey that my cynical view, it was a roller coaster ride with many high points but just as much disappointment and frustration. I could be speaking out of terms here because its about 6 months since I gave it much attention and things may have moved on but I don't think its quite where it needs to be.
With the help of dedicated folks such as yourself that will change and people, including companies, will be made aware of just how to handle the data as its passed through processing mechanisms.
Wingfeather said:
I think it all adds to a more processed sound that many people seem to object to with digital audio. Perhaps not that one distortion mechanism alone but given enough of these cumulative effects and they will become noticeable.
Can't you use 64bit integers? Most CPU's these days are 64bit and have instruction sets as such.
That's exactly what I'm doing in mine.
The audio path is 32-bit signed integer, and all the filter coefficients are 32-bit signed integer. When you multiply the audio by the coefficients you get 64-bit signed integers as your intermediate results. These must be dithered back down to 32-bits for subsequent DSP operations or to go back onto the audio path (as in, between filters).
SSE2 has instructions to multiply two simultaneous pairs of 64-bit integers into two 64-bit results which would be ideal for this (you'd put your two pairs of 32-bit numbers in as the operands and get two 64-bit numbers out at the end). This instruction would be ideal for what I've done. I just need to work out how to use the SSE2 functions!
Floating point in audio is a no-no if you can avoid it. Especially single-precision as every operation you do is akin to an undithered 24-bit integer truncation. The nasty noise floor will quickly add up as you do more operations.
With regards to DEQX, I understand three new models are on the horizon
1) The PDC3 preamp processor. This has essentially the same internals as PDC2.6P but is 2U high with thick aluminum front panel and machined buttons etc. It also has blanked out cut-outs on the rear panel for the Dig out and the Bal out boards, so both can be installed together and can be upgraded in the field. There is a new all Jensen transformer balanced out board ($950) that is compatible with the existing one, so can also be used in PDC=2.6 models. List price of standard unit is US$4,450. Option prices for Bal out, dig out, and Earthworks mic are the same as for PDC-2.6 options.
2) The PDC3-300 is the same as above but with four internal Hypex UcD180'AD' version amps (for bi-amping) with 300W linear PSU that also powers the PDC board. Speakon 4-pin output connectors. All inputs, line outs etc are still available as per 'standard' PDC-2.6P. List price is US$5,950.
3) The PDC3-50 is same as '1' above but with internal 500W linear PSU (also powering PDC) whose DC output is provided by two 4-pin Neutric female connectors (mute, -55V, OV, +55V) to power two external bi-amp modules that can be mounted on the rear of the speaker boxes. Each module contains two UcD400 AD version amp modules and additional local low Z capacitors (8,800uF). List price is US$7,950.
1) The PDC3 preamp processor. This has essentially the same internals as PDC2.6P but is 2U high with thick aluminum front panel and machined buttons etc. It also has blanked out cut-outs on the rear panel for the Dig out and the Bal out boards, so both can be installed together and can be upgraded in the field. There is a new all Jensen transformer balanced out board ($950) that is compatible with the existing one, so can also be used in PDC=2.6 models. List price of standard unit is US$4,450. Option prices for Bal out, dig out, and Earthworks mic are the same as for PDC-2.6 options.
2) The PDC3-300 is the same as above but with four internal Hypex UcD180'AD' version amps (for bi-amping) with 300W linear PSU that also powers the PDC board. Speakon 4-pin output connectors. All inputs, line outs etc are still available as per 'standard' PDC-2.6P. List price is US$5,950.
3) The PDC3-50 is same as '1' above but with internal 500W linear PSU (also powering PDC) whose DC output is provided by two 4-pin Neutric female connectors (mute, -55V, OV, +55V) to power two external bi-amp modules that can be mounted on the rear of the speaker boxes. Each module contains two UcD400 AD version amp modules and additional local low Z capacitors (8,800uF). List price is US$7,950.
Wingfeather said:
Can you help me better my knowledge here please? Could you provide as much detail as possible but also make it easy to understand for a casual reader.
What are the main charateristics of the noise floor and truncation errors with float vs. int? I assume float has a more spontaneous noise floor similar to analogue whilst int is near flat? Would you say int is more lossless(less processing errors) than float given the same conditions?
Your using 32bit to get 24bit resolution, what are the other 8bits used for? Are these used for the decimal?
Waves used dithering. I read a little about it and came to the conclusion that its effectively used to try and accurately truncate data without loosing information. I also assumed this was a big contributor to final quality. Can you outline the dithering method you use?
Thanks
I'll give it a shot - but please forgive me if I don't explain it very well!
(Warning to those with weak hearts: This is a long post. It's like really, really long)
Basically, when you have a digital audio stream and you want to process it, you end up with a result that contains more bits of precision that you started with.
-- Case in point: a biquad filter
A biquad filter has five coefficients that the audio is multiplied by as it passes through.
Let's say your input is called x[n] and your output is y[n].
y[n] = b0*x[n] + b1*x[n-1] + b2*x[n-2] - a1*y[n-1] - a2*y[n-2]
x[n-1] is the input from one sample ago, and x[n-2] is the input two samples ago, etc. Thus x[n] is your current input.
y[n-1] is the last output you had and y[n-2] is the output before that, etc. Thus y[n] is your current output.
The bit in bold is the calculation you need to do to produce your current output, y[n]. Now, you'll see that there are five multiplications in there. Each of these, by definition, will have a bit-depth equal to the sum of the bit depths of the two multiplicands.
So for the biquad I'm using, the audio is 32-bit and the coefficients are 32-bit. Thus, each of the multiplications will produce a 64-bit result.
These 64-bit results are all added together - it is possible that they could add up to something greater than what you can represent with 64-bits. This will cause overflow internally, which isn't something you want. But provided you follow rules for input scaling you can guarantee there will be no overflow.
So all is good.
-- But there is a problem
You've got your lovely 64-bit result, and you try and put it into y[n] - but y[n], like all your other numbers, is only 32-bits in size! The easiest thing to do - and what many are guilty of - is to simply throw away the 32 least-significant bits and call it a day. Or, at best, to round the number to the nearest 32-bits (this is basically the same in performance terms as chopping them off, but will at least not introduce the one-half bit of DC offset that chopping them off does).
-- We can do a lot better than that
In the 1980s (1984, I think it was) Stanley Lipshitz and John Vanderkooy wrote a seminal AES paper on a technique that can be used to maintain the information contained in these lower 32-bits even after you've chopped them off. The technique is called dithering.
The process is tricky to explain with words and it all comes down to what your maths is like, but in essence:
You chop off (or round) the 32-LSBs as you did before - but before you do, you add 2 LSBs peak-to-peak of TPDF white noise to your 64-bit result.
(Note that the "2 LSBs" is referring to LSBs after-truncation, and so the noise will be 32-bits peak-to-peak when you're adding it to your 64-bit result.)
Still with me? :s I tried several ways of wording that and can't come up with something I like.
--The overall effect:
Let's say you have a high-precision 64-bit result that has ended up being exactly halfway between the two nearest levels you can represent with 32-bits. If you were to truncate as normal, the output would end up on the lower of these two levels every time. If you were to round, it would end up on the higher one every time. In both cases, you have a full 1/2LSB of error for every input sample of this value.
Now, if you add the noise, it will mean that when you truncate (or round!) your number down to 32-bits, it will end up on the upper of the two 32-bit "quanta" half of the time, and it will end up on the lower of the two quanta the other half of the time. If you average the result over time what you get is an output which really kind've IS halfway in between the two possible 32-bit levels.
This is the essence of dither. On the face of it, you would think that the benefits would be rather small. But when you start taking measurements you can see how much of a leap in real-world performance that you get by using it.
-- Measurements
Consider you have a 16-bit output. We all know that the dynamic range of a 16-bit signal is somewhere around -96dB, right? Actually, not at all!
If you put in a high-precision sine wave that's quieter than -96dBFS - and you then truncate it to 16 bits - the sine wave will disappear entirely.
However, if you dither that sine wave to 16 bits then your sine wave can be of any amplitude at all and still be present in the output.
Using a 16k-point FFT the 16-bit noise floor spectrum appears as a flat line at around -135dBFS. If you use larger FFTs you're distributing the noise energy across more FFT bins and the level in each one goes down. Doubling the number of FFT points reduces this noise floor by 3dB.
If you have a sine wave that's truncated to 16-bits at 0dBFS what you'll see is a single vertical spike at the input frequency and a somewhat jagged noise floor at around -135dBFS everywhere else.
As you reduce the amplitude of the input, you notice two things:
- The noise floor changes shape - the "jaggies" shift around, and
- The noise floor changes in level (known as noise modulation)
The first point shows that the noise spectrum itself is actually correlated with the input, and will change periodically if you have a periodic input.
Noise modulation is particularly audible with very quiet inputs. If the amplitude if your input varies up and down slowly with time you can hear the noise "pumping" up and down along with it.
The noise modulation is taken to the extreme when your input reaches -96dBFS - then, it disappears entirely.
If you use dithering with this input signal, you sort out both of these problems:
- The noise spectrum is flat at all times, regardless of the input signal. It is completely decorrelated.
- The noise floor is constant in amplitude, regardless of the input signal.
What's quite beautiful is that if you dither, you can encode a -130dBFS sine wave into 16-bits with no problem - even though this sine wave is substantially less than 1LSB in size! A 16k-point FFT will show that perfectly. What's even more beautiful is that you can keep increasing the length of the FFT (and thus lowering your measured noise floor) and encode a sine wave of any amplitude into 16 bits. You have exchanged nasty signal-correlated quantization noise for a pure-white constant noise - what you end up with essentially an analogue system and infinite resolution. Yes, I said infinite.
-- The problem with floating-point
Floating point numbers have two parts - a mantissa and an exponent. They are akin to writing "1.6 x 10^-19". In this case, 1.6 would be the mantissa and -19 would be the exponent. This method of notation allows you get huge dynamic range from a certain number of bits.
32-bit floating point numbers have a 24-bit mantissa and an 8-bit exponent, and thus some 1536dB of dynamic range (in contrast to 32-bit integer which only has around 192dB).
The first problem with it is that it only has 24 bits of actual precision, since that is the size of the mantissa. This wouldn't necessarily be a problem on its own, if it weren't for the fact that floating point numbers are inherently unditherable. If you multiply a pair of 32-bit floats together what you are doing is multiplying the mantissae(?) and adding the exponents. This should leave you with 48-bits of mantissa to work with. However, this 48-bits is truncated back down to 24-bits in the multiply operation and there's no way you can get it back.
Moreover, if you could somehow magically retrieve this result and properly dither the mantissa back down to 24 bits, the effective amplitude of the dither noise would be scaled up by whatever value the exponent happens to be at that time, meaning of course that the noise floor is not constant and you get noise modulation anyway. This noise modulation would probably be quite chronic, too, since the amplitude of the noise could vary hugely.
The net result is that a single floating-point multiplication is akin to an integer truncation at the 24-bit level. This has all the problems of undithered truncation - bad linearity, noise modulation. Subsequent multiplications take this error and compound it. The problem then snowballs.
Now, add to this the fact that to make the convolution of long FIR filter kernels feasible you have to use an FFT-based system - this means a forward FFT, a set of multiplications and an inverse FFT. All the convolution/FIR filters I've seen do it this way (conversely, mine is direct-form)
If you were to do this with fixed-point (integer) arithmetic you'd end up with with a very slightly higher noise floor, due to the multiple dither stages. However, most people will do this in floating point format because it runs faster on the machine.
What you end up with is a huge load of compounding errors, and before long they will start to become audible.
There is simply no way of doing these types of calculations correctly with floating point numbers. People use them because PC CPUs are set up to work on them very quickly, and because their huge dynamic range means you don't have to worry about clipping them. but in all other respects, they are inferior.
Right, I'm done. I'm sure some errors have crept in there but I think I got the gist of it across.
*exhales*
Wingfeather, that was one superb post. Whilst the specifics are lost to me, the general method and the reasons why 'integer is better' were made crystal clear. I'm sure many others will be able to take some level of understanding from that post too.
I don't have much time right now but wanted to get a quick post in just to acknowledge and thank you. I'm thoroughly interested now and will be back tomorrow with questions and maybe you can find some time to help guide me through the setup.
Ant
I don't have much time right now but wanted to get a quick post in just to acknowledge and thank you. I'm thoroughly interested now and will be back tomorrow with questions and maybe you can find some time to help guide me through the setup.
Ant
- Status
- Not open for further replies.