Hello. It is no problem to design or write reverbs. The problem is in coding the interface (API, GUI, etc.) to the reverb. Here are some numbers. Yet unreleased jackgverb source code has 20 parameters, and I have coded only the early reflection section. All 20 parameters are meaningful to the end users, i.e., they are not developer parameters such as lengths of individual delay lines. Therefore the number of parameters cannot be reduced without making the reverb dull, canned. For each parameter I have the following functions: -a GUI callback (e.g., slider) -jackgverb_set() and jackgverb_get() called in the GUI callbacks -gverb_set() and gverb_get() called in jackgverb_set/get() Perhaps jackgverb_set/get() are unnecessary. I have them because gverb is an enclosed system with API and if I need to add something to the jack wrapping, its place is in jackgverb_set/get(). So, in total I have 5*20 = 100 functions for the parameters. The whole situation is a nightmare. I don't have time nor interest in coding with that kind of system. It all gets worse if the design is changed as often happens in the design phase. What would help? If nobody figures out anything, I could draw the reverb design on a small piece of paper and then somebody else may torture himself in coding. Are there coding patterns which would make my C code simpler? Would modular system help? PD has strange firing rules: does they apply to standard signal flow or to advanced ones? Feedback paths should be sample accurate, not blocked to N samples as in Csound. Juhana -- http://music.columbia.edu/mailman/listinfo/linux-graphics-dev for developers of open source graphics software