DSP Robotics Support

Post deleted as I have since learned different methods which supersede these interesting methods.

BTW, I used this method by using the de-zippers at 7 for 500Hz & beyond; But for the bands prior, to avoid more crackle; I used the same crossfade method I'd mentioned but employed Sam Mungal's (Sam Beans) Smoothers. They just use a lot of memory and using them from a0 - b2 is taxing.

Thankfully the default de-zippers are so well made, Just not so well made that they can counter the amount of data that bass can produce. Bass waves go on for miles while mid tones only a few yards


Here's basically how far sound can be heard to entertain the notion of rarefaction and complexity:

\\\\\\\\ 40 feet - 17khz
\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 2.5 miles - 100Hz
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\\\\\\\\\\\
\\\\\\\

Could you explain how exactly the Sound is getting fuller when a Multiplication instead of a Division is used? Sure it's faster so there is less risk of crackles, but a fuller Sound?

I think it must process a bit more sound. Multiplication requires no memory due to old Fortran framework;
But division also includes the functionality for linear algebra, calculus, rounding and division of complex function in a
conservative, independent sense; Therefore division takes longer to process. I would assume because the music
is already playing though cached to a degree that there's less propogation and re-iteration of the signal based upon bits.

Theoretically I'd assume that division serves as a dither and results in every other bit being dominant due to firmware limitations.
In the case of DSP code; It's just slower than C++; And seems much the same. However, in the case of DSP Code I like the speed, it's in between.

All theory; gather what you will. People often say bitwise; But how can they test definitively for milliseconds of milliseconds?
The scale just is not fine enough to be sure that one process is faster. I think speed has more to do with this phenomenon than
bitrate, or bitwise ideas (If the same size yet they take longer to process); There's probably a built in coping mechanism. Much like
quantize or maybe even slide that's flexible and gracefully compensates.

It's a shame because whoever made the original Synthmaker is obviously who touched the original fruity loops and it's a combination
of madness and unattainable complexity. It's very sad that it is not moving to VST3.
Funny that even now we're theorizing on how it was made.

Im sorry but this is all nonsense. The sound of a synth or an effect has nothing to with with multiplication or division. Its how well your filter or oscillator or whatever is coded. Lets say that the maximum volume is 1. You want to lower the volume of the oscillator, so you multiply it by 0.5. Then the output will be 0.5. Now if you divide by 2, you also get 0.5. So what you are saying that the the first 0.5 sounds better than the other 0.5...It makes no sense.

...

Umm....no?

If you have a ramp that goes from -0.5 to 0.5 and 0 to 1 then subtract 0.5, you just push the phase of it by half a cycle. There is no difference in sound quality, like the OP says.

here's a comparison of two stock eq's. The first one includes My multiplication fixes.
Notice that Mine has no distortion?

The stock one using division clips.

I'm glad We have the chance to debate over these things because the more developers that
understand the effect of mathematics on an emulation of fortran; The more semantically perfect Our
end product will be.

The only thing I notice though however is that maybe on the graphics end division might be better.
It's all about timing. I suppose eventually I could rewrite the stock eq so that it is smooth flowing and
has multiple bands and such.

It's quite a nice eq; Anything could be achieved with it; Especially with multiplication.
Try this example (works in fl studio's latest fl synthmaker/flowstone application).


Try these EQ's with various styles of music and sounds. It will become clear to You that the versions
using division crackle and the sound outputted is truncated and clipped .

There is no magic involved in maths!

I didn't think I needed to point that out. There is no magical switch of behaviour of a value depending on how you get to it.

Whatever you do in Flowstone, in the end there is a small buffer of values. This buffer is sent to the ASIO driver (or whatever else you use), and the driver sends it to the DAC. The DAC however only knows the current value. It has no history available for that value, that explains how it was achieved mathematically. It doesn't care if multiplication or division (etc.) is involved; 0.5 means 0.5. Always and ever.

I think you are mixing it up with inaccuracies that can happen during the process of calculating. That is due to the limits of the used data formats. A 32-bit-float ("single precision") is so limited in the amount of bits, that it isn't able to accurately display certain values. In such cases it passes the nearest value it can display. This happens with all kinds of operators, since it is data format dependend, not operation dependend. However, division is a more complex task for a processor than multiplication (it uses more cpu cycles), which increases the chance of such an inaccuracy, compared to multiplication.

The difference to what was claimed in this thread is, that the actual value is changed. Instead of 0.5 a 0.49999999989 might arrive at the DAC. And of course that makes a difference. Because it is not the correct value.

However, there is lots of literature about this topic (plus the topic of denormals, which come to existence due to the same restriction of the data format, and some solutions. They indeed have to do with the order of operations and the used operators, but again, this is a result of single precision floats, not of magic in maths!

...