microeffects v1.0

stylus02 · Jan 14, 2008, 09:46 AM

hi all,

this is a bundle of effects i have written so far called "microeffects". the bundle includes
phaser, bitcrusher, chorus, delay mono/stereo, autopan, wah-wah, 80´s reverb and a 4x4 mixing matrix.

http://freenet-homepage.de/stylish-s...fects_v1.0.zip

for more informations visit: kx it!

stylus

Russ · Jan 14, 2008, 10:05 AM

One note about your microcode...

As a general rule you should not use the same input registers more than once in your code (there is info about this here in the forum).

In any case, I look forward to trying out your plugins

stylus02 · Jan 14, 2008, 10:20 AM

Quote:

Originally Posted by Russ

As a general rule you should not use the same input registers more than once in your code (there is info about this here in the forum).

oh have i done this? by me this fact is allready known. some code is made month ago.. some things could made better, but then the release date had not been today.
all in all the effects work very well.

ps: where are such double uses of input gpr´s?

Russ · Jan 14, 2008, 10:29 AM

Quote:

Originally Posted by stylus02

ps: where are such double uses of input gpr´s?

Well, it looks as though it is done in most of your plugins.

For example (in matrix4x4 mixer):

macs a, 0,[COLOR=Red] in1[/COLOR], send1to1
...
macs b, 0,[COLOR=Red] in1[/COLOR], send1to2
... etc.

In any case, it is not terrible, but the plugins should not be connected directly to FxBus.

stylus02 · Jan 14, 2008, 10:37 AM

hmm .. and this is meant with double use of input gpr? i assumed it would be something like this:

[COLOR=RoyalBlue]input in
...
macs in, a, b, 1
...[/COLOR]

Russ · Jan 14, 2008, 10:46 AM

Quote:

Originally Posted by stylus02

hmm .. and this is meant with double use of input gpr?

Yes, the register(s) should only be used once in the code.

Buffer the input by copying it to another register, and then use that register in the other instructions instead of the direct input.

i.e.
Use a temp register, or you could use an output register, etc.

i.e.
macs out1, in1, 0, 0;
...
macs a, 0, [COLOR=Red]out1[/COLOR], send1to1;
...
macs b, 0,[COLOR=Red] out1[/COLOR], send1to2;
...
macs out1, 0, a, 1;
...

Quote:

Originally Posted by stylus02

i assumed it would be something like this:
[COLOR=RoyalBlue]input in
...
macs in, a, b, 1
...[/COLOR]

You cannot do that either.

stylus02 · Jan 14, 2008, 11:00 AM

i don't understand why there could something happen. the input register is written every samplecycle by the driver itself. i do not modify and/or rewrite it, just read out several times in the microcode.. were there ever problems and how did these look?

Russ · Jan 14, 2008, 11:08 AM

Quote:

Originally Posted by stylus02

i don't understand why there could something happen. the input register is written every samplecycle by the driver itself. i do not modify and/or rewrite it, just read out several times in the microcode.. were there ever problems ans how did these look?

Yes, it is explained by Max M. somewhere here in the forum (there are a couple of different issues related to this).

Hold a sec and I will see if I can find that info...

http://driverheaven.net/effects-dsp/...em-fxbus1.html
http://driverheaven.net/bug-reports/...connected.html

Max M. · Jan 14, 2008, 11:27 AM

by the way:

Code:

macs wrt7, d1,rd7, -freq_comp
macs d2, rd7, wrt7, freq_comp

It must be a bug in the assembler - this code is invalid
- Dane does not support any arithmetic operators
(i wonder why it gives no error - but "-freq" is assembled as 0)
use the following instead:

Code:

macsn wrt7, d1,rd7, freq_comp
macs d2, rd7, wrt7, freq_comp

[color=gray]
e.g:
macs .... -1 // ok: -1 is a numeric constant
macs .... -v // error: arithmetic operation on variable
[/color]

stylus02 · Jan 14, 2008, 11:46 AM

wow. my programming style must be somewhat different when the assembler does something what never was defined. *g*
max, you are the developer of the assembler, isn't it?
all bugs will be fixed soon guys.

Max M. · Jan 14, 2008, 12:12 PM

heh - yep, that's cool - you're first (for 7 years!) to encounter this bug.
and, yeah, i'm the one to blame for most of bugs in the Dane.

stylus02 · Jan 14, 2008, 12:38 PM

dane is pretty great. never had so much fun while programming. we need a more detailed documentation about it. some time ago i made tests to find out how different numbers (fractional, integer) are interpreted by different instructions. this and many other thing like logical xor or skip instruction (skip in the instruction array) must be documented well. for that we must do challenge the dsp.

oh, i forgot the table lookup, which people missed all the time...

Max M. · Jan 14, 2008, 02:43 PM

[color=gray]
if you don't mind. your code gives a nice optimization food for the brain.
(just take this stuff as a "hint of the day")[/color]

Code:

; dry_wet

  macs wet, 0, rd, dry_wet ; make a wet register
  macsn dry, in, in, dry_wet ; make a dry register 

; output

  macs out, dry, wet, 1

this is exactly what interp instruction does, e.g. above can be written as:

Code:

interp out, rd, dry_wet, in;

the history illustrated that it's even more fun to have as little documentation as possible (joking - you know - time, time)
well, if i'm not mistaken the only exception of interpreting fract/int numbers is the y operand of macint*. The rest are less or more all the same.
Regarding instructions - i believe the pair of Untitled Document and General Assembly Syntax give a nice clue on each instruction (of course a big "dane manual" would be handy - i'm sure i'll write it when i'll retire on a pension

). additionally, here in the forum we'll find a lot of interesting information that can't be found anywhere else.

table-lookups: well, they're considered to be not as useful as they may look at first glance (see Look up Table for example). (although not completely useless of course)

[color=gray] and, yep - sorry for offtopic. i guess you would probably more like to hear about effects themselves[/color]

stylus02 · Jan 14, 2008, 03:17 PM

i know that max, but i was tired of recode my first plugins. some constructions were/are classical or experimental. i have done a lot of linear interpolation in my synth project and my skill becomes better and better.
doing this now for approximately a half of a year there is still much to learn.
code optimization will be in version 1.5 of the microeffect.
nevertheless thanks for your pieces of advice.

stylus02 · Jan 14, 2008, 03:59 PM

max, you are interested in effect mechanisms? the www offers all what you want. even descriptions about lexicon reverb algorithms. a good start is: Harmony Central - Effects Explained
take the google search and you will be surprised...

or do you mean my effect algorithms?
my know how is from www sources, books, experiences with music hardware.
the most important fact is the "right ear". you have to trim our effects until they sound better than a world class effects unit.

and i know, a 32 bit emu can do.
the effects i wrote, are some painfully missed ones in the kx driver bundle. so i did it.
musicans won't search for a long time in www to get what they want. they want make music with good effects.

maybe i will write some additions to the dsp beginners guide, which is quite good.

stylus02 · Jan 14, 2008, 04:48 PM

microeffects update on 14.01.2008, 22.33

have made some save temporary input registers. added dry_wet slider to microwah-wah.
the invalid opcode, max had recognized, sounds great. it remains in it until i have got an idea.

for download link see top entry.

Max M. · Jan 15, 2008, 03:16 AM

>the invalid opcode, max had recognized, sounds great.

amh - with this invalid code the allpasses have no effect (their feedback path is dead) - it will sound more great with fix

stylus02 · Jan 15, 2008, 06:50 AM

strange..

this is a 1. order allpass:

http://freenet-homepage.de/stylish-s...er_allpass.jpg

with substitute in my reverb (allpass 1): x(n)=f, y(n)=d1, a=wrt6, b=rd6, k=freq_comp the code has no audible effect.

i agree with you, if the coefficient "-freq_comp" is 0, the allpass is no more what it should be..
but it does any interesting diffusion and equalizing.

stylus

[COLOR=RoyalBlue]oh there was an error in my picture.. fixed[/COLOR]

stylus02 · Jan 15, 2008, 07:09 AM

i think i do simply following compromise:

[COLOR=RoyalBlue]; allpass 1

macs wrt6, f, rd6, -0.5
macs d1, rd6, wrt6, freq_comp

; allpass 2

macs wrt7, d1, rd7, -0.5
macs d2, rd7, wrt7, freq_comp[/COLOR]

so we have an allpass with fixed feedback amplification and variable feedforward amplification, which do bend the sound a wide range.

this is for developers only

http://freenet-homepage.de/stylish-s...ce_80_v1.5a.da

and some prests:
http://freenet-homepage.de/stylish-s...ce_80_v1.5.kxp

Max M. · Jan 15, 2008, 10:16 AM

>i think i do simply following compromise:

you've missed it, above i've written how to fix it correctly:

Code:

macsn wrt7, d1,rd7, freq_comp
macs d2, rd7, wrt7, freq_comp

stylus02 · Jan 15, 2008, 01:45 PM

max, when i did it with the "macsn" instruction it had no audible effect. maybe the tap delays are to short to hear any diffusion for what the (correct) allpasses are for. i have found an interesting equation as described above. with a negativ number as the "y" operator in the instruction no rule is broken.
i still like the sound and won't spend more time on it. this is 80's reverb and it can sound dusty.
if you like try out the presets with human voices primarily.

Max M. · Jan 15, 2008, 02:26 PM

Sorry, I just thought you maybe missed it.
Sure i get your point. Of course - you are the master here

- OK means OK. (yeah, 1/4-1/2 ms are too short to be heard for allpass, it actually starts to blur above 5..10ms - assuming its coefficient > ~.7)

stylus02 · Jan 15, 2008, 03:42 PM

i didn't know if i have missed it. never heart such old units individually.

hmm.. as i know a first order allpass has an average phase delay of 90°. when we have 4 allpasses in series the phase delay would be 360° (1 period) at average 1khz, what is 1ms. so i think my allpasses are not to short. furthermore i did test longer delaytimes with not much more goal.

modern reverb units use different algoritms such as feedback delay networks, waveguide meshs or convolution. i think the emu can do this too with restrictions in convolution.

stylus02 · Jan 15, 2008, 05:00 PM

one must be said: the space'80 is no "true stereo". the stereo input is mixed to mono and one output is 180° phaseshifted to the other.
i wanted simulate a good sounding old reverb with the same hardware limitations as there were when such things came up.
anytime i do it in "true stereo", which will eat the double on resources.

Max M. · Jan 15, 2008, 05:07 PM

Note the difference between a plain "allpass filter" (where the delay is 1 sample) (this (firts order) one - yes - turns it by 90° at Fs/2 (note - not average)) and a "delay allpass filter" (where the delay much longer, and phase shift is much bigger - but it's not about a phase actually). Even if both are the "allpass" filters - they have a very different effect on a sound (the way we sense it). The latter is a just another form of "delay network" (like a "comb filter" for example) just having an "allpass" form and therefore having a linear frequency response. The trick is - we are able to hear short "comb-filters" mostly because of their non-linear frequency response (e.g. we hear their "coloration"), but we can't hear a short allpass (because it has no "coloration") until its delay becomes large enough for actual "delay" effects to be heard (in that case the "effects of delay" will be hearable as "blurring", "flattering", "whatever" until delay becomes too long). Well, i'm a bad explainer. So, i guess you've already read many paper on reverberation but do not hesitate to take a look at Artificial Reverberation and Spatialization