Effect Hunters

Eugene Gavrilov

hi there

it's been a while since our users have started to write their own DSP effects -- most of them can be found on our forum -- some are in 'source' form (.Da), some are in DLLs (KXLs)

I decided to collect all the currently available 'third-party' effects and integrate them into the next driver release (in order to facilitate their usage by 'regular' users which don't want to bother with .DA / .KXL stuff...)

in order to do that I apply to effect authors to provide me with the very recent effect versions and their source code (for KXL part)

please post links to your effects to this topic

/Eugene

eyagos

Ok. I can send the AGC, WAVEGENERATOR and APS-COMPRESSOR/EXPANDER sources, with optimized da's.

Just a few days.

Eugene Gavrilov

ok, a good start

[attn: LM] what about Leslie and rotary/b3 scanner stuff?..

/Eugene

Nappylady

I find I am no good at coding for this thing Can we see if we can reverse-engineer the reverb from the Creative drivers? I really miss the huge, cathedral-the-size-of-the-moon reverbs that were possible with that one.

Lex Nahumury

Eugene, Max,

When I first started posting here, I thought this section of the board was for DSP coders/development mainly.
A place where ppl would activly Learn, Write, Publish and Discuss DSP code.
I guess I was totaly wrong in that assumption.
This section is 'dead' for coders!
No one ,except a few, publishes usefull DSP code here.
(Look at the nr. of relevant replies to this thread were Eugene 'hunts' for coders)
Instead, this section is flooded with all kinds of Kx-users that dont even bother to code.

Shouldn't this be 'the' place were Kx-coders interact with each other?
Or are we all working on our own small islands?
And why is Max.M the only available DSP Guru around here?
E.g. I dont see (any other) UFX coders posting here! (apparently for good reasons)

Anyway;
I feel I'm at the wrong place here so I removed all my previous posts/code etc from this board. (No one will miss them anyway)

If I finished coding something worthwhile I'll mail it to you guys rather then posting it on this 'dead' forum section.

Max, Eugene;
Thanks again for the 'jump start' on coding.
Untill better times...


Regards,

/LeMury

Max M.

Thanks, LeMury, for the clearing that up... I see, noone except me can understand you better... I see.. of course - just do what you feel you should to... this is the thing we are here for... thanks again...

Eugene Gavrilov

hello LeMury!

>> When I first started posting here, I thought this section of the board was for DSP coders/development mainly

it was supposed for
however, the problem is not with this section, but with the amount of DSP coders...
currently, there are too few of them

>> And why is Max.M the only available DSP Guru around here

well, probably because he is the author of most DSP effects
I usually implement very simple effects (mixes, volumes) and low-level stuff (as well as prolog/epilog/routing)
(and also sometimes deal with LiveWare effects)
Hanz Petrov is responsible for porting E-mu APS effects to kX (that is, he writes a DLL part and parameter calculation code)
Soeren has written practically all the EQ effects (except Eq10 and Timbre)
eYagos is also a 'known DSP coder'
that's it

>> UFX

if you mean 'uniform plugins' -- this is Max M.'s own interface which isn't available for the developers at the moment
even I have never seen his sources

>> I feel I'm at the wrong place here so I removed all my previous posts/code etc from this board. (No one will miss them
>> anyway)

well, I think it was not a very good idea -- I was just about to 'cut & paste' them for further investigation and integration into kX distribution...
(sorry, sometimes I cannot respond quicker)

>> If I finished coding something worthwhile I'll mail it to you guys

that would be great!

>> Thanks again for the 'jump start' on coding.

you are welcome. feel free to ask any questions (by mail or by posting them here)

>> Untill better times...

I'm sure they'll come

/Eugene

Lex Nahumury

Hello Eugene, Max,

Thanks for the replies.

Of course I know Max's role as well as yours, Hanz Petrov, Soeren.B, UFX etc.
(One just has to take a look at the SDK and see who did what)
You guys are the 'core' of Kx and have done enough already.
I deliberatly mentioned that to state my case wich is:

There SHOULD be more NEW ACTIVE dsp coders on THIS forum section!

Taken the nr. of Kx users in account, it's statisticly unbelievable and ,to me, unacceptable
that there are not at least 10 new active DSP coders publishing here on this section the way I did.
Novice, skilled or total beginners, I dont care, as long as there are active.

You guys provided a great DSP IDE and a well documented SDK.
Compared to the complexity you had to deal with in oder to bring KX to Life,
writing DSP code now is almost a 'no-brainer'! ( I said.. ALMOST)

Surely I'm not expecting every Kx user to start learning DSP code.
Of course not....But 10 out of ~1000?
COME ON KX USERS..!!!!!!

Oh well, nuff said on this matter. Time will tell.


Anyway; Eugene, Max,
1. I will gather, re-document my deleted code and send them to you.
(may take some time) Use whatever you may find usefull.

2. I think I settle for a 'light' version of the Rotary.
The more complex version does not justify the extra resources needed
i.e. the gain in effect over the 'light' version is very small.

3. The distibuted Kx Chorus (not the St Chorus) does not work.
It's lfo modfreq is not properly dll-ed. In fact its source.cpp is missing in the
SDK, and in da_chorus.cpp the controls are not defined.
Also; both Chorus and St Chorus code waists quite a bit unused itram as I see it.
I was in the process to re-write/fix them for my own use.
Let me know if you are interested. It might save you guys some work.


At last;
I will not hesitate to ask any questions. Thanks for this offer btw.
Know that I am always willing to help or contribute within the range of my skills.


Best Regards,

/LeMury

Eugene Gavrilov

>> The distibuted Kx Chorus (not the St Chorus) does not work.
>> It's lfo modfreq is not properly dll-ed. In fact its source.cpp is missing in the
>> SDK

probably, you are right
the Chorus you are speaking was written -before- the actual SDK was even created
there was no plugin architecture at all...
so, now it seems to be outdated

>> Also; both Chorus and St Chorus code waists quite a bit unused itram as I see it.
>> I was in the process to re-write/fix them for my own use.
>> Let me know if you are interested. It might save you guys some work.

that would be nice

/Eugene

Nappylady

If we're in here requesting things...

can we have a 1/3-octave graphic EQ? My soundsystem needs one...

Thanks!

Lex Nahumury

Ehhhhh....Sorry Nappylady,..I think you don not understand the topic of this thread.
This thread is about people who DO write dsp code!

No one (except you) has requested here anything.

We are NOT 'in here' to request things, but to DO things!

So if you want your EQ, you are more then welcome to start coding it yourself.
I'm sure you will get help once you start coding.


Please post requests in another thread if you don't want to code it yourself.

/LeMury

Juraaas

Hi, I would like to start write some DSP codes, but I need to learn it, where should I start?

Lex Nahumury

Hi,

The quickest way is to use the 'Dane Assembler/Dissasembler' (already integrated in your Kx driver)
and reverse-engineer some existing dsp effect.
Open the DSP window, add a simple dsp effect like a Mixer, right click on it, select 'dump' or 'edit',
and examine/study it's dsp code.
Use the 'kX Dane Assembler guide' to learn the instruction set and syntax.
Then try to write some simple Dane code yourself like a mixer or something.
Just experiment. You can't break anything..

Well documented Kx Dane source code makes learning much easier.
Unfortunatly, they are few and hard to find.
I have published some docu-ed code on this forum as have some other ppl.
But you can always ask for help and advise. That is what this forum section is for. (amongst other things)
So don't hesitate to do so.


Reading stuff;

-kX Dane Assembler guide.
You can find this in the Kx Help menu. (right click on the Kx logo in the systray)

-The "As10k1 Manual" written by Daniel Bertrand:
http://emu10k1.sourceforge.net/as10k1-manual/

-search the doc's section on Kx homepage:
http://kxproject.spb.ru/docs.php?language=en

-If you have some C++ knowledge you can also study the Kx SDK sources.
To actually use the SDK you need Visual Studio 6.0.

These are the Kx DSP related docs I know of. (I probably forgot some..)

Further; there are tons of DSP source code, algoritmes and resources etc. on the net.
Mostly written in C++ so you have to 'port'/'translate' them to the Kx platform.
Not really for 'starters' but nevertheless very usefull.

I hope this helped a bit. Other suggestions are welcome.
Again; Feel free to ask questions.

Regards,

/LeMury

kokoon

ok, im willing to prog some things too. dont have much asm experience yet though. but before i start, my question is: would it be possible to implement a timestrecher (pitchsifting portion, i know, is possible) - is there a way to store some audio for realtime timestreching? anyone knows what i mean?

Lex Nahumury

In general, Time Stretch effect is; Changing the length of a signal without changing it's pitch.
I.e. changing tempo/bpm but with the same pitch.
Is that what you mean?

/LeMury

kokoon

yes. basicallay its the same thing as just pitchshifting, only the playback rate changes too. but its clear that if you want to slow down a signal, you have to have a backing buffer.

kokoon

look, people.

i have found some nice resources:

http://musicdsp.org
-a site with many many effect, filter, synthesis and analysis algorithms/codes.

http://www.dspdimension.com
-mostly dedicated to pitch scaling. contains a very nice tutorial on building a pitch scaler.

will dig for more :>

i hope to start coding soon.
what im really after is a granular resynthesizer.

Lex Nahumury

(Lol..Kokoon,....I was just about to post the same URL's...hehe)

Nice job!

Btw,..buffers can be made in Tram or 'static' GPRs.

Seems that what you want to code is close to Vocoder algo stuff.
Eyagos has wrote that one. I'm sure he can help.

Also; take a look at APS Pitchshifter code. It maybe usefull to you.

/LM

Correction: Eyagos wrote the Ring Modulator!
The Vocoder was written by someone else.
(Sorry, ...my fault)

kokoon

well...

here's the thing: i will probably be implementing 2 different effects:
1. granulator resynth (thats what i always wanted plus i think it is possible - not too dsp expensive)
2. pitch/time scale effect

for the second one i want to use Time Domain Harmonic Scaling (TDHS) or maybe this newly discovered Pointer Interval Controlled OverLap and Add (PICOLA) algorithm instead of Short Time Fourier Transform (STFT), which is used in the common time/pitch stretching method called Phase Vocoder, which, i think, APS Pitch effect uses.

but note that for now i have no real idea about what im talking about. the algos im talkin about could be way way beyond the EMU10kX abilities. also i have only limited knowledge about audio, calculus and algebra.

if there are any volunteers that have done stuff before and think they can participate, ... well, please

Eugene Gavrilov

I'm afraid that time-stretching effect cannot be implemented because the plugins cannot control incoming audio speed...
(at least, at the moment. it is theoretically possible to make the directsound applications think the audio stream is played back quicker... but the DSP plugins deal with DSP data and cannot access / control the separate incoming audio sources)

even using large buffers won't solve the problem until the audio speed is modified accordingly

/E

kokoon

awwww thats really bad news. but why do you say large buffers wont solve this proble?

Duke_srg

As for time scale:
1. You can't speed up input signal, because input data incoming with fixed rate.
2. You can slow down input signal only for a fixed period if time, which depends on buffer length and slow down amount. Otherwise buffer will simply owerflows.
Is it clear now?

kokoon

no, its not clear:
1. the buffer can help you with that. you just delay the entire stream for the buffer length and make it quasi-realtime. now you can virtually speed up input signal. (yes, for a fixed period of time)
2. thats what i meant.

so the buffer is used for both speeding up and slowing down, depending on what you choose.

another thing: if you start fresh on stream with "slowing down", then you can fill the buffer while playing at lower speed. and when the buffer is full then you can speed up to normal speed (not clearing the buffer). because the buffer is full now, you can use it to speed up the stream.

apparently this is the only way to realize real-time speed manipulation on fixed streams.

the only question now is - how big buffers can i get?

Lex Nahumury

Hi Kokoon,

>another thing: if you start fresh on stream with "slowing down", then you can fill the buffer
>while playing at lower speed. and when the buffer is full then you can speed up to normal speed (not
>clearing the buffer). because the buffer is full now, you can use it to speed up the stream.

Apart from the actual implementation, let's assume you manage to do the above.
While you are busy filling the buffer, reading it back at another speed not clearing the buffer etc,
new data keeps coming in. So you will simply loose that data no matter how big buffers you have.

As I see it, you will only be able to 'catch' a chunk of data equal to the size of the buffer.
By the time you have finished proccesing that chunk, new data has been lost.

Unless this is what you want/need as the basis for an effect,
I'm afraid that time-stretching a continues data stream
without interruption in real time is currently not possible.

Feel free to correct me if i'm wrong.

Regards,

/LeMury

kokoon

ok, ill try hard to explain, but note that english isnt my native language.

imagine you have a continues, fixed flow of a fluid, trickling vertically. drop by drop. below, under the source of this trickling stream, there's a sink (opposite of source - this is where we recieve the data). now there's no loss of data (drops of fluid), right?

now we build a special storage glass/cup to be put later between the source and the sink:
we take a pipe/a glass without its bottom/something that can store a certain amount of fluid if we cover the bottom hole. we cover the bottom hole with a valve. a simple valve that can be regulated to "leak" faster or slower (or not leaking at all).

now we put this special "glass" in the middle of our trickling stream.
1. if the valve is - lets say - 50% open, then the drops fall into the glass and the partly closed valve forms the drops again, with the same frequency (rate).
2. if the valve is less than 50% open, then the drops fall into the glass, the valve forms drops again, but with lower frequency (rate). because of that, the glass starts to fill. but there you have a simple mechanism, that simply opens the valve to the 50% when the glass is full. this way, no drop owerflows, meaning no drops are lost. and we have a full glass. now we can leave it this way, or we can afford to...
3. open the valve more than 50%. until the glass is empty, the valve open for more than 50% can form drops at a frequency higher than of the incoming drops. when its empty, the drops will simply "drop through" the valve (if its still open more than 50%)

the glass = the buffer
trickling stream = audio stream
a drop = a unit of audio data (a sample)
the valve = the speed control

im sorry if this explanations seems trivial. maybe im missing something else that you see.
yes, the effect would be completely limited with the glass size (buffer length) and to start any "speeding up" manipulation, we had to start the "slowing down" first, for buffer to fill. but still i think it would be a useful thing (a toy, at least).

techically, the buffers are no glasses, meaning the data just sits there, not moving toward the exit. but im sure a FIFO queue system without priority control can be implemented on a fixed buffer (no copying ofcourse). i guess a common way to implement this is to write and read "circulary" (wrap ends).

how big buffer can i get? this is really important, cause if its less than, lets say, 5 seconds, then its probably useless.

thanks for looking into this thing for me.

Eugene Gavrilov

perhaps if we consider all the limitations you mention, such effect is possible
however, it is very difficult to use the external TRAM f