Finally, i solved the problem in a quite empiric way, but it seems to work ... I agree, it deserves a lot of cleaning, i put a lot of [bang] to be shure that the coefficients are right...
I send the final abstraction, and a patch which uses it. It's quite fun and i think it sounds great ! ;-)
hello,
you're right. i made some fast clean up to this patch. it makes a nice low pass resonant filter.
i'm wondering if it's possible to have signal based
frequency and
resonant factor?
playing with block~ is the solution maybe?
Cyrille
Frank Barknecht a écrit :
Hallo, frablanc hat gesagt: // frablanc wrote:
I've made this little abstraction (modale.pd), which is an approximation of the mass-spring-damper equation, to make some modal synthesis. The abstraction works fine, but the amplitude of the impulsional response decreases with the frequency, and so i'd like to "normalize" the output of the filter. (The amplitude is really too big for low frequencies, as 100Hz
...).
I don't have a real answer, but your patch includes lots
of completely
undefined execution orders, that might or might not be
related to the
unusual scaling. You should use manymany more trigger
objects.
For example this little construct in your patch:
| [pow -1] |
|
[* ]has an undefined result. You must replace it with:
[pow -1] | [t a a] | / | / [* ]
to correctly get the square of the inverse as you probably
intended
and you must do similar triggering in the rest of your patch.
Maybe this already fixes your problem.
Ciao
Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34 /mn) ; tél : 08 92 68 13 50 (0,34/mn)
Hallo, frablanc hat gesagt: // frablanc wrote:
Finally, i solved the problem in a quite empiric way, but it seems to work ... I agree, it deserves a lot of cleaning, i put a lot of [bang] to be shure that the coefficients are right...
I send the final abstraction, and a patch which uses it. It's quite fun and i think it sounds great ! ;-)
Yes, it sound really wonderful I like it a lot (so much I'll steal it, if you don't mind ;)
Only with the execution order you still didn't get it right. it might work now, but as soon as you do some further editing it *will* break. Better fix it now. The [bang] objects don't help at all, let me explain why: Every "connection fanning" in your patch still has an undefined order. If two or more connections come out of a message outlet, you cannot tell which one will fire first. If order is important, and it practically *always* is, then you must use a trigger object instead of connection fanning.
So you should generally avoid more than one connection coming out of a single message outlet. It's trouble waiting to happen, you don't want to marry such patches.
Attached patch shows some of the things that can go wrong with connection fanning.
Frank Barknecht _ ______footils.org_ __goto10.org__