[n] numbers in plugins?

brainless_beginner

I wonder what are these small numbers at the bottom of each plugin in the dsp window for? Is it just a couter or what? And what if my plugin chain doesn't match exactly that uprising sequence?

Russ

It is mainly an identifier for use in kX Console, but it also indicates the ordering of the plugins within the DSP (in general.... not always). It is best to order the plugins (start with a blank DSP) such that any plugin(s) that takes it's input from another plugin(s), is loaded after that plugin(s). This is to ensure that they are all working with the same sample number during each cycle of the DSP. In many cases it really does not make any difference, but in some cases it does, so it is best to get yourself into the habit of building your DSP configs this way.

WxMan1

Roger that. Now if I could only finger out if its best to place the plug-in before or after the microcode I'd be all set.

Russ

Hehe, don't bother with the advanced options (uncheck it) as it is not all that useful, and just start with a blank DSP.

Chester01

Hey Russ, thanks for the advice about the number order of the plugins, I have rebuilt my dsp's on our three computers running KX due to your advice Could you give a bit more insight as to which plugins are affected (or why) by their order in the dsp? Are there certain things that cannot be done after other things? :-/ I was going to change my dsp on one computer abit and am wondering if its worth doing another rebuild because the change is pretty far 'up the chain'

Russ

In most cases the ordering will not make much difference, so I would not worry about it, but there are other reasons why it is good to start with a blank DSP when building your configs (and if you are starting blank anyway, you may as well load them in order). i.e. If you often load/unload plugins, you can end up with holes in the DSP, such that you may have enough free space left for some plugin that you want to load, but the free space is fragmented, so you cannot load the plugin. Also, occasionally if I have been unloading/reloading plugins a lot, I get some strange DSP behavior (i.e. signal bleeding for no apparent reason, etc), that goes away if I rebuild the same config starting with a blank DSP.

Russ

Here is an odd example to show the possible effects of the load order (and connection arrangement), but again in most cases (i.e. the type of config most people would use) it probably would not make much of a difference.

DSP Config

In the above DSP config, the same signal is taken twice from the wave generator plugin and fed to a mono mix plugin (with some vol plugins in between). Connections and plugin settings are the same for both paths, the only difference being the load order, and the order in which the vol plugins are connected/arranged. Overlaid on the picture of the DSP config, is a picture of the 2 signals (feeding the mono mix plugin) that shows that they are almost 180 degrees out of phase with each other. Because of this, if you listen to the output of the mono mix plugin (assuming mono mix is set with the left/right volumes equal, i.e. 50/50, 100/100, etc), you probably will not hear anything (but I suggest you keep your volume low if you try (just in case)).

BTW: You would get the same result with any number of vol plugins on the bottom, since they are loaded and connected in such a manner, that any plugin that takes it's input from another plugin is loaded at some point after that plugin (i.e. in this case they are in a consecutive order).

Anyway, I thought I would show an example that (although odd) uses simple plugins, but the end result may not be immediately obvious when looking at the config.

Chester01

cool and good to know, are there certain functions within the plugins that cause them to do this? ex. i could look at the code of a plugin and if it had a "macs" one could assume its function will depend on the proper load order within the dsp... Thank you for taking the time to make that demonstration btw

Russ

No, it is not related to the plugin itself (although (obviously) some plugins add delay intentionally, and some plugins add delay as a side effect of thier normal functionality), this is why I used simple (to understand) plugins in the example.

DSP code is executed in a linear fashion, generally in the order that the plugins were loaded.

i.e.
code for plugin[1] is executed first, then code for plugin[2], etc.

Now imagine that plugin[1] gets it's input from plugin[2].

i.e.
... -> plugin[2] -> plugin[1] -> ...

On the very first DSP cycle the following happens:
plugin[1] takes input from plugin[2], processes it, and outputs a value, BUT, plugin[2]'s code has not been executed yet, so the value in it's output register is zero, and thus that is the value plugin[1] gets. Next the code for plugin[2] is executed, it takes it's input from whatever it is connected to, processes it, and outputs a value.

In the following DSP cycles the following happens:
plugin[1] takes input from plugin[2], processes it, and outputs a value, BUT again, plugin[2]'s code has not been executed yet (this cycle), so the value in it's output register is from the previous cycle, and that is the value that plugin[1] gets, thus a delay of 1 sample is introduced.

In the example with the wave generator plugin, the plugins at the top are all connected in the reverse order that they were loaded, so if you use the same logic, you will see that a delay of 7 samples is introduced in the top path, while there is no delay in the bottom path.

Chester01

ah makes sense... Thanks again!

Russ

One other thing to note is that the code for a plugin is placed in the DSP in the first place found with enough contiguous free space for the plugin's instructions, and the plugin is assigned the first available number. Because of this, when you start unloading plugins and loading different plugins, it may not be completely clear as to the order in which each plugins code will get executed (particularly if you have any untranslated plugins in the DSP). In these cases, the number in brackets may not reflect the load/execution order, and is why I say "in general.... not always".

i.e.
plugin[1] -> plugin[2] -> plugin[3]

Imagine plugin[2] is a vol plugin, which has 1 instruction. You decide to unload it and use a St Vol plugin instead, which has 2 instructions. It cannot fit where the vol plugin was, so it is loaded into the first available (contiguous) space, which is after plugin[3], but the first available number is [2]. Next you load some other plugin that has one instruction, it is loaded where the vol plugin was (right after plugin[1]), but the first available number is [4]. In this case the execution order would be [1] [4] [3] [2] (but signal path is still [1] -> [2] -> [3] -> [4] (assuming you used the same connection scheme with the new plugins)). In this case, everything looks OK, but you have a 2 sample delay that you are probably not aware of.

Chester01

another good thing Thanks! So I assume this knowledge will come in handy when applying gain to audio? ex. if I for some reason were to apply +60db and then -60 db to get the 'original' signal, if I loaded the +60db plugin first then the -60 one, even if i connected the -60 one before the +60 db plugin, i would have severe clippling on audio that had a fairly 'normal' level rather than distortion from 'the bits' being truncated and some dynamic range lost?

Russ

No, the audio always follows the path as it is connected. If the -60 dB plugin is before the +60 dB plugin, regardless of the load order, the -60 dB plugin will process the audio first (the +60 dB code may be executed first, but it still takes it's input from the plugin it is connected to). The only difference would be whether there is a 1 sample delay or not.

If a plugin's code is executed before the plugin that is providing it's input, the input it gets is the (fully processed) value from the previous cycle.

i.e.
src[1] -> -60dB[3] -> +60dB[2] -> out[4]
would give the same result as:
src[1] -> -60dB[2] -> 1SampleDelay[3] -> +60dB[4] -> out[5]