> What do you want me to check?

I was just more curious to see if you understood the similarities between comb~ and teeth~ since it seemed you were still in doubt on how it behaved.

Did you see that comb~ has also two delay lines?

> If comb~ and teeth~ are so close, one

> wonders why there are two objects at all.

Well, they are that close... the only thing is that teeth~ is a bit more flexible, but it can act exactly like comb~ if the delay values are the same for the feedforward and the feedback.

I guess they made it in the case anyone wanted a filter that is a bit more flexible.

On that note, you may realize that the structure of the [allpass~] object is also exactly the same as [comb~]! This means that you can make an [allpass~] out of [comb~], just make it sure, in comb~, that b = 1 and that c = a * -1!

So it's kinda like [comb~] is the same as [allpass~] but more flexible. And teeth~ is an even more flexible unit than comb~ (and yeah, you can also make allpass~ with teeth~).

Hope that was clearer and not more confusing.

cheers

2015-06-25 4:08 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl>:

Hi Alexandre,

What do you want me to check?

If comb~ and teeth~ are so close, one wonders why there are two objects
at all. In hindsight, the early development of objects in Max/MSP
doesn't look very organized. Almost like the pd-extended collection :-).

Greetings,

Fred Jan

On 2015-06-25 12:20 AM, Alexandre Torres Porres wrote:
> were you able to check it? I'm curious to see if we are on the same page :)
> cheers
>
> 2015-06-23 13:52 GMT-03:00 Alexandre Torres Porres <porres@gmail.com
> <mailto:porres@gmail.com>>:
>
> > Well, not quite. You also need another delay line,
> > as each has different input (input and output signal).
>
> Not really, because [comb~] also has two delay lines, one for input
> and another for output, in the same way! The thing is that it'll
> have the same delay time for both lines, whereas in teeth~ you can
> specify different times for each delay.
>
> see my patch attached comparing them.
>
> cheers
>
> 2015-06-23 12:08 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl
> <mailto:fjkraan@xs4all.nl>>:
>
> Hi Alexandre,
>
> > hello, I had plans to try working on a .c code for it, and my idea was
> > to just adapt from [comb~].
> >
> > Yeah... Teeth is almost identical to [comb~]!
> >
> > In [comb~] you have the same delay time for the feedforward and the
> > feedback. In [teeth~] you can specify different time delays for
> > feedforward and feedback. So you basically have only one extra time
> > delay parameter to include in [comb~] and... voilà, you've got [teeth~]!
>
> Well, not quite. You also need another delay line, as each has
> different
> input (input and output signal). And writing code is more fun than
> reading/understanding/adapting. I prefer the array aproach above the
> pointer arithmetic that real programmers use :-).
> >
> > Hope this makes it clear for you.
> >
> > Cheers
>
> Greetings,
>
> Fred Jan
> >
> > 2015-06-23 4:56 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>

> > <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>>:
> >
> > Hi Alexandre,
> >
> > Just now I completed the c code for a teeth~ object, which doesn't seem
> > to crash instantly and sounds* the same as your abstraction which is now
> > in cyclone.
> >
> > The block diagram in your help patch made it very clear what should be
> > coded. The only thing (what an expert told me), was that 'z' applies to
> > samples, and teeth~ is controlled in milli-seconds.
> >
> > While coding, I found the delay time has to be zero or positive, but the
> > gain coefficients can be negative too, adding the delayed signal out of
> > phase.
> >
> > I have no plans to add the object to cyclone anytime soon. First spend
> > some time figuring out that i really does what I think it does. It
> > doesn't crash instantly, and output looks sinusoid with a sinus input,
> > but that doesn't prove much. And at least some form of interpolation
> > should be added before it is ready for prime time.
> >
> > Greetings,
> >
> > Fred Jan
> >
> > *) the help patch sounds equally weird with both, using only the
> > positive gains
> >
> > On 2015-06-15 04:14 PM, Alexandre Torres Porres wrote:
> > > it's just a preview, I'm gonna still work on them and help files :)
> > >
> > > 2015-06-15 10:38 GMT-03:00 Fred Jan Kraan <fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>
> > <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>
> > > <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>
> <mailto:fjkraan@xs4all.nl <mailto:fjkraan@xs4all.nl>>>>:
> > >
> > > Hi Alexandre,
> > >
> > > Thanks for the abstractions. I will include them in
> the svn
> > repository
> > > and the next binary deken compatible builds. Only
> rect~ didn't
> > work.
> > >
> > > I applied some minor modification by replacing [pi],
> which doesn't
> > > appear to be vanilla by [3.141593(.
> > >
> > > Greetings,
> > >
> > > Fred Jan
> > >
> > > P.S. Wouldn't mind if the future supplied
> help-patches were
> > already
> > > cyclone-standard formatting ;-).
> > >
> > > On 2015-06-14 10:14 PM, Alexandre Torres Porres wrote:
> > > >> Any object or abstraction that implements something
> > > >> present in Max(5) could be part of cyclone.
> > > >
> > > > i've made 13 abstractions so far
> > > >
> > > > - atodb
> > > > - atodb~
> > > > - dbtoa
> > > > - dbtoa~
> > > > - freqshift~
> > > > - rect~
> > > > - saw~
> > > > - scale
> > > > - scale~
> > > > - teeth~
> > > > - thresh~
> > > > - tri~
> > > > - trunc~
> > > >
> > > > Gonna try and do a few of these more, I have more
> 5 in mind
> > so far. I
> > > > guess some make much more sense as objects, like
> > > [rect~]/[tri~]/[saw~].
> > > > Here's a preview attached.
> > > >
> > > > cheers
> > >
> > >
> >
> >
>
>
>