Hi Malte, > Actually I dont have a feedback from Fons yet, or maybe my spamfilters > killed it. Speed optimization is my first thing because I believe to see > some obvious stuff to improve but time will tell. 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. > Second is an annoying dependency to something depricated QTLists or so > which at least made me necessary to google 10 minutes but I could > imagine that this turns off some newbies who dare to 'make' it and than > bang, no AMS for you. 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.
