Where did you read about filtering techniques? Perhaps I could explain one or two things; I'm not a programmer, but I study mathematics and I'd like to see if I could help.

Sorry about the lag time in my reply. I've been busy with RealLife(tm),

There are quite a lot of web resources out there. Basically, what I understand the filter to be boils down to this:

The filter is an Infinite Impulse Response filter. Before samples can be passed into the filter, the filter parameters have to be transformed from the s to the z domain. This is the part that confuses me. What exactly is the s domian vs the z domain. Also, there's a couple of constants, one modified by the resonance parameter.

Resonance also seems to be a bit twitchy, add a tiny amount more than one and it screams (sounds very cool with Overdrive guitar sounds, but for regular sounds that employ resonance, it sounds very wrong, pianos don't feedback like that 😉)

The rest of it seems to be feeding forward the last n entries, with n being the number of coefficient sets. Each set does some simple arethmetic, stores it in the history, and goes to the next set. There is mention in the source code about "poles" and "zeros", which I do not understand, except they are locations on a unit circle (I have seen these diagrams).

In the transformation functions there seems to be a bit of calculus involved, and it's a bit beyond me. I've also seen some examples on the web where the s-z transform is (presumably?) performed, and the frequence response is graphed.

It doesn't matter in all practicality if I don't understand the math behind what is going on, but it's one of the things I'd like to know more about.

That's just the first bit of it. I'm not exactly sure why you're trying to reimplement the MT-32 stuff when for all practical purposes my version is done. Just check out the code. If you have questions, feel free to ask. It needs some serious optimization and refactoring, but other than that, its good as gold.

canadacow wrote:

That's just the first bit of it. I'm not exactly sure why you're trying to reimplement the MT-32 stuff when for all practical purposes my version is done. Just check out the code. If you have questions, feel free to ask. It needs some serious optimization and refactoring, but other than that, its good as gold.

In a way -- I'm just crazy, I suppose.. But-- It's mostly an acedemic excercise for me, The codebase is significantly different... but, so far, is very stable (albeit, slow ... unoptimised, compared to your codebase) Many of the things I have gleaned from the original implementation, but, due to the fact that for speed purposes, tables have been used in many areas, it's hard for me to track down what is actually going on in some cases. One of the reasons for the re-implementation is to centralise the actual tone producing code, I am having difficulty with the filter, But-- then I can't complain-- after all, I am re-inventing the wheel, here. It seems I have some of the same snags that were also in the existing codebase, i.e. the slight off-pitch of some of the sounds. Also-- the way I have things organised suits my own purposes for tuning out the remaining sound troubles (the driving force behind the tuning dialog). One of the major improvements, so far is stability, For one, the pops/clicks I was experiencing are gone, I have also implemented interpolation for the PCM sounds.

I suppose it's my nature, I guess 😉 I tend to be a bit bull-headed and independant at times, But, rather than ask questions about why certain constants exist, I want to figure it out on my own. I do refer to the original code a lot, and some is incorporated.

I just hope that in doing my own excersise, and posting my thoughts etc... on the process is not stepping on your toes ... If I am, just let me know.

On another note, I am willing to share whatever I discover along the way ...

Could you post some links to the actual resources, Ictoagh. The math involved sounds a lot like complex analysis (poles, unit circle).

Here is one of the most comprehensive I have seen

http://www.ee.vt.edu/~jnoronha/dsp_proj2_report.pdf

Anoher

http://www.mathworks.com/access/helpdesk/help … l/filterd5.html

Java Applet that calculates freq response:

http://www.digitalfilter.com/iircalwav/iircalwav.html

The filter is actually straight forward. Interpreting the cutoff parameters is what had me stumped for the longest time.

Your best resource is http://www.musicdsp.org/. For my emulator I just used the IIR filter from here: http://www.musicdsp.org/files/filters004.txt There really is no sense in reinventing the wheel. Filters are hard to write. Resonant filters are that much harder. As for the reverb, I used the code from Freeverb to implement that.

Yep.. I've played around a bit with the existing freeverb stuff. Very nice sounding reverb.

I'm using an unmodified version of the Resonant IIR filter, right now.. in searching for information on how it worked, I've found that particular code all over the place.. I took the existing unmodified form (I found it on http://www.gamedev.net) and made it into a class. From what it appears to me, in the MT32 the cutoff is actually the note frequency + (some value, there's tons of factors resulting in the final value...as evidenced by your code).

One question I do have, though, and I thought it was the case, but apparently not, ... I don't have Dune2 to test with, but, the ring modulator emits white noise when one partial is muted. The way I had my mixers set up, when I brought this part of it in, I got sounds that generated white noise when they shouldn't have, I wound up having to resort to not reusing the ring mod code in the ringmod with combine code. Why does it work that way? I would have thought internally to the MT32 (I don't have schematics in front of me) the ring modulator would have been a single entity, and reacted the same way either way.