feature request - accurate trig functions in blue

[tester]

Hey support - please add accurate trigonometric functions in "blue" version. sin, cos, tan, atan, and so on.

Green versions are accurate, but they not passing streams.

"In code" versions (not to mention the lack of atan) are based on approximations, and are useless for precise work.

And by the way - can't the smart components be switched between green and blue if they perform similar function? Can't you simply add a "checkbox" that indicates "accurate" (by default) vs "approximate" when it comes to things like trigonometric functions?

[support]

It is possible to do this in Ruby if you use the mono to frames and frames to Mono.

Here's an example of a sine wave generated in Ruby:

Ruby mono to frame sine example clip-2.png (105.27 KiB) Viewed 23377 times

[tester]

Dear support, the problem is also with performance of such functions.
Computers have limited speed

Ruby version would not be suitable neither to my research project that involves multiple generators (even with built in sine osc - I can't use all units at once) nor to my research projects that involves special modulated filters (blue approximation of green version - eats about 3x time of CPU, and ruby version would eat much much more I guess).

[MyCo]

ASM Workaround.

BTW: How many sines do you use, that it kills the CPU? On my system, I can do 2400 Sine calculations in SM and come only to 59% CPU usage... And this is my old PC, on my new one, I'll propably have 3 times more CPU Power

[tester]

In terms of "sine oscillator" - not too many, but I don't remember the detail now. Checking briefly - on my 2GHz unit (laptop), one core is full (and sound starts to break) at various 29 stereo sine outputs (built-in sine osc, SM not FS), so I guess c.a. 60 sine oscs can work at the same time together or a bit more if some of them would serve as modulators at lower frequency. If FS improved the performance, this should be a bit more. Performance is tricky - you get different readings if you feed all oscs with the same input data as far I remember.

In terms of trigonometric calculations - I don't know what to think:
http://synthmaker.co.uk/forum/viewtopic ... =90#p90873
...and this difference seems to be due to change the coeffs from green to blue; blue unit showed similar performance when all other modules (detuning related) were removed.

[MyCo]

In the "2Pole BP" Module you could use hop(128) around the whole code there, to calculate the coeffs only every 128 samples, instead of calculating it every sample. I've tested it, it reduces the the CPU usage down to 2/3.

There are also many other chances to optimize for a special case. Eg. the filter coeffizient b1 is always zero, so it could be removed from the filter code completely.

Converting everything to assembler, and doing further optimization there, would reduce the CPU usage by another 20-30%...

Just use your brain, or money

[tester]

Instead of my brain or money - can I use your help?

...or if you eager to get some of my music, you should say so on the beginning
It's like money, just in different form.

//edit:
indeed, removing b1 and adding hop(128) made that thing much faster.

[tester]

Answering to one of your questions - 280 sine oscillators on 2GHz (one core of D2D CPU), in which 32 are carriers (audible sounds), and the rest modulates variety of things Around that amount - app starts to crackle.

[infuzion]

ASM Workaround.

In the Tan, you have fstp twice per line; is there a reason for this please?

[MyCo]

ASM Workaround.

In the Tan, you have fstp twice per line; is there a reason for this please?

Yes. fptan opcode pushs its result on the stack and then it pushs "1"... so to get the right result you have to pop a dummy (which is always 1) and then pop the result.

BTW: I've made a mistake on the other SSE channels in the tan function. I've attached the fixed version.