Hi Malte, Sorry for the delay - very busy days. If you can revive this project that would be most welcome. I will have very limited time to devote to AMS for the coming months. So the best way to proceed will be that we (and any others interested) discuss things to be done on the developers list. I will set up developer access for you if you sent me your sourceforge login name. There are QTLists everywhere in the code. I was never really involved with the QT side of AMS - Matthias did all that - and I wouldn't dare touching any of it. I think the first things to be done are: - Migration to the actual QT version. - Removing the dependeny on fftw2 (either by porting the code to fftw3 or, or by just removing the spectrum display - using jack it's easy enough to set up a link to JAAA or JAPA or any other external spectrum display. Maybe same for the scope. - Efficiency improvements - there is lots of room for this in some of the current dsp code. Longer term changes: - Remove the static ENV and MIDI objects. This will be a major task. Once this is done we can have dynamic polyphony, and also multiple independent polyphinic patches. I have some ideas on how this should be done, but it will be a major rewrite and should be done only after adapting everything to the current QT system. - Reviewing the parameter view system so it gets better integrated with the dynamic modularity. Currently modifiyng a patch having a parameter view is a risky business. -- FA Lascia la spina, cogli la rosa.

* remember open and save file paths * autoappend extension to saved files * allow opening files without extension, see 2 ;-) * improved parameter view Actually, the CPU load is one of the most important things to fix so it can be used with a polyphony more than 8. And some day it needs to be ported from Qt3 to 4, so separating the GUI from the engine would be helpful (if it's not done yet). Just my two cents, ce