looking for a kx delay plugin...

dungle · Sep 13, 2003, 09:27 PM

hi,
does anyone know of a kx dsp pluggin to do the following? (very common requirement...)
1. Delay time (say 10mS..1.0 Sec, reasonable resolution)
2. Wet/Dry mix (0..100%)
3. Feedback
thanks for any pointers

Lex Nahumury · Sep 14, 2003, 01:01 AM

Doesn't the standard included Delay work for you?
If not, please specify why?

I could code one for you. (well,..maybe,..if I have some time left)

/LeMury

P.S.
I can't remember, but doesn't Max. M's UFX package contain a delay?

dungle · Sep 14, 2003, 06:27 AM

thanks for the reply.
No, the delay time slider does not work properly. It has poor resolution of delay time and the relationship between slider position and delay time is bazaar!

Wet/dry only goes to 50% also.
Thanks for the pointer to Max's UFX which I shall now locate...

dungle · Sep 14, 2003, 06:46 AM

I've loaded and installed Max's UFX (which looks great) but alas, no delay, it would seem

TheKezmiester · Sep 14, 2003, 07:47 AM

ohhhh.... How long I've been waiting for a delay that works! I'd try it myself If I thought I could but alas, the last time I coded anything on was an Amiga 500

Just a couple of suggestions if your thinking about coding a delay plugin...

1. Could the dll display the delay time in ms?
2. It would be awesome to have a like a 'feedback out' and 'feedback in' (with a corisponding switch to enable them) so that we could insert one of the filters into the feedback loop for old style tape delay or other cool delay effects.
3. Stereo ping pong?
4. This is becoming wishful thinking now but in an ideal world you could swithc the time slider between milliseconds mode and tempo (bpm) mode where a second slider or knob becomes active with 1/2, 1/4 1/8 ect.

Seems like it's one of the olny things left that APS and Creative drives still have but kx dosen't is a decent delay plugin

Like I said, I'd love to tackle this myself but altough I've had some success with the kx assembler, I've never even looked at C++ before and besides, I corrupted my bios months ago so I'm pc-less atm anyway.

...btw, new motherboard next week..... Brushed skin will return!!

RIV@NVX · Sep 14, 2003, 01:11 PM

Quote:

Originally posted by TheKezmiester
...btw, new motherboard next week..... Brushed skin will return!!

Can't wait!!! Great news!

dungle · Sep 14, 2003, 03:46 PM

Kez,
your specification is most excellent.
To eager coders, here is a project that will be greatly appreciated by many kx'ers I'm sure

5th element · Sep 14, 2003, 08:24 PM

Id like this too for time aligning tweeters.

Lex Nahumury · Sep 14, 2003, 10:09 PM

Quote:

Originally posted by TheKezmiester
Just a couple of suggestions if your thinking about coding a delay plugin...

1. Could the dll display the delay time in ms?

-Yes.

2. It would be awesome to have a like a 'feedback out' and 'feedback in' (with a corisponding switch to enable them) so that we could insert one of the filters into the feedback loop for old style tape delay or other cool delay effects.

-Yes. ( if you mean the possability of 'switching' between 'internal' and 'External' Feedback routing)

3. Stereo ping pong?

-Possible, but takes an 'synced' LFO to ping/pong....(hmmm have to think some more about that)
-Btw; are we talking about a ' Mono In -> Stereo Out' delay? Or stereo-> stereo?

4. This is becoming wishful thinking now but in an ideal world you could swithc the time slider between milliseconds mode and tempo (bpm) mode where a second slider or knob becomes active with 1/2, 1/4 1/8 ect.

- I'm not sure what you mean. Do you mean only switching from msec display to BPM display?
- I.e. the actual Slider position keeps producing the same delaytime regardless of 'Display mode?

Further;

-I guess it's desirable to change DelayTime in Real Time during performance right?
If so it gets a little more complicated, because I have to 'smooth' the delaytime changes
to avoid horrible clicks. ( Can be done, but I'm afraid you may still hear some zipper noise)

-Another issue;
Let's say we make a delay from 10ms to 1 sec, (1 sec should be more then enough),
then 1 step of the slider gives an increase of ~10ms if a linear slider scaling is used.
From 20ms to 40ms is a 'huge' step compared to 900ms to 910ms.
Keep this in mind.

/LeMury

Lex Nahumury · Sep 14, 2003, 10:21 PM

Quote:

Originally posted by dungle
To eager coders, here is a project that will be greatly appreciated by many kx'ers I'm sure

No doubt.
Unfortunatly, there are not much 'eager' coders (or any coders for that matter) around here as you may have noticed.

If no one else 'jumps' on this one, I'm willing to code it.
I can not say when, since I have a lot of other Kx projects to finish first.

/Lemury

Lex Nahumury · Sep 14, 2003, 10:35 PM

Quote:

Originally posted by 5th element
Id like this too for time aligning tweeters.

For that purpose I propose a 'dedicated' delay instead of one meant for 'musical effects'.
I.e. no feedback, and no 'smooting' (gives a Lowpass effect).

In fact this is much simpler to code.

-What is the maximum delaytime you need?
Probably not seconds, Right?

-Do you need mono or stereo delays?
I guess mono or better; one DSP plugin with several independent mono delay lines + level controls.

/LeMury

Daniel Drummond · Sep 14, 2003, 10:51 PM

LeMury has definitely achieved KX god status.... He should receive a promotion in the "alias" under his name... Way to go!

dungle · Sep 15, 2003, 01:18 AM

I'll put my suggestion for the way some features might work....

Ping-pong may be simply implemented by an additional delayed signal routed to the opposite channel.
here's an example:
1)signal in
2)200mS delay,with f/back->right out
3)100mS delay, no f/back -> left out

note that (3) gets its input from (2) not (1)

If the delay times are specified in BPM and integer beat multiples/fractions, this is probably the most useful for musical applications. A mS control (not quantized) could be used as well and whichever is adjusted would be active.

I suppose if the user wants nothing in the feedback path they can patch the f/back-out to f/back-in with a virtual cable.

5th element · Sep 15, 2003, 08:12 AM

Time delay for aligning a tweeter would be really simple. The only thing it would need is the alteration of the time delay and none of these feedback things. I would want the signal to remain intact but just delayed by a few ms. I would guess that the max required would be about 10ms with fine increments available for adjustment. Say from 3.1 to 3.2ms.

Maybe this would require another plugin other then the one thats been described, but the smoothing thing to eliminate clicks would also not be of importance. Yes it would be another feature to add to the list that would make a product more desireable but in real life it would have no real extra bonus.

Hope that helps Matt

P.S. If anyone could point me in the direction of somewhere that can tell me how to start coding these things it'd be much appreciated.

BiCho · Sep 15, 2003, 10:15 AM

Quote:

Originally posted by TheKezmiester
4. This is becoming wishful thinking now but in an ideal world you could swithc the time slider between milliseconds mode and tempo (bpm) mode where a second slider or knob becomes active with 1/2, 1/4 1/8 ect.

Ideally the sequencer would send BPM information to the plugin, but i think that's a VST 2.0 implementation, not Kx's

Anyway, there must be a way for Kx to interpret MIDI clock information, in this way, the delay could read the current BPM and be perfectly in sync with your music. a dream come true

what about a filter just before the feedback chain? in that way you could have an ever changing delay! be careful with the resonance value though...

i'm just a musician/dj/producer working in latin america and working for Native Instruments too. don't know anything 'bout coding nor programming though

thanks for the drivers!!! a dream come true!

best regards
BiCho

dungle · Sep 15, 2003, 07:59 PM

5thelement,
There are sample sources of simple delays if you need a fixed delay for your speaker alignment then locate these sources (in this forum) which you can modify. Your requirement is so simple that I'm sure someone else will have suggestions also.
BiCho,
Automatic BPM detection via VST is great but the suggestion here is simply a calibrated selector so the user can dial up a specific BPM/beat time for the delay. The BPM/beat could then be automated in VST using KX Automation.
In fact adding VST BPM tempo information gathering capability to KX Automation would allow any plugin to operate in relation to current tempo/timesignature.
regards

TheKezmiester · Sep 16, 2003, 04:11 PM

Ohhh... I'm getting excited..... but let's not go overboard.

1. The delay time really should not have to be changed during a song or performance, I mean it could be usefull and might be nice but we don't need huge resource monsters here.

2. It might be wise to have 3 seperate plugins. Long Delay (500-1000ms) Short Delay (100-500) and Sample Delay (0-100...or less for the speaker placment stuff ect). this would refine slider resolution and reserve itram or whatever resources it uses when not needed.

3.
>. This is becoming wishful thinking now but in an ideal world you could swithc the time slider between milliseconds mode and tempo (bpm) mode where a second slider or knob becomes active with 1/2, 1/4 1/8 ect.

>. Do you mean only switching from msec display to BPM display? - Yes
> the actual Slider position keeps producing the same delaytime regardless of 'Display mode? - Yes

But a second slider with multiples of the bmp ie. 1/4 1/3 ect would be inactive or redundant when in ms mode. See most common vst delay plugins for examples.

4. Automatic BPM detection is really not needed at all. All we need to do is once we've decided what bmp our song is at, at the start of our song, we insert a midi controller message (at the very first bar of the song) with the channel set to 'Kx control' port or the kx vst plugin that set's the delay time then your set for the rest of the song.
This method can be used to set up all your kx plugins so that when u load a song in your sequencer, as soon as you press play, your effect settings are restored to that specific song. This is very easy to do... if anyone needs me to explain this process further just say so

...perhaps one day we could send a midi message to the drivers to load a whole dsp setup!!!! The drivers could recognise if it's the same settings file being loaded again and only load it the first time (So it's not loaded everytime you press play).

Lemury.. you definatley should be raised to god status for your contributions here.
... and yes.. I'll do my bit (the only thing I know how) and you'll have a new brushed skin soon.

Lex Nahumury · Sep 17, 2003, 02:57 AM

Ok guys,

I'll stick to Kez's and Dungle's specs as a design goal.
When I start coding I'll probably make some basic test versions firts
before going deep into the time consuming fancy GUI (dll) part.
I will then post them here for feedback/testing.

Again,..no promises as to when I start. (it's getting quite busy..

)

5thelement;
In this thread I have posted a documented delay line implementation:
Strange chorus (code inside)
Although it's a lfo modulated delay you can derive usefull info from it.
Also, take a look at Max. M's 'Dane assembler guide'.
In your case the dsp code is fairly "simple", but you will also need a dll extension
for the msec GUI stuff. (See Kx SDK)

/LeMury

TheKezmiester · Sep 17, 2003, 07:16 AM

ooops.. Somehow I missed your last message dungle.

> In fact adding VST BPM tempo information gathering capability to KX Automation would allow any plugin to operate in relation to current tempo/timesignature.

I see what your saying.... if VSTIs can get the tempo directly from the sequencer then why can't the kx VSTI do the same thing and pass that on to the plugins via kx automation?? Briliant!!

Max M. · Sep 17, 2003, 05:47 PM

hello everybody...

Yep, the "where's delay?" thingy is really misterious... :)
Delay (as an effect) is probably one of the simplest algorithms ever
(and we can even find several different raw implementations at this forum),
but we still not have this one in any of kx effects packages shipping...
It's curiosly to mention that "delay" was the first code used to debug and test
the Dane assembler itself... Then another delay forced Max to start ufx thingy
(He found that it is not acceptable to write a good one using present GUI framework
- that was one of the reasons as i've heard ;) - and.. hmm. i really don't know why
this effect is not yet there :) Ok, that was just curious introduction...

---------------

Yep, and even if is is (again) one of the simple algorithms the one should carefully
specify "target usage" of such thing since dealy is also one of the effects where too many
different implementations possible (stereo or mono input, feedback flow, number of taps,
availability of control over tap's properties such as level, pan, phase etc... etc...)

Here's for example simplest _stereo_ input delay which shows how "ping-pong" trick
is _typically_ implemented... (other implementations are also possible)

Code:

name "delay2003" 
guid "80100006-0999-11D6-BFBC-D4F706E10C52"    

xtramsize 0x17704 ; whatever

xdelay write d1 at 0x00000
xdelay read d1r at 0x02580   
xdelay write d2 at 0x0bb82 ; (~half of xtramsize)    
xdelay read d2r at 0x00e102

input in1, in2
output out1, out2

control xfeed = 0.25	; crossfeedback: 0 - "this-to-this pan", 0.5 - "mono feedback", 1 - pingpong
control fdbk = 0.25 	; feedback
control wmix = 0.5		; wet mix
control dmix = 1        ; dry mix

temp w

; left
interp 	w, d1r, xfeed, d2r
macs	d1, in1, w, fdbk;
macs	0, 0, d1r, wmix
macs	out1, accum, in1, dmix
	 
; right
interp 	w, d2r, xfeed, d1r   
macs	d2, in2, w, fdbk;
macs	0, 0, d2r, wmix
macs	out2, accum, in2, dmix

end
; i did not test it so errors are possible

and here some notes on possible extensions/improvements/variations...

a. "Mono Input" - the delay to be used to process signal which intentionally is mono
(voice, guitar etc...)
A single delay line could be used for any number of taps like:
xdelay write d1 at 0x00000
xdelay read d1a at 0x02580
xdelay read d1b at 0x03580
xdelay read d1c at ....
etc...
This reduces amount of XTRAM usage by 50%...
(in above example we have single tap delay line per channel)
- hmm.. but this will make "ping-pong" tricky to implement...
(e.g. probably we still need at least two separate lines)...

b. More then two taps and control of level, pan and feedback amount of each...
Well, this will require just one additional "tram-access-pair" per each tap,
and ~1 register/instruction per each parameter...
(in above example we have each tap hardly panned and mixed to output at the same wetmix level)

c. Modulation...
Well, the only thing to mention is that we need to combine long xtram line with short itram line and modulate the last one... (because we cannot touch xtram-based
lines in such manner)

d. Filters in feedback path...
As starting point i'd suggest (as compact but quite "tunable") first-order high-shelf with
adjustable frequency and cut amount...

e. well, etc... (many other important features like tempo-based delay times, tap-time link/unlink
and so on are the matter of "control code" and won't require additional DSP resources...).

thanks,

Lex Nahumury · Sep 17, 2003, 06:57 PM

Thank you Max.

One 'off topic' question;

Why exactly isn't it possable to lfo modulate a delay line in XTRAM?
Because of PCI bus timing?

Thanks,

/LeMury

Max M. · Sep 17, 2003, 10:07 PM

>Because of PCI bus timing?

I think yes... while the actuall itram address seems to be guaranteed to be changed not later then next sample cycle (hmm, where did i read that from? anyway this is prooved by working "two tap interpolation" code), latency (e.g. time beetween address register change and the actuall address change (e.g. time when correct samples starts to be written to data register) for the xtram seems to be undefined at all (and depends on pc configuration (like bios pci latency setting, other hardware that uses PCI bus, even CPU frequency maybe :~\ .)
And... if we imagine that emu10kx uses some "cache" for xtram (as some patents probably say) then it goes more badly...
Each address change makes (as it seems to be) that cache data to be somewhat "invalid" and then if we change that address at each sample cycle we just always get "random" samples from xtram... somethink like that maybe...
So, yep, we've got another "limitation rule" - xtram can be used only for "static/solid" delay lines...

p.s. I remember that Daniel Bertrand have measured that "xtram latency" and the results were about 3..4 sample cycles...
(which is not too bad but stuff like "everycycle" modulation becomes unworkable)

Lex Nahumury · Sep 18, 2003, 12:04 AM

Aha...I see. Yep, makes sense.
Thanks for the explanation and clearing that up Max.

/LeMury

Max M. · Sep 18, 2003, 11:31 AM

and small modification ;):
i think that "xfeed" should be applied to the inputs as well (so that ping-pong will start from first reflection - not from second as above - it will make sense only for "stereo input delay" of course)
like that:

Code:

; ...         
temp v
          
macs	w, in1, d1r, fdbk;           
macs	v, in2, d2r, fdbk;
interp 	d1, w, xfeed, v  
interp 	d2, v, xfeed, w 

macs	0, 0, d1r, wmix
macs	out1, accum, in1, dmix    
macs	0, 0, d2r, wmix
macs	out2, accum, in2, dmix     
; ...

mAlo · Sep 19, 2003, 09:28 AM

Ciao beautiful people!
In these days I have tried to merge some plug-in (the 2 delay base and the eq g10).
I have obtained something that almost works, but I'm not a programmer, and I'm at beginning with dane, so I do not know to continue!
Can You take a look to this awful thing?

mAlo · Sep 20, 2003, 03:01 PM

; New microcode
name "AmAloCiùCiùDelay_alpha_x";
copyright "Copyright (c) 2003.";
created "09/20/2003";
engine "kX";
; comment "";
guid "eaafb97e-52b1-4097-a146-ea7ef28c22bc";
; -- generated GUID

xtramsize 57600

input In_L, In_R;
output Out_L, Out_R;
control Level_L=0x7fffffff, Level_R=0x7fffffff, Feedback_L=0x19d89d8a;
control Feedback_R=0x32762762, Delay_L=0x66276275, Delay_R=0x33b13b13;
;control Wet_mix = 0.5 ; wet mix
;control Dry_mix = 1 ; dry mix

control Eq_Gain=0x7fffffff;
control Freq_31=0x3fffffff, Freq_62=0x3fffffff, Freq_125=0x3fffffff;
control Freq_250=0x3fffffff, Freq_500=0x3fffffff, Freq_1k=0x3fffffff;
control Freq_2k=0x3fffffff, Freq_4k=0x3fffffff, Freq_8k=0x3fffffff;
control Freq_16k=0x3fffffff;

static a0=0x5ea50a, b0=0x7fa15af4, y0=0x7fa0ceca;
static a1=0xbd044d, b1=0x7f42fbb1, y1=0x7f40cbd8;
static a2=0x178f316, b2=0x7e870ce8, y2=0x7e7e53fe;
static a3=0x2ed9cc9, b3=0x7d126335, y3=0x7cefb339;
static a4=0x5ca76e3, b4=0x7a35891b, y4=0x79ac645d;
static a5=0xb54d437, b5=0x74ab2bc7, y5=0x72935185;
static a6=0x15beabcb, b6=0x6a415433, y6=0x6245ec6f;
static a7=0x2860d3d0, b7=0x579f2c2e, y7=0x3abbe2bf;
static a8=0x425b11d6, b8=0x3da4ee28, y8=0x5ed27713;
static a9=0x5b708beb, b9=0x248f7413, y