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, in1, send1to1
...
macs b, 0, in1, 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:

input in
...
macs in, a, b, 1
...

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, out1, send1to1;
...
macs b, 0, out1, send1to2;
...
macs out1, 0, a, 1;
...

Quote:

Originally Posted by stylus02

i assumed it would be something like this:
input in
...
macs in, a, b, 1
...

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

e.g:
macs .... -1 // ok: -1 is a numeric constant
macs .... -v // error: arithmetic operation on variable

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

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

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)

and, yep - sorry for offtopic. i guess you would probably more like to hear about effects themselves

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.