i'm working on delays and, before understanding all the pitfalls of 

building one in C, i made one in max patching. To have a multitap delay, 

the workaround i found is to remove/redraw a tapout~ object by scripting 

(have to say how many taps, and what are their times...) Is there any 

f.e chanfrault | aka | personal computer music

> >>>>>> |sublime music for a desperate people|

i'm working on delays and, before understanding all the pitfalls of 
building one in C, i made one in max patching. To have a multitap delay, 
the workaround i found is to remove/redraw a tapout~ object by scripting 
(have to say how many taps, and what are their times...) Is there any 
better solution ?

f.e
-- 
f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> |sublime music for a desperate people|


delay-lines

You have noticed that one tapout~ can take multiple arguments, and be a multitap delay, yes?

Quote: f.e wrote on Mon, 27 November 2006 07:24

----------------------------------------------------

> i'm working on delays and, before understanding all the pitfalls of 

> building one in C, i made one in max patching. To have a multitap delay, 

> the workaround i found is to remove/redraw a tapout~ object by scripting 

> (have to say how many taps, and what are their times...) Is there any 

> f.e chanfrault | aka | personal computer music

> > >>>>>> |sublime music for a desperate people|

Quote: f.e wrote on Mon, 27 November 2006 07:24
----------------------------------------------------
> Hello,
>
> i'm working on delays and, before understanding all the pitfalls of 
> building one in C, i made one in max patching. To have a multitap delay, 
> the workaround i found is to remove/redraw a tapout~ object by scripting 
> (have to say how many taps, and what are their times...) Is there any 
> better solution ?
>
> best
>
> f.e
> -- 
> f.e chanfrault | aka | personal computer music
> > >>>>>> http://www.personal-computer-music.com
> > >>>>>> |sublime music for a desperate people|
>
----------------------------------------------------


one tapout~ inside of each instance, change the times from outside the poly~ with the |target $1|

message and mute those you don't use if you want to have a dinamic amount of delays.

note this way you don't change the dsp chain each time you change a parameter, and that means no

> i'm working on delays and, before understanding all the pitfalls of

> building one in C, i made one in max patching. To have a multitap delay,

> the workaround i found is to remove/redraw a tapout~ object by scripting

> (have to say how many taps, and what are their times...) Is there any

>> >>>>>> |sublime music for a desperate people|

use [poly~]
one tapout~ inside of each instance, change the times from outside the poly~ with the |target $1|
message and mute those you don't use if you want to have a dinamic amount of delays.
note this way you don't change the dsp chain each time you change a parameter, and that means no
interrution in sound processing!

> Hello,
>
> i'm working on delays and, before understanding all the pitfalls of
> building one in C, i made one in max patching. To have a multitap delay,
> the workaround i found is to remove/redraw a tapout~ object by scripting
> (have to say how many taps, and what are their times...) Is there any
> better solution ?
>
> best
>
> f.e
> --
> f.e chanfrault | aka | personal computer music
>> >>>>>> http://www.personal-computer-music.com
>> >>>>>> |sublime music for a desperate people|
>


I don't know about f-e but did learn somthing today!

> You have noticed that one tapout~ can take multiple arguments, and be a multitap delay, yes?

> Quote: f.e wrote on Mon, 27 November 2006 07:24

> ----------------------------------------------------

>> i'm working on delays and, before understanding all the pitfalls of

>> building one in C, i made one in max patching. To have a multitap delay,

>> the workaround i found is to remove/redraw a tapout~ object by scripting

>> (have to say how many taps, and what are their times...) Is there any

>> f.e chanfrault | aka | personal computer music

>> > >>>>>> |sublime music for a desperate people|

> || michael f. zbyszynski -- molecular gastronimist

> || mzed@cnmat.berkeley.edu -- +1.510.643.9990x314

I don't know about f-e but did learn somthing today!
//yac
>
> Hi f.e.-
>
> You have noticed that one tapout~ can take multiple arguments, and be a multitap delay, yes?
>
> mz
>
>
> Quote: f.e wrote on Mon, 27 November 2006 07:24
> ----------------------------------------------------
>> Hello,
>>
>> i'm working on delays and, before understanding all the pitfalls of
>> building one in C, i made one in max patching. To have a multitap delay,
>> the workaround i found is to remove/redraw a tapout~ object by scripting
>> (have to say how many taps, and what are their times...) Is there any
>> better solution ?
>>
>> best
>>
>> f.e
>> --
>> f.e chanfrault | aka | personal computer music
>> > >>>>>> http://www.personal-computer-music.com
>> > >>>>>> |sublime music for a desperate people|
>>
> ----------------------------------------------------
>
>
> --
> || michael f. zbyszynski -- molecular gastronimist
> || mzed@cnmat.berkeley.edu -- +1.510.643.9990x314
> || http://www.cnmat.berkeley.edu/
> || http://www.piratelemur.com/
>
>
>
>


And you can have multiple tapout~ objects from one tapin~ object, as 

> You have noticed that one tapout~ can take multiple arguments, and 

>> building one in C, i made one in max patching. To have a multitap 

>> the workaround i found is to remove/redraw a tapout~ object by 

>>>>>>>>> |sublime music for a desperate people|

Associate Professor of Contemporary Music

SFIFEM                Atrium Sound Space        OVOS

And you can have multiple tapout~ objects from one tapin~ object, as  
well...

>
> Hi f.e.-
>
> You have noticed that one tapout~ can take multiple arguments, and  
> be a multitap delay, yes?
>
> mz
>
>
> Quote: f.e wrote on Mon, 27 November 2006 07:24
> ----------------------------------------------------
>> Hello,
>>
>> i'm working on delays and, before understanding all the pitfalls of
>> building one in C, i made one in max patching. To have a multitap  
>> delay,
>> the workaround i found is to remove/redraw a tapout~ object by  
>> scripting
>> (have to say how many taps, and what are their times...) Is there any
>> better solution ?
>>
>> best
>>
>> f.e
>> -- 
>> f.e chanfrault | aka | personal computer music
>>>>>>>>> http://www.personal-computer-music.com
>>>>>>>>> |sublime music for a desperate people|
>>

Associate Professor of Contemporary Music
College of Santa Fe
Contemporary Music Program
1600 St. Michaels Drive
Santa Fe NM 87505
http://pubweb.csf.edu/~smill
(505) 473-6197

SFIFEM				Atrium Sound Space		OVOS
http://sfifem.csf.edu	http://atrium.csf.edu		http://pubweb.csf.edu/ 
~smill/ovos.html

Yes, i know that tapout~ can take multiple arguments. But only since a 

few days when, looking for how to achieve a bouncing ball delay, i 

re-read the docs. Because there's not a shadow of this in the help 

files... Anyway, i erase/rewrote the tapout~ each time i need to change 

the number of taps, but i still wonder if there was something more sexy 

> And you can have multiple tapout~ objects from one tapin~ object, as 

> On Nov 27, 2006, at 4:43 PM, mzed wrote:

>> You have noticed that one tapout~ can take multiple arguments, and be 

>> Quote: f.e wrote on Mon, 27 November 2006 07:24

>> ----------------------------------------------------

>>> i'm working on delays and, before understanding all the pitfalls of

>>> building one in C, i made one in max patching. To have a multitap delay,

>>> the workaround i found is to remove/redraw a tapout~ object by scripting

>>> (have to say how many taps, and what are their times...) Is there any

>>> f.e chanfrault | aka | personal computer music

>>>>>>>>>> |sublime music for a desperate people|

> Associate Professor of Contemporary Music

Yes, i know that tapout~ can take multiple arguments. But only since a 
few days when, looking for how to achieve a bouncing ball delay, i 
re-read the docs. Because there's not a shadow of this in the help 
files... Anyway, i erase/rewrote the tapout~ each time i need to change 
the number of taps, but i still wonder if there was something more sexy 
around.

Steven Miller wrote:
> And you can have multiple tapout~ objects from one tapin~ object, as 
> well...
>
>
> On Nov 27, 2006, at 4:43 PM, mzed wrote:
>
>>
>> Hi f.e.-
>>
>> You have noticed that one tapout~ can take multiple arguments, and be 
>> a multitap delay, yes?
>>
>> mz
>>
>>
>> Quote: f.e wrote on Mon, 27 November 2006 07:24
>> ----------------------------------------------------
>>> Hello,
>>>
>>> i'm working on delays and, before understanding all the pitfalls of
>>> building one in C, i made one in max patching. To have a multitap delay,
>>> the workaround i found is to remove/redraw a tapout~ object by scripting
>>> (have to say how many taps, and what are their times...) Is there any
>>> better solution ?
>>>
>>> best
>>>
>>> f.e
>>> -- 
>>> f.e chanfrault | aka | personal computer music
>>>>>>>>>> http://www.personal-computer-music.com
>>>>>>>>>> |sublime music for a desperate people|
>>>
>
> ----
> Steven M. Miller
>
> Associate Professor of Contemporary Music
> College of Santa Fe
> Contemporary Music Program
> 1600 St. Michaels Drive
> Santa Fe NM 87505
> http://pubweb.csf.edu/~smill 
> (505) 473-6197
>
> SFIFEM Atrium Sound Space OVOS
> http://sfifem.csf.edu http://atrium.csf.edu 
> http://pubweb.csf.edu/~smill/ovos.html 
>
>
>
> ------------------------------------------------------------------------
>
>

-- 
f.e chanfrault | aka | personal computer music
> >>>>>> http://www.personal-computer-music.com
> >>>>>> |sublime music for a desperate people|


IIRC the minimum delay time for tapin~/tapout~ (at least with feedback) can be no smaller than the MaxMSP vector size. This restriction can be circumvented in a custom designed external, so a multitap interpolating delay line object with internal feedback would be most useful.

> Yes, i know that tapout~ can take multiple arguments. But only since a 

> few days when, looking for how to achieve a bouncing ball delay, i 

> re-read the docs. Because there's not a shadow of this in the help 

> files... Anyway, i erase/rewrote the tapout~ each time i need to change 

> the number of taps, but i still wonder if there was something more sexy 

if the use of poly~ isnt sexy enough for you, then it is 

hard to suggest something which you will like.

almost everything is sexier than the use of scripting 

> Yes, i know that tapout~ can take multiple arguments. But only since a 
> few days when, looking for how to achieve a bouncing ball delay, i 
> re-read the docs. Because there's not a shadow of this in the help 
> files... Anyway, i erase/rewrote the tapout~ each time i need to change 
> the number of taps, but i still wonder if there was something more sexy 
> around.
>
> f.e

if the use of poly~ isnt sexy enough for you, then it is 
hard to suggest something which you will like.

almost everything is sexier than the use of scripting 
for DSP objects!


Quote: Eric Lyon wrote on Tue, 28 November 2006 14:19

> IIRC the minimum delay time for tapin~/tapout~ (at least with feedback) can be no smaller than the MaxMSP vector size. This restriction can be circumvented in a custom designed external, so a multitap interpolating delay line object with internal feedback would be most useful.

Quote: Eric Lyon wrote on Tue, 28 November 2006 14:19
----------------------------------------------------
> IIRC the minimum delay time for tapin~/tapout~ (at least with feedback) can be no smaller than the MaxMSP vector size. This restriction can be circumvented in a custom designed external, so a multitap interpolating delay line object with internal feedback would be most useful.
>
> Eric
----------------------------------------------------

Isn't teeth~ supposed to be that?
Mattijs


But, tell me if i'm wrong, changing the number of voices in a poly is 

not much handy 'cause you got glitches, do we ?

>> Yes, i know that tapout~ can take multiple arguments. But only since a 

>> few days when, looking for how to achieve a bouncing ball delay, i 

>> re-read the docs. Because there's not a shadow of this in the help 

>> files... Anyway, i erase/rewrote the tapout~ each time i need to change 

>> the number of taps, but i still wonder if there was something more sexy 

> if the use of poly~ isnt sexy enough for you, then it is 

> hard to suggest something which you will like.

> almost everything is sexier than the use of scripting 

But, tell me if i'm wrong, changing the number of voices in a poly is 
not much handy 'cause you got glitches, do we ?

Roman Thilenius wrote:
>
>> Yes, i know that tapout~ can take multiple arguments. But only since a 
>> few days when, looking for how to achieve a bouncing ball delay, i 
>> re-read the docs. Because there's not a shadow of this in the help 
>> files... Anyway, i erase/rewrote the tapout~ each time i need to change 
>> the number of taps, but i still wonder if there was something more sexy 
>> around.
>>
>> f.e
>>
>
>
> if the use of poly~ isnt sexy enough for you, then it is 
> hard to suggest something which you will like.
>
> almost everything is sexier than the use of scripting 
> for DSP objects!
>
>
>

Quote: f.e wrote on Tue, 28 November 2006 09:45

> But, tell me if i'm wrong, changing the number of voices in a poly is 

> not much handy 'cause you got glitches, do we ?

just make 10 copies of [fe.10-tap.~mxb] so that you can turn 

70 tapouts (and all the connections from and to them) off if 

you only need 30 taps for the current "preset" of your bouncing 

and about glitches: nothing makes more glitches than 

scripting, which can in some cases just chrash the runtime 

Quote: f.e wrote on Tue, 28 November 2006 09:45
----------------------------------------------------
> right :-)
>
> But, tell me if i'm wrong, changing the number of voices in a poly is 
> not much handy 'cause you got glitches, do we ?
>
> f.e

nah, not voices, building blocks. 
just make 10 copies of [fe.10-tap.~mxb] so that you can turn 
70 tapouts (and all the connections from and to them) off if 
you only need 30 taps for the current "preset" of your bouncing 
delay DSP.

and about glitches: nothing makes more glitches than 
scripting, which can in some cases just chrash the runtime 
or the hw driver. :)

Do you have an example of a script which will work in Max, but crash 

the runtime? Im not trying to be pedantic, as Im trying to hunt down 

On Nov 28, 2006, at 2:37 PM, Roman Thilenius wrote:

> scripting, which can in some cases just chrash the runtime

Do you have an example of a script which will work in Max, but crash  
the runtime? Im not trying to be pedantic, as Im trying to hunt down  
a few potential bugs.

> scripting, which can in some cases just chrash the runtime


btw, i have a whole set of poly "objects" around tapping 

delays. i would share it, but it is not "final" enough yet.

why i am telling you about it is this: it is possible to

create _poly~s containing the tapouts - but connect them 

all to only one tapin in the _root level of the patch.

btw, i have a whole set of poly "objects" around tapping 
delays. i would share it, but it is not "final" enough yet.

why i am telling you about it is this: it is possible to
create _poly~s containing the tapouts - but connect them 
all to only one tapin in the _root level of the patch.

As scripting will always interupt audio, its better to use a poly~...

f.e wrote:
> i'm working on delays and, before understanding all the pitfalls of 
> building one in C, i made one in max patching. To have a multitap delay, 
> the workaround i found is to remove/redraw a tapout~ object by scripting 
> (have to say how many taps, and what are their times...) Is there any 
> better solution ?

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com

Quote: Mattijs wrote on Tue, 28 November 2006 16:22

> Quote: Eric Lyon wrote on Tue, 28 November 2006 14:19

> > IIRC the minimum delay time for tapin~/tapout~ (at least with feedback) can be no smaller than the MaxMSP vector size. This restriction can be circumvented in a custom designed external, so a multitap interpolating delay line object with internal feedback would be most useful.

Quote: Mattijs wrote on Tue, 28 November 2006 16:22
----------------------------------------------------
> Quote: Eric Lyon wrote on Tue, 28 November 2006 14:19
> ----------------------------------------------------
> > IIRC the minimum delay time for tapin~/tapout~ (at least with feedback) can be no smaller than the MaxMSP vector size. This restriction can be circumvented in a custom designed external, so a multitap interpolating delay line object with internal feedback would be most useful.
> >
> > Eric
> ----------------------------------------------------
>
> Isn't teeth~ supposed to be that?
> Mattijs
>
----------------------------------------------------

Quote: Eric Lyon wrote on Wed, 29 November 2006 00:28

Quote: Eric Lyon wrote on Wed, 29 November 2006 00:28
----------------------------------------------------
> > Isn't teeth~ supposed to be that?
> > Mattijs
> >
> Except that it's not multitap. 
>
> Eric
>

But for shorter than the vectorsize, the word multitap is already 

missleading. For the asked use, tapin~/tapout~ within a poly should be 

able to do whatever one could ever need...

I place a receive object inside the poly~ for the tapin~ connection and 

have a standard fadein/out to prevent clicks for switching on/off voices...

For communication I use midinote with the delaytime as note value...

Eric Lyon wrote:
> Except that it's not multitap. 

But for shorter than the vectorsize, the word multitap is already 
missleading. For the asked use, tapin~/tapout~ within a poly should be 
able to do whatever one could ever need...

I place a receive object inside the poly~ for the tapin~ connection and 
have a standard fadein/out to prevent clicks for switching on/off voices...
For communication I use midinote with the delaytime as note value...
Works as a charm...

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


Quote: vade wrote on Tue, 28 November 2006 13:39

> Do you have an example of a script which will work in Max, but crash 

> the runtime? Im not trying to be pedantic, as Im trying to hunt down 

anything which disconnects and connects signal cables,

especially when more thann 1 or 2 at a time.

but i assume it widely depends on operating system, I/O

hardware, and audio settings (I/O vector size and stuff)

Quote: vade wrote on Tue, 28 November 2006 13:39
----------------------------------------------------
> Do you have an example of a script which will work in Max, but crash  
> the runtime? Im not trying to be pedantic, as Im trying to hunt down  
> a few potential bugs.

anything which disconnects and connects signal cables,
especially when more thann 1 or 2 at a time.

but i assume it widely depends on operating system, I/O
hardware, and audio settings (I/O vector size and stuff)


>>> IIRC the minimum delay time for tapin~/tapout~ (at least with 

>>> feedback) can be no smaller than the MaxMSP vector size. This 

>>> restriction can be circumvented in a custom designed external, so 

>>> a multitap interpolating delay line object with internal feedback 

An alternative might be a bank of delay~ objects. Feed the same 

signal into each delay~ but set them to different delay lengths.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

>>> IIRC the minimum delay time for tapin~/tapout~ (at least with  
>>> feedback) can be no smaller than the MaxMSP vector size. This  
>>> restriction can be circumvented in a custom designed external, so  
>>> a multitap interpolating delay line object with internal feedback  
>>> would be most useful.
>>>
>>> Eric
>> ----------------------------------------------------
>>
>> Isn't teeth~ supposed to be that?
>> Mattijs
>>
> ----------------------------------------------------
>
>
> Except that it's not multitap.

An alternative might be a bank of delay~ objects. Feed the same  
signal into each delay~ but set them to different delay lengths.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

>>>> IIRC the minimum delay time for tapin~/tapout~ (at least with 

>>>> feedback) can be no smaller than the MaxMSP vector size. This 

>>>> restriction can be circumvented in a custom designed external, so a 

>>>> multitap interpolating delay line object with internal feedback 

>>> ----------------------------------------------------

> An alternative might be a bank of delay~ objects. Feed the same signal 

> into each delay~ but set them to different delay lengths.

> Peter Castine +--> Litter Power & Litter Bundle for Jitter

> Interface Building for |home | chez nous|

> Max/MSP Extremely cool |bei uns | i nostri|

Peter Castine wrote:
>>>> IIRC the minimum delay time for tapin~/tapout~ (at least with 
>>>> feedback) can be no smaller than the MaxMSP vector size. This 
>>>> restriction can be circumvented in a custom designed external, so a 
>>>> multitap interpolating delay line object with internal feedback 
>>>> would be most useful.
>>>>
>>>> Eric
>>> ----------------------------------------------------
>>>
>>> Isn't teeth~ supposed to be that?
>>> Mattijs
>>>
>> ----------------------------------------------------
>>
>>
>> Except that it's not multitap.
>
> An alternative might be a bank of delay~ objects. Feed the same signal 
> into each delay~ but set them to different delay lengths.
>
> --------------    http://www.bek.no/~pcastine/Litter/    -------------
> Peter Castine             +--> Litter Power & Litter Bundle for Jitter
>                                Universal Binaries on the way
> iCE:  Sequencing,  Recording &
>       Interface  Building  for                   |home    | chez nous|
>       Max/MSP   Extremely cool                   |bei uns |  i nostri|
>       http://www.dspaudio.com/                   http://www.castine.de
>
>
>

i've done this, but got few strange results :

- first, the [in 1] seems to receive messages adressed to [in~1] (i got 

an error gnagnghgngaga "flonum (connected to the [in 1] ): doesn't 

understand "tapconnect" when nobody talks to it).

- Then the out~ 1 & 2 don't seem to output what they're supposed to. 

Having an [out~ 1] & an [out~ 2], i have to create a message [out 3] 

(instead of simply say [out 1]) for the second msp outlet to let a 

- i send a list of 'target n, ' ('target 1, 1000' then 'target 2, 

1500', and so on) to specify different delays for the tapout~s inside, 

and the only signal i got is a fucking 0ms undelayed one (i mean, when i 

send a signal, it plays it like a bloody sfplay~, in time, with no delay 

f**k (not you of course, the poly~ object which i still hate to the end 

> btw, i have a whole set of poly "objects" around tapping 

> delays. i would share it, but it is not "final" enough yet.

> why i am telling you about it is this: it is possible to

> create _poly~s containing the tapouts - but connect them 

> all to only one tapin in the _root level of the patch.

- first, the [in 1] seems to receive messages adressed to [in~1] (i got 
an error gnagnghgngaga "flonum (connected to the [in 1] ): doesn't 
understand "tapconnect" when nobody talks to it).

- Then the out~ 1 & 2 don't seem to output what they're supposed to. 
Having an [out~ 1] & an [out~ 2], i have to create a message [out 3] 
(instead of simply say [out 1]) for the second msp outlet to let a 
signal pass thru (!!).

- i send a list of 'target n, ' ('target 1, 1000' then 'target 2, 
1500', and so on) to specify different delays for the tapout~s inside, 
and the only signal i got is a fucking 0ms undelayed one (i mean, when i 
send a signal, it plays it like a bloody sfplay~, in time, with no delay 
at all...).

f**k (not you of course, the poly~ object which i still hate to the end 
of times).

Roman Thilenius wrote:
>
>> nah, not voices, building blocks. 
>>
>
>
> btw, i have a whole set of poly "objects" around tapping 
> delays. i would share it, but it is not "final" enough yet.
>
> why i am telling you about it is this: it is possible to
> create _poly~s containing the tapouts - but connect them 
> all to only one tapin in the _root level of the patch.
>
>
> -110
> --
> http://vst-mac.info/
>
>

If the signal vector delay of feedback is a problem for your needs, I 

would suggest you use poly~ with a signal vector size of 1. Then 

delay lines