comb~ and alternatives
Is there another comb filter option in Max? other than comb~ ?
I find the comb filter in MSP to be less than perfect for my
application, particularly in comparison to what i am used to in Cmix
and Csound and others (i know i know there is rtcmix~ and csound~ i
may go that route but i am hoping for a maxcentric solution).
In Csound you set the looptime to be 1/ frequency as you would expect,
but you can also set the filter ringtime to to arbitrarily long (or
short) reverb times. So you could set a short sample through the comb
and set it to buzz away for like 10 seconds if you felt like it.
Is there another way to get a really resonant comb filter in max that
lets you use employ csoundesque long ring times?
cheers,
kevin
On 2008 Apr 18, at 3:14 PM, kevin parks wrote:
> Is there another comb filter option in Max? other than comb~ ?
In MSP there is also the teeth~ object, though it doesn't sound like
it will help you too much. There is also tap.comb~ in Tap.Tools which
may be better -- check the URL in my signature.
best,
Tim
____________________________________
Tap.Tools - Objects for Max, MSP, and Jitter
http://electrotap.com/taptoolsmax/
regarding comb tone, I recently played with a friends eventide harmonizer, which had the most incredible sounding combs ive ever heard. Im curious if anyone here has played with out and knows of a way to get a similar tone?
also, I reccomend creating your own comb using tapin and tapout, and encapsulating it in a poly so that you can set the vector size to 1, which will allow you to get extremely tight delay times needed for combing, this will also allow for greater control over the things taking place within the comb, I added a highpass and lowpass to mine, as well as an overdrive and limiter to give the comb more tone and keep it from feeding back too much.
>
> Non-math answer, the higher you make the last inlet of comb~/teeth~
> the longer the ringing should be.
that's right. but the problem with [comb~] and [teeth~] is, that they
use linear delay time interpolation instead of slightly more
expensive cubic or allpass interpolation.
this becomes apparent if you set the delay time to non-integer
multiples of the sample interval - which is most often the case.
this results in high frequency loss in the output signal, which is
pretty audible if you work with high feedback settings.
if you set the delay time with a float (not a signal) teeth~, comb~
and also tapin/tapout~ don't do sub-sample delay times at all.
so the ringing frequencies are out of tune.
don't know exactly what kevin's problem is with [comb~], but i would
rather go with tapin~/tapout~ and set the delay time with a signal.
then again the highest possible pitch is limited by the sigvs.
but tapin/tapout's interpolation sounds much better than comb/teeth
(still not perfect).
aha, and if you go for distinct pitches, make sure you set the delay
time 1 sample shorter than the pitch period you want to obtain.
finally, i got a delay external somewhere on my disk that uses
allpass-interpolation (osx only).
this is slightly more cpu intensive and not made for rapid delay time
modulation, but gives you 'endless' ringing without
any unwanted high frequency loss. kevin, get back to me, if you want
to try it.
volker.
Oh, I forgot to ask before,
> aha, and if you go for distinct pitches, make sure you set the delay
> time 1 sample shorter than the pitch period you want to obtain.
This suggestion I was not aware of, why exactly should you need to do this? Is this to make up for some interpolation error? If you could fill me in that would be great :)
On 19 Apr 2008, at 18:59, Roth Michaels wrote:
>
> thanks for remembering to mention this. Not necessarily a
> "problem" (I've been known to use comb~ and tapin~/tapout~ for
> slightly different processes) but it is good to know that when you
> use comb~/teeth~ they could have different spectral effects.
not necessarily a problem, true - often it is desirable to have a
high frequency rolloff.
but you can't control the filter effect independently since it is
connected to the delay time setting, i.e. you get changing spectral
results for different delay times.
>
> When I was looking at Volker's example, I noticed something that I
> was unaware of. Signal vector seems to be an issue setting delay
> time for tapin~/tapout~ (see Axiom's suggestion to put it in a
> poly~), but not for comb~. Is comb~ one of the lucky objects that
> can take delay times smaller than allowed by the signal vector? I
> guess I feel silly for taking signal vector precautions with comb~
> in the past.
the sigvs limit is only a problem if you build the feedback path in
max (tapin/tapout or send/receive stuff).
inside an external you have access to all samples of a vector.
otherwise you couldn't build any useful filters, e.g.
>
>> finally, i got a delay external somewhere on my disk that uses
>> allpass-interpolation (osx only).
>> this is slightly more cpu intensive and not made for rapid delay time
>> modulation, but gives you 'endless' ringing without
>> any unwanted high frequency loss. kevin, get back to me, if you want
>> to try it.
> Also not Kevin, but would like to see that external ;)
for anyone interested in trying it, i've put a version + helpfile here
http://www.esbasel.ch/Downloads/MaxMSP-Objects.htm
volker.
On 19 Apr 2008, at 22:11, Roth Michaels wrote:
>
>
>> aha, and if you go for distinct pitches, make sure you set the delay
>> time 1 sample shorter than the pitch period you want to obtain.
>
> This suggestion I was not aware of, why exactly should you need to
> do this? Is this to make up for some interpolation error? If you
> could fill me in that would be great :)
> --
no, afaik this is not linked to interpolation.
we had a little discussion on the chuck-list about that issue not
long ago.
if you let the user provide the feedback path (as with tapin/tapout)
you can only access the feedbacked signal one sample later (assuming
a sigvs of 1). so in case you use the feedback delay to produce
periodic oscillation, the period will be 1 sample longer than the
actual delay time specified. i.e. the ringing sounds out of tune.
in an external, with built in feedback path, you can compensate the
one sample delay and get correct tuning if you pay attention to read-
write order.
this is what i _think_ it is, as i don't know the inner workings of
tapin/tapout.
but maybe someone from cycling wants to shed some light it?
well, you can always just test it yourself - see the patch below.
volker.
> finally, i got a delay external somewhere on my disk that uses
> allpass-interpolation (osx only).
> this is slightly more cpu intensive and not made for rapid delay time
> modulation, but gives you 'endless' ringing without
> any unwanted high frequency loss. kevin, get back to me, if you want
> to try it.
>
> volker.
Hello volker,
Id like to try out this external, sounds like it may have the tone Im looking for.
Thanks
On 20 Apr 2008, at 14:13, Nicholas C. Raftis III wrote:
>
> Hello volker,
> Id like to try out this external, sounds like it may have the tone
> Im looking for.
>> for anyone interested in trying it, i've put a version + helpfile
>> here
>> http://www.esbasel.ch/Downloads/MaxMSP-Objects.htm
let me know if you experience any problems.
vb
cool yeah that comb is great, thank you very much, the feed back oscillator seems to crash and sounds incredibly strange.. im not sure whats going on with it but I don't think it sounds the way its supposed to on my system.
On Apr 18, 2008, at 11:00 PM, Roth Michaels wrote:
> If you want to ring comb~, you need a very high feedback coefficient
which still isn't enough (for my purposes, in this particular project)
Perhaps i was not clear.
A patch is worth a thousand words. Observe MSP's somewhat wimpy comb~
even with the feedback cranked
and compare that with the ringfest that is on hand using rtcmix~ (i
could have done this with csound~ as well).
you will need rtcmix~
cheers,
kevin
--
Quote: kevin parks wrote on Sun, 20 April 2008 22:19
----------------------------------------------------
>
> On Apr 18, 2008, at 11:00 PM, Roth Michaels wrote:
>
> > If you want to ring comb~, you need a very high feedback coefficient
>
> which still isn't enough (for my purposes, in this particular project)
>
I'm not sure how long of a ring you need or how high you cranked the feedback, but a feedback coefficient of 0.998 seems to give a similar ring time to your rtcmix~ example. I'm guessing that comb~, tapin~/tapout~, and Volker's object should all be able to ring long enough if the feedback is set close enough to 1--the biggest difficulty is describing the delay time with the feedback factor. The problem with the formula I gave for that is that it only really gives an approximation of what would happen to the amplitude of a single sample entering the filter and this probably does not accurately describe the ringing effect.
While I am sure all of these delay concepts mentioned here can create long enough delay times for you, it may just be easier to use csound or rtcmix if you need to specify an exact ring time vs. a feedback coefficient. ^^
On Apr 20, 2008, at 11:02 PM, Roth Michaels wrote:
>>
> I'm not sure how long of a ring you need or how high you cranked the
> feedback,
.99
> but a feedback coefficient of 0.998 seems to give a similar ring
> time to your rtcmix~ example.
and yet i could make that even longer..... i just picked something
arbitrarily longish ring time on the rtcmix side.
and to my ears the cmix example rings much longer.
> While I am sure all of these delay concepts mentioned here can
> create long enough delay times for you, it may just be easier to use
> csound or rtcmix if you need to specify an exact ring time vs. a
> feedback coefficient. ^^
yeah, i still think the cmix one sounds better, and since i am a
musician and not a computer scientist i would much rather specify a
ring time than a feedback coefficient
I hate having my patches littered with third party objects. I been
bitten by that so many times in the past. You use a third party
external and it no longer is available for your machine ( so many of
my patches from my old set up used Trond Lossius's wonderful
externals, now PPC only, sadly) or you go to a gig or demo w/o your
own laptop and your patches on a thumb drive and you have to spend all
that time installing stuff (and installing third party max objects is
really not my idea of fun unless they come with one folder to drop in
externals and one to drop in help) ... hey for obscure stuff i don't
expect much, for comb? I was hoping to get comb~ to work a little
better.
I'll use rtcmix~ (thankfully Brad's made it an easy install and i use
Cmix for other stuff outside of Max/MSP anyway)
so now i'll spend an hour installing rtcmix~ on a dozen machines in
the lab.
rtcmix~ rocks
On 21 Apr 2008, at 05:59, kevin parks wrote:
>> I'm not sure how long of a ring you need or how high you cranked
>> the feedback,
>
> .99
>
>> but a feedback coefficient of 0.998 seems to give a similar ring
>> time to your rtcmix~ example.
>
> and yet i could make that even longer..... i just picked something
> arbitrarily longish ring time on the rtcmix side.
> and to my ears the cmix example rings much longer.
go figure, 0.99 is not enough. so why not set it higher? there's
still plenty of room until you hit 1 (= eternity).
from the way you set up comb~ in your example, you don't seem to care
for correct pitch.
then i see no reason not to use comb~.
> i would much rather specify a ring time than a feedback coefficient.
I think the only thing we were assuming is that it was going to be thought to convince you that comb~ can ring for a VERY VERY long time and while it has some limitations compared to other comb filter arrangements, ring time isn't one of them. Half of why I post responses on here is to get other people to correct me, so don't take it too personally if a response makes you feel dumb--I'm sure most of us are not trying to be jerks, just to the point. Responses to my responses often make me feel silly, so I just feel dumb for about a minute and then move on and keep responding because every time someone jumps in on my responses it will make me a better teacher down the road; either because I overlooked mentioning an important detail that should be included or correcting my self-taught understanding of things. It is great everyone on this forum is quick on amending the answers of others.
Anyway, some more comb filter info for you:
It is too bad that you can only drag the contents of a number box to two decimal places (maybe this will change in Max 5, but it too late to ask). When I was messing around with your example and found a feedback number that worked, I was just typing in values to the box. Volker's [expr] object is the key for implementing feedback factor in terms of delay time using the formula I posted earlier (and btw, sorry for giving the equation solving for current amplitude not ring time. I was tired and lazy and didn't feel like solving for c at the time). Another easy way to get better resolution for a number box is to take one number box and divide by 100. or something going into another number box like this:
Yeah, it is a little weird to control, but lets you drag a number box and get better decimal precision but that's a pretty lame solution if you ask me.
As far as the assumption you did not care about pitch, I think I can jump in and explain (Volker, please correct me if I am wrong). To be very accurate with specifying delay time you will need to use a signal, not a float. As far as the minus one sample goes, I am pretty sure this only applies if you are building your own filters using tapin~/tapout~.
Now, even though you can specify very long ring times with [comb~] there are other reasons to consider using [comb~] or other filter configurations. First of all there is frequency response, both Volker's external, your cmix example, and using tapin~/tapout~ will all have a more even frequency response than comb~/teeth~. Personally, I like the tone of comb~ and use it for a lot of things because of the high frequency loss.
Something else I noticed about your cmix example was that the initial amplitude passed through the filter seemed lower than with comb~ and so when set to decay over the same amount of time the decay will be more gradual with combit/cmix than with comb~. Now I am not 100% sure that this is the case and won't be until I mess around with it some more when I get some free time, but I think combit actually uses a variable feedback coefficient that starts farther away from 1.0, gets closer, and then falls again to create that more gradual fadeout to the ring. I will experiment more later this weekend or something to confirm/deny that theory. I tried looking at some cmix documentation to find out the algorithm behind combit and the description seemed more brief than other filter examples. Anyone know if there is a cmix list we could ask about this because I'd be curious what is going on behind the scenes with combit.
Yay for poorly crafted sentences!
On Apr 22, 2008, at 6:52 PM, Roth Michaels wrote:
> Something else I noticed about your cmix example was that the
> initial amplitude passed through the filter seemed lower than with
> comb~ and so when set to decay over the same amount of time the
> decay will be more gradual with combit/cmix than with comb~. Now I
> am not 100% sure that this is the case and won't be until I mess
> around with it some more when I get some free time, but I think
> combit actually uses a variable feedback coefficient that starts
> farther away from 1.0, gets closer, and then falls again to create
> that more gradual fadeout to the ring.
We don't use a variable gain coefficient in COMBIT; what I suspect
you are hearing is a consequence of specifying the reverb time in
seconds instead of as a multiplier of the feedback coeff. Here's the
code in the Ocomb ugen used by the instrument:
void Ocomb::setReverbTime(float reverbTime)
{
assert(reverbTime > 0.0);
_gain = pow(0.001, (_delsamps / _sr) / reverbTime);
}
float Ocomb::next(float input)
{
float tmp = input + (_gain * _delay->last());
_lastout = _delay->next(tmp);
return _lastout;
}
so the _gain factor is determined by the (user-input) reverbTime. We
also have the option to apply an amp envelope to the resulting
output, so you *could* get a simulation of a variable feedback gain.
(note: the COMBIT instrument uses an interpolating delay, so pitch
is accurate.)
> I tried looking at some cmix documentation to find out the
> algorithm behind combit and the description seemed more brief than
> other filter examples.
That's my fault -- COMBIT is one of the most ancient instruments in
the distro (and source is all there for perusing, of course). I
wrote the original in FORTRAN for the MIX language running on an IBM
3081 back in, like 1983 or something, I'm so old my memory don't work
so good no more. As it mutated into C and then C++ the docs stayed
rather terse.
> Anyone know if there is a cmix list we could ask about this because
> I'd be curious what is going on behind the scenes with combit.
Certainly! Go here:
or go to http://rtcmix.org/ and look at the 'links' (the mailing list
is linked there). We are a happy group.
> Yay for poorly crafted sentences!
Always and forever...
Thanks Brad, exactly what I was looking for. This weekend when I'm done with my new piece I'll mess around with combit and meditate on this issue some.
P.S. thanks for the links too. While I used to do some Csound work a few years ago, the CMix/RTCMix Music-N (this is from music N right?) world is new to me as of 2008 and I've been too busy with other projects to do any proper research into it.
On Apr 22, 2008, at 8:28 PM, Roth Michaels wrote:
> the CMix/RTCMix Music-N (this is from music N right?)
They all are... :-)
You wrote:
"It is too bad that you can only drag the contents of a number box to two decimal places (maybe this will change in Max 5, but it too late to ask)."
FWIW, you CAN already drag any decimal place in the float number box in Max 5 (without even asking).
--C