Discussion:
[music-dsp] Emu IV filter design
Jamie Bullock
2004-12-08 10:07:44 UTC
Permalink
Dear all,

I am currently working on a project that involves converting a load of
old e64/EIV format samples into a more widely usable format. The initial
plan of attack was to use an Akai S5000, which claims to read and
convert the samples to WAV/Akai format.

The conversion worked well, but there are no equivalents to many of the
lovely filters on the emu!

Does anyone have any suggestions for i) an existing piece of software
that does good emulation of the emu filters, or ii) advice/warnings
regarding building the filters from scratch in an environment such as PD
or just plain C?

Thanks,

Jamie Bullock
-
Lecturer/Research Student
Birmingham Conservatoire
UK
-
a***@smartelectronix.com
2004-12-08 11:08:36 UTC
Permalink
Post by Jamie Bullock
Does anyone have any suggestions for i) an existing piece of software
that does good emulation of the emu filters, or ii) advice/warnings
regarding building the filters from scratch in an environment such as PD
or just plain C?
You will want to read two papers:
"The ARMAdillo Coefficient Encoding Scheme for Digital Audio Filters",
Dave Rossum, IEEE ASSP Workshop on WASPAA, 1991
and
"Filter Morphing of Parametric Equalizers and Shelving Filters for Audio
Signal Processing", Yinong Ding & David Rossum, JAES vol 43, Oct 1995

Basically they take "snapshots" of normal IIRs made of second order
sections, encode the coefficients with the ARMAdillo encoding and linearly
interpolate the encoded coefficients.

To make a resonant lowpass filter, you'd design a normal IIR filter at
the following four (constant) settings:
low cutoff no resonance
high cutoff no resonance
low cutoff high resonance
high cutoff high resonance

Then you'd encode the coefficients and linearly interpolate between the
encoded coefficients (bilinear interpolation as there are two axis). For
each sample interval, you'd decode the interpolated ARMAdillo coefficients
and update your second order coefficients.

Disclaimer: I haven't actually implemented this.
Disclaimer2: The method is patented - don't blame me if you get C&D
letter.

Antti
Andreas Sumerauer
2004-12-08 12:36:57 UTC
Permalink
... an existing piece of software
that does good emulation of the emu filters, ...
You might want to try this:
http://www.emu.com/products/product.asp?product=2212&category=631&maincategory=631

The EIV import works great. The overall sound and especially the filters
are identical to the hardware unit. (apart from the FX settings. the
effect routing of the Emulator X is a bit different from the EIV)
Dear all,
I am currently working on a project that involves converting a load of
old e64/EIV format samples into a more widely usable format. The initial
plan of attack was to use an Akai S5000, which claims to read and
convert the samples to WAV/Akai format.
The conversion worked well, but there are no equivalents to many of the
lovely filters on the emu!
Does anyone have any suggestions for i) an existing piece of software
that does good emulation of the emu filters, or ii) advice/warnings
regarding building the filters from scratch in an environment such as PD
or just plain C?
Thanks,
Jamie Bullock
-
Lecturer/Research Student
Birmingham Conservatoire
UK
-
--
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://shoko.calarts.edu/musicdsp
http://ceait.calarts.edu/mailman/listinfo/music-dsp
Tony Scharf
2004-12-08 14:41:44 UTC
Permalink
www.emu.com. The EmulatorX software. I had an EMU E64 a number of
years ago, and this software reads my banks exactly perfect. It has
all the same voice architecture of the EIV + it has more filter types
(something like 50 of them). It works great.

only downside, you need to have an emu sound card for it to run.

Tony
Post by Jamie Bullock
Dear all,
I am currently working on a project that involves converting a load of
old e64/EIV format samples into a more widely usable format. The initial
plan of attack was to use an Akai S5000, which claims to read and
convert the samples to WAV/Akai format.
The conversion worked well, but there are no equivalents to many of the
lovely filters on the emu!
Does anyone have any suggestions for i) an existing piece of software
that does good emulation of the emu filters, or ii) advice/warnings
regarding building the filters from scratch in an environment such as PD
or just plain C?
Thanks,
Jamie Bullock
-
Lecturer/Research Student
Birmingham Conservatoire
UK
-
--
subscription info, FAQ, source code archive, list archive, book reviews, dsp links
http://shoko.calarts.edu/musicdsp
http://ceait.calarts.edu/mailman/listinfo/music-dsp
Jamie Bullock
2004-12-08 23:04:40 UTC
Permalink
Antti,

Thanks. This is exactly the sort of information I was looking for. Shame
about the patent...

Jamie

-----Original Message-----
From: music-dsp-***@ceait.calarts.edu
[mailto:music-dsp-***@ceait.calarts.edu] On Behalf Of
***@smartelectronix.com
Sent: 08 December 2004 11:09
To: a list for musical digital signal processing
Subject: Re: [music-dsp] Emu IV filter design
Post by Jamie Bullock
Does anyone have any suggestions for i) an existing piece of software
that does good emulation of the emu filters, or ii) advice/warnings
regarding building the filters from scratch in an environment such as
PD or just plain C?
You will want to read two papers:
"The ARMAdillo Coefficient Encoding Scheme for Digital Audio Filters",
Dave Rossum, IEEE ASSP Workshop on WASPAA, 1991
and
"Filter Morphing of Parametric Equalizers and Shelving Filters for Audio

Signal Processing", Yinong Ding & David Rossum, JAES vol 43, Oct 1995

Basically they take "snapshots" of normal IIRs made of second order
sections, encode the coefficients with the ARMAdillo encoding and
linearly
interpolate the encoded coefficients.

To make a resonant lowpass filter, you'd design a normal IIR filter at
the following four (constant) settings:
low cutoff no resonance
high cutoff no resonance
low cutoff high resonance
high cutoff high resonance

Then you'd encode the coefficients and linearly interpolate between the
encoded coefficients (bilinear interpolation as there are two axis). For

each sample interval, you'd decode the interpolated ARMAdillo
coefficients
and update your second order coefficients.

Disclaimer: I haven't actually implemented this.
Disclaimer2: The method is patented - don't blame me if you get C&D
letter.

Antti
--
dupswapdrop -- the music-dsp mailing list and website:
subscription info, FAQ, source code archive, list archive, book reviews,
dsp links
http://shoko.calarts.edu/musicdsp
http://ceait.calarts.edu/mailman/listinfo/music-dsp
Urs Heckmann
2004-12-09 01:02:22 UTC
Permalink
Hiya,

Hmmm, does one need that armadillo thing? Sounds to me like an
optimization to calculate filter coefficients, no? With today's means,
one could calculate them on the fly I guess...?

;) Urs
Post by Jamie Bullock
Antti,
Thanks. This is exactly the sort of information I was looking for. Shame
about the patent...
Jamie
a***@smartelectronix.com
2004-12-09 14:09:35 UTC
Permalink
Hmmm, does one need that armadillo thing? Sounds to me like an optimization
to calculate filter coefficients, no? With today's means, one could calculate
them on the fly I guess...?
Yes, you could calculate them on the fly. On the other hand, armadillo
allows you to morph arbitrary filters. In fact, you can precalculate the
endpoint armadillo coefficients in matlab or something and just
interpolate between those in the filter code. You need 2^N sets of
coefficients, where N is the number of control parameters (N=2 for normal
cutoff, resonance filters).

This means that you can implement morphable EQs too with the exact same
filter code. Just change the endpoint armadillo coefficients.

Armadillo encoding is great for hardware implementation: You can make fast
2^x easily with FPGA and since you can precalculate the endpoint armadillo
coefficients, the whole filter can be implemented in a relatively simple
FPGA (see the E-Mu H chip).

IIRC, the patent was awarded in late 80's so it might be expiring soon.
Also it may be related to hardware implementation specifically (since you
can't patent mathematical formulae) so software implementation might not
have any problems with that. YMMV. At the least you should be safe if
you're in europe.

Antti
Urs Heckmann
2004-12-09 16:02:31 UTC
Permalink
Post by a***@smartelectronix.com
Post by Urs Heckmann
Hmmm, does one need that armadillo thing? Sounds to me like an
optimization to calculate filter coefficients, no? With today's
means, one could calculate them on the fly I guess...?
Yes, you could calculate them on the fly. On the other hand, armadillo
allows you to morph arbitrary filters. In fact, you can precalculate
the endpoint armadillo coefficients in matlab or something and just
interpolate between those in the filter code. You need 2^N sets of
coefficients, where N is the number of control parameters (N=2 for
normal cutoff, resonance filters).
This means that you can implement morphable EQs too with the exact
same filter code. Just change the endpoint armadillo coefficients.
Now, that's indeed interesting!
Post by a***@smartelectronix.com
Armadillo encoding is great for hardware implementation: You can make
fast 2^x easily with FPGA and since you can precalculate the endpoint
armadillo coefficients, the whole filter can be implemented in a
relatively simple FPGA (see the E-Mu H chip).
IIRC, the patent was awarded in late 80's so it might be expiring
soon. Also it may be related to hardware implementation specifically
(since you can't patent mathematical formulae) so software
implementation might not have any problems with that. YMMV.
Might be.
Post by a***@smartelectronix.com
At the least you should be safe if you're in europe.
ARRRGH. Either you don't follow the news, or you're a master of cynism
8-)

The latest draft of the EU law for *patents on computer implemented
innovations* (freely translated from German, that is) let me sweat big
time. The commission wanted to give it a nod in a short cut manner, but
at least it looks like they're gonna send the contract back to
parliament for discussion (where Spain and Poland will hopefully kill
it).

I don't know what's been driving them unless it's masochism and willing
to kill our software industry (which is primarily based upon small and
medium sized companies who don't see a sense in aquiring patents, or
simply can't afford any).

I have owned a patent (a *real*, physical one) for some years, but
neither could it prevent me from having an intrigueing idea stolen, nor
did it do anything else than costing me fees. The costs are absolutely
no fun, yet we'd always have to fear that someone with a budget wants
to erase us from the landmark.

Sorry for the rant ;-)

Cheers,

;) Urs
j***@det3.net
2004-12-09 23:05:04 UTC
Permalink
Hey all,

The ARMAdillo was an encoding scheme to relieve one of the burden of
having to use large coefficient sizes for IIR filters. Also, this is
one of the reasons that wide-band E-Mu Z-Plane filters have real
horrible LF response. And yes, one can design a system now that
doesn't have to use the ARMAdillo encoding algorithm by Rossum. I'm
currently working on an AU that implements something similar to E-Mu's
Z-Plane using RBJ's filter classes that have been all over here for a
while. FYI, the patent # is 5,170,369.

Regards,

Joe Grisso
Det3 Media, Ltd.
Post by Urs Heckmann
Hiya,
Hmmm, does one need that armadillo thing? Sounds to me like an
optimization to calculate filter coefficients, no? With today's means,
one could calculate them on the fly I guess...?
;) Urs
Post by Jamie Bullock
Antti,
Thanks. This is exactly the sort of information I was looking for. Shame
about the patent...
Jamie
--
subscription info, FAQ, source code archive, list archive, book reviews,
dsp links
http://shoko.calarts.edu/musicdsp
http://ceait.calarts.edu/mailman/listinfo/music-dsp
Urs Heckmann
2004-12-10 02:13:10 UTC
Permalink
Hiya,

now... what exactly are the Z-Plane filters?

I kept thinking that they are a couple of LP/HP and Peaking filters in
series, or maybe with some BP in parallel?

I think I can remember that they have like 14 poles. But then, putting
them into a single set of coefficients (multiplying the transforms)
would make them pretty instable even at double precision, no?

Hmmm, or am I completely mistaken?
Post by j***@det3.net
I'm
currently working on an AU that implements something similar to E-Mu's
Z-Plane using RBJ's filter classes that have been all over here for a
while.
Please, keep us up to date!

Cheers,

;) Urs
j***@det3.net
2004-12-10 06:02:10 UTC
Permalink
Post by Urs Heckmann
Hiya,
now... what exactly are the Z-Plane filters?
First off, let me say that Z-Plane is a trademark of E-Mu, so a more
technically correct classification is required. I'd basically call them
multi-segment interpolating filters.

There are two parts to this filter architecture - the filters themselves
and the coefficient interpolator. The interpolator can store up to six
"filter presets", and then interpolate between all six presets. Think of
each preset residing in a corner of a cube, and then have three control
parameters (CVs, CCs, whatever) be able to move in the X, Y, and Z
directions. This is why they called the first z-plane synthesizer
"morpheus" - because you could morph between filter presets.
Post by Urs Heckmann
I kept thinking that they are a couple of LP/HP and Peaking filters in
series, or maybe with some BP in parallel?

Specifically, the E-Mu filter architecture consists of seven two-pole IIR
sections connected in series. The first being a lowpass filter, and the
next six sections being parametric filters. Each segment has controllable
Cutoff, Q, and the parametric sections have controllable bandwidth. This
allows you to create much more detailed filter curves than your standard
-12/-24dB per octave lowpass curves of the old analog days.
Post by Urs Heckmann
I think I can remember that they have like 14 poles. But then, putting
them into a single set of coefficients (multiplying the transforms)
would make them pretty instable even at double precision, no?
Post by Urs Heckmann
Hmmm, or am I completely mistaken?
Yes and no - you get a "14 pole filter" by adding up each 2-pole section.
Each set of coefficients described in the ARMAdillo spec on AES and the
patent are for a single 2-pole section. Rossum developed this spec (which
is really a funky form of logarithmic compression) so he could implement
the filter morphing in hardware with minimal loss of fidelity when you
interpolated between the preset coefficients. There's some additional
stuff to the biquad IIR architecture I can't talk about, which is silly...
but most competent DSP folks can figure out how to make a biquad section
like this stable across the audio band.

The cool part is when you think about it in hardware terms, it gets really
impressive. Dave Rossum basically got 64 2-pole filters into a 20,000 gate
ASIC with decent dynamic range in 1989. In 2001, E-Mu had a chip on the
drawing board called the H2.0, which increased the number of filters to
384 on a single 250K gate ASIC - and that's the magic behind the ARMAdillo
algorithm. Encoding the coefficients to make it easy for a hardware ASIC
to interpolate, and shrinking gate budgets to make the hardware more cost
effective.
Post by Urs Heckmann
Post by j***@det3.net
I'm
currently working on an AU that implements something similar to E-Mu's
Z-Plane using RBJ's filter classes that have been all over here for a
while.
Post by Urs Heckmann
Please, keep us up to date!
All updates for the project will be placed here:

http://proteus.det3.net/projects/sonos/

Don't laugh too hard - I like to start in marketspeak, so I know how big
of a boondoggle I'm getting myself into before I build. :-) I'll start
seriously hacking on it in a few weeks, after fall semester is over at
University.

Best Regards,

Joe Grisso
Det3 Media, Ltd.

Continue reading on narkive:
Loading...