stylus02

hi all,

to save some registers and instructions, i'm interested in c++ implementation of the microcode.

Russ

Try this:
set_dsp_register(VOL3_P, _dbl_to_dspword(log_DANE(value, 2)));

BTW: Signals entering the DSP are divided by 4 (and multiplied by 4 when leaving), so any level detection code, etc, should take that into account.

... and welcome to the forum

stylus02

thank you russ. the _dbl_to_dspword conversion seems to work. i will take a closer look later to what it does exactly.
yes, i have noticed that: signals, which come out of a plugin, have a quadruple amplitude.

Russ

It basically just converts the value (which is a double) to the 2's compliment version (i.e. fractional value), rounded to the nearest integer (IIRC).

i.e.
value * 2^31 + 0.5 (truncated at decimal point)

Russ

Yes, the peak plugins are designed so that regular users do not have to think about the div4/x4 stuff, and thus they show the level as it will be after leaving the DSP (so the value on the peak plugin will be 4 times the value shown in the plugin's register(s)). The controls for most plugins are like this as well (when applicable).

stylus02

it can be handled, when it's known. to show signals on software oscilloscopes they have to scaled down to 25%.

Russ

No, they should not have to be scaled down since the peak plugin shows what the level should be in the recording application (i.e. what it will be when it leaves the DSP)... unless of course another plugin changes the level before that point.

i.e.
original level -> Div4 (entering the DSP) -> x4 (exiting the DSP (to recording software or whatever)) = original level again

The only difference is that DSP plugins (in the middle) work with the div4 level (gives overhead room for plugin calculations, etc), but this should be pretty much transparent for regular users (i.e. you only need to know about it if you are creating plugins that use level detection, etc (or you are using a plugin that does not account for it)).

<edit>
Sorry if I confused you... I mainly mentioned it because I thought that you might be doing level detection (or similair), as Log/Exp can be used for that (i.e. to convert linear values to log scale (and vice-versa) for dB comparison, etc).
</edit>

stylus02

no you don't confuse me. only c++ is able to do this .

when i'm checking the signal with the software osciloscope "oscilight" i have to scale down the plugin output level from 100% to 25%. when i do not, the osci shows only the first quarter of the signal amplitude. it looks like "hard cutted" at -0.25..0.25. really don't know if the software has a problem with 32 bit input data or it is the phaenomenon you described. but it can be solved as described above.

i actually work on a synthesizer and i would like to optimize an adsr envelope and something else i've written in microcode.

kx it!

stylus02

have tested some linear > log, linear > exp conversions with following c++ code:

set_dsp_register(VOL3_P, _dbl_to_dspword(log_DANE(value, 6)));
set_dsp_register(VOL3_P, _dbl_to_dspword(exp_DANE(value, 6)));

there are 2 tests for every instruction, one linear rampup an one linear rampdown.

here the results of the plugin outs viewed on and oscilloscope :

http://freenet-homepage.de/stylish-s...ane_0_to_1.jpg
http://freenet-homepage.de/stylish-s...ane_1_to_0.jpg
http://freenet-homepage.de/stylish-s...ane_0_to_1.jpg
http://freenet-homepage.de/stylish-s...ane_1_to_0.jpg

as you can see there are dropouts with nearly 0 or 1 values.
there must be a problem in functions. i have seen that eYagos's dynamica uses a
similarly interpolating version of such function.

ok this is very high skill level. i'm not that c++ professional at the moment.

Russ

Make sure that you account for the x4...

i.e.

What are you ramping up/down?
- Make sure the signal's range (in the DSP) is 0 to 0.25. If this is an external signal, then it is done automatically for you, but if it is a signal that you are creating in the DSP then you need to scale it's range yourself.

stylus02

ramp or saw waves, as we musicans say, are simple linear rise up or fall down functions like this f(x)=(-)ax.
no i think the smaller range is also concerned of the problem.
the picture's names tell what i have done. i have moved the slider constantly up from 0..1 and down from 1..0. the conversion is the c++ method right out the kxl.

stylus02

the log-, exp- curves are recognizably. but the dropouts's are absolutely not acceptable. if i would put such an envelope to a sound, it would scratch like an old record player. *g*

Russ

I am sorry but I still am not completely sure what you are using these instructions for (why not just use a logarithmic slider to being with?). I only know that you are setting DSP registers to converted linear slider values. I do not know what else you are doing in your C++ code, nor how these values are being used in your microcode.

Also, if you are going to use a slider for musical purposes, you should probably interpolate between value changes (in your microcode) as the resolution of the slider is probably not good enough for smooth results (depending on what you are using it for).

Lex Nahumury

Control signals generated in DSP like ADSR envelope generators, LFOs etc. often go from 0 to 1.
That is why they are clipping at DSP output due to 4x and that's why you have to temporarly scale them down in order to observe them in software osciliscope.
Audio signals on the other hand, traveling through DSP should always be kept below 'virtual kX DSP 0dB point' else they will clipp at the DSP output too.
The digital oscilators used in your Synth is audio signal!
Their peak amplitude must not exceed 'virtual kX DSP 0dB point' else they will clip too.
So there is nothing 'strange' going on here.
Just the difference between control signals and audio signals used in DSP.

@Russ; My guess is we are looking at a Control signal ramping up/down between 0-1
and that the OP is experimenting trying to move ADSR from microcode to C++ (wich is very tricky) to save DSP resources.

/Lex.

Russ

Doh, I know what the problem is...

Your slider range is KX_FXPARAM_LEVEL which is integer values, and log_DANE expects a double (-1..1). Divide the slider value by 2^31.

i.e.
set_dsp_register(VOL3_P, _dbl_to_dspword(log_DANE(value / 2147483648.0, 2)));

Sorry, between your description of the problem, and your pictures, and everything else, I wasn't completely following what you were saying.

<edit>
Didn't see Lex's reply... Yes, I think you are right that it is the control signal (I had thought this originally, but the pictures threw me off with all the ups and downs, and I got confused (I did not realize that is what he meant by dropouts... and then I thought it was some odd signal that was being ramped)).