log_dane, exp_dane in c++

stylus02 · Jan 11, 2008, 09:17 AM

hi all,

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

how do the c++ functions "log_dane", "exp_dane" have to be used correctly?
i have done following:

[COLOR=DimGray][COLOR=Navy] ...
case VOL3_ID:
[/COLOR][COLOR=Navy] // lin > log calculation from vfader value
[/COLOR][COLOR=Navy] set_dsp_register(VOL3_P, (dword)log_DANE(value, 2));
break;
...
create_vfader(level_3, VOL3_ID, "s", 0 , 0x7fffffff, 85, 10, 50, 100);
...
sprintf(c, "% .1f", v/10.); [/COLOR][COLOR=Navy]// shows float 0..1
[/COLOR][COLOR=Navy] ...[/COLOR]
[/COLOR]
when i dump the compilied kxl in dane only 0x0 and 0x1 are written in dsp register "vol3". where i am wrong?

thank you

kx it!

Russ · Jan 11, 2008, 09:33 AM

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 · Jan 11, 2008, 10:27 AM

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 · Jan 11, 2008, 10:46 AM

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 · Jan 11, 2008, 11:20 AM

Quote:

Originally Posted by stylus02

yes, i have noticed that: signals, which come out of a plugin, have a quadruple amplitude.

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 · Jan 11, 2008, 11:38 AM

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

Russ · Jan 11, 2008, 11:52 AM

Quote:

Originally Posted by stylus02

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

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 · Jan 11, 2008, 02:28 PM

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 · Jan 11, 2008, 04:02 PM

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 · Jan 11, 2008, 04:19 PM

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 · Jan 11, 2008, 04:41 PM

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 · Jan 11, 2008, 05:15 PM

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 · Jan 11, 2008, 07:20 PM

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 · Jan 11, 2008, 10:01 PM

Quote:

Originally Posted by stylus02

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 ..

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 · Jan 11, 2008, 10:07 PM

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)).

stylus02 · Jan 11, 2008, 11:18 PM

lex, this is exacly what i want - let do c++ some non- audio control calculations like trimming slider ranges or lin > log, exp conversion... to save limited resources on the dsp. the calculation range should be from fractional 0..1 or -1..1.

russ, i didn't noticed, that a 0x7fffffff in c++ is interpreted as integer, will try the double. in dane i had do not consider this. i will need some c++ revitalisation. nevertheless the x4 amplification is an interesting fact.

thank you guys

Max M. · Jan 12, 2008, 06:33 AM

[color=gray] and two cents from me. Actually i doubt if it makes any sense to really use these functions in C++ (since they are a very rough approximations). These functions are there more likely for reference only (e.g. for one to find out how their corresponding DSP instructions work). But for parameters/values calculation (and any math actually) in C++ - use "normal" C/C++ math functions e.g. log, exp, pow, tan, whatever.
See kx's plugins sources for examples.
[/color]

stylus02 · Jan 12, 2008, 07:13 AM

hi max,

i have spend a few hours to figure out what these 2 functions do in detail. now i think i do it with standard c++ expressions if i have a little bit more skill.
the gui elements hslider, vslider, checkbutton.. and so on are simple to use. not so simple as in the "dane" interpreter but enough at the moment.

thanks

Max M. · Jan 12, 2008, 09:17 AM

well, if you just need to convert linear 0..1 curve to some expontential/logarithmic curve (staying in same 0..1 range) you could do it something like
(very dumb code - just to show the idea):

Code:

#include <math.h>

double a_sort_of_log_or_exp(double value, double shape)
{
    return (exp(value * shape) - 1) / (exp(shape) - 1);
}
// where 'shape' defines the actual shape of the curve and could be any number (its reasonable range is somewhat like -10...+10)
// for example shape = 5.2 gives a curve similiar to dane's 'exp r, value, 0x7, 0'
// shape = 10.5 is close to 'exp r, value, 0xf, 0' and so on...

Although in real plug-in you'll find yourself using some more task oriented conversions (like linear gain to decibells and in reverse, freq to filter coefficients etc.)

stylus02 · Jan 12, 2008, 10:21 AM

looks usable - no linear interpolation as there is in hardware routines. i think c++ can do much help- processing for developing complex audioplugins like synthesizers.

Max M. · Jan 12, 2008, 10:39 AM

[color=gray]well... it can... considering there're thousands synthesizers written in C/C++ (VSTi for instance)

Btw., if Lex's guess is right and you're really moving an ADSR generator from DSP to host part - i'd like to warn you about one "little" obstacle.
A time it takes to call set_dsp_register function (or any other DSP read/write functions) is undefined. In general, it is reasonably smooth - but once it may take as long as a second, a minute or an hour. E.g. if you'll call it once per (let's say) 10ms - it will probably go fine, but if you'll try to run it faster it becomes really drifty.
It is not intended for such things (Actually the whole DSP<->Host I/O is not for real-time stuff)[/color]

Lex Nahumury · Jan 12, 2008, 12:21 PM

I agree with Max. While it certainly is 'fun' to code a synth in kX DSP hardware
(been there, done that: NEW:'Analog' Synth (DSP-instrument))
you will run inevitable into a few nasty limitations that probably render
your synth beeing a 'nice experimental toy'.
IMO it's better to code the entire synth in C/C++ VST right away than wasting time/effort realizing one in kx dsp.
Just some friendly advise, not meaning to spoil your fun or anything ofcourse.

Cheers, /Lex

stylus02 · Jan 12, 2008, 12:25 PM

no, i don't want replace the completely envelope. mainly sliders and perhaps the log instruction, wich converts linear counter values for tracing the envelope in realtime.
i know that there is something like interuption in audiostream when moving a window or other tasks happen. this could be a problem in realtime signal generation. so far i thought my exotic slow computer (dual p2 333) could be the reason for that.

stylus02 · Jan 12, 2008, 12:39 PM

lex, i never could install your minimoog clone. was there a driver version conflict? my synthesizer will be a modular one. some modules are written. biggest problems are solved. the midi implementation has to work out. actually it can be played by using a the software "midi transformator" which does some midi precalculation to match kx- automation. not the smartest methode but it works.

stylus02 · Jan 12, 2008, 01:34 PM

lex, i'm a big fan of old synthesizers moog, oberheim, korg, sequential and so on and its developers. beside me is a nordlead 1, a ms 404 and a jv 1080 but making sounds with an own synthesizer is something special.
of course programming a synthesizer is an experimental task on a system like kx. but remember the problems developers and musicans had with these old analog or first digital systems: voice instability, defect electronical components, slow processors, low audio resolution...
here we can say the emu dsp and the kx driver are doing a good job for making samples or playing monotimbral, monophonic voice with very high quality audio resolution. i see more the advantages than the disadvantages and.. if the kx driver would be not usable it never had reached this level.