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

stylus02

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.

[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

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.

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

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.

[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

I agree with Max. While it certainly is 'fun' to code a synth in kX DSP hardware
(been there, done that: http://www.hardwareheaven.com/effects-...nstrument.html)
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

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

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

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.

Lex Nahumury

Ah, ok as long as you just use c++/kxl for parameter calculation, microcode initialisation and GUI stuff you're gonna be fine.
Any real-time host->DSP stuff (as Max explained) is unpredictable.

Not sure what you mean, but audio processing in DSP hardware runs independant from host CPU utilization.
So moving a window should not affect it in any way.

It just needs recompiling for 3539.
Back then we had the '3538 abcdefghijlklm alphabet blues' so I got tired of recompiling just for 1 or 2 users.
Perhaps I'll remove it's KXGUI dependancy one day so I don't have to recompile that often. Same goes for my other synth-alike plugins.

Well, kx-automation is pretty slow.
I found it to be totaly unusable for tight MIDI playback in this context.
But if it works for you, ok.
BTW, if you like it that much, you can get rid of "midi transformator" and process incoming RAW kX midi automation
data directly in your C++ code to trigger the synth.

You can get 'Better'(faster) results by opening a MIDI input port through Windows Multimedia API directly in your C++ code.
Most tight MIDI playback results I ever achieved is by encapsulating the synth plugin as a VSTi.
That is; synth audio process runs entirely im microcode, but triggering is by VSTmidi events.
Still, the set_dsp_register is part of the MIDI timing problem too.
So MIDI timing is one of the problems you'll have to deal with, sooner or later.

I don't wish to argue but;
Just because the emu10kx is a more modern device then all the old synths you listed
doesn't automaticly make kX Driver+emu10kx capable of doing something it was never designed for.
Bottom line is; you will run into limitations you/we/I cannot solve.
Whereas with C/C++ you'll meet big challenges too, but most at least can be solved, fixed or workaround.

But again, don't let me spoil the fun.
I too had a lot of fun in coding my kX synth and still think it sounded great.
But I ported it to VSTi, it still sounds great, I now can use it on every PC/laptop
and all the limitation are gone.
(at the expense of some CPU cycles ofcourse)

Anyway; Good luck with the synth and keep us posted!

Cheers, /Lex.

PS: BTW, I totaly agree with you, making sounds with a 'self made' synthesizer is something special. Even if there are limitations!

zaboomafoo

Sorry for reactivating this old thread.

Does this mean that whatever is above 0db within DSP gets clipped down to 0db on the exit from DSP? Basically - have to make sure that everything going out from DSP does not go over 0db in the last stage or it will cause clipping?

And who is doing div4 / x4? is that done by SB card or by kxdriver?

And does that mean that we are loosing 2 bits of the original value when it enters DSP?

Regards,
Frank

Max M.

Yes, sure.

This depends on card's model and DSP config (for example k2 does this in fxbus/prolog/epilog while k1 does this somewhere else)

Yes, but take into acount that DSP is 32 bit and the ADC/DAC are 24 bit. E.g. you have 30 bit within DSP anyway. (and - well, not jumping into details - you never have this "original value" better then 30 bits)

[color=gray]
>Sorry for reactivating this old thread.

i had a pleasure to re-read it - nice thread.
[/color]

__________________

zaboomafoo

Thanks for the reply.

One more thing to consider. My understanding is that 0db (digital clipping) is considered as +12db in the outside (analog) world (according to some manuals I read).

That means that if output of the DSP is connected to a PA mixer, amp or any other analogue device, output from DSP should be kept at about -12db to avoid clipping in the analogue devices downstream.

Now another question: Is 0db coming out from an audigy card's digital output equal to 0db coming out from (or going into) another digital device?

This is all making me dizzy.

Regards,
Frank

Max M.

Not exactly, the analog output/input levels only depend on what "standard" device follows to - there're two common standards: consumer '-10dBV' and pro-audio '+4dBu'.
The pro-audio one is approximately 12dB higher than the consumer, probably this is the root of your reminiscence - but it no way means "that 0db (digital clipping) is considered as +12db in the outside (analog) world".
In anyway, if your card analog output causes a clipping on a mixer (watch the mixer meters!) - you should decrease the input level/gain on the mixer itself and not the output level of the card.

Yes, it is.

__________________