seejayjames

I struggled with this for several hours and did learn some interesting things (about coll and table too), but still didn't figure it out. I'd like to be able to delay a noteon/noteoff a specified duration, an arbitrary number of times. I could of course create a massive series of mini-delay elements, and may well do that for other purposes (like being able to change velocity etc. for each). However, it would be neat to be able to say "I want this note to play 100 times, starting with a delay of 0 ms, with a delay of 150 ms for each iteration". (I don't care about having different delay lengths in this case, for simplicity.)

It certainly *seemed* like a counter that re-banged notes through a delay a certain number of times would do the trick. The problem was with the note-ons and note-offs, since overlapping notes seemed to behave badly.... need to send a note-off at the end of each delay interval before re-banging the note-on.

I'd love to hear what this could do--even with only about 8 delays I was getting some great stuff! (Working with the "hard-coded" multiple delay elements, that is... ;)

I'd love to hear what this could do--even with only about 8 delays I  was getting some great stuff! (Working with the "hard-coded" multiple delay elements, that is...  ;)

creating-an-arbitrary-number-of-delays

i was doing something like this last year. i ended up putting makenote 

and/or delay objects inside poly~ abstractions. events were time 

stamped in a sense. so that no new note would be retriggered with out 

first turning off the note at that pitch. unless the note was to be 

sustained, in that case the retrigger only prolonged the output of the 

see the patchwork in the JMSL demo for specifics. www.algomusic.com

i was doing something like this last year.  i ended up putting makenote 
and/or delay objects inside poly~ abstractions.  events were time 
stamped in a sense. so that no new note would be retriggered with out 
first turning off the note at that pitch. unless the note was to be 
sustained, in that case the retrigger only prolonged the output of the 
note-off. 
see the patchwork in the JMSL demo for specifics. www.algomusic.com


Thanks, will check it out and see what I can do. Interesting effects abound with them delays.... ;)

Thanks, will check it out and see what I can do. Interesting effects abound with them delays....  ;)

> It certainly *seemed* like a counter that re-banged notes through a

> delay a certain number of times would do the trick. The problem was

> with the note-ons and note-offs, since overlapping notes seemed to

> behave badly.... need to send a note-off at the end of each delay

> interval before re-banging the note-on.

You have to keep track of all the information, thats why [pipe] would

I made a [pipeall] abhaXion which would let you pipe also lists or any

other message. if you combine that with some kind of feedback you should

be able to deal with not-offs correctly, you would not need to just shut

off notes, the delayed notes could overlap and would have the same

Seejay James wrote:
> It certainly *seemed* like a counter that re-banged notes through a
> delay a certain number of times would do the trick. The problem was
> with the note-ons and note-offs, since overlapping notes seemed to
> behave badly.... need to send a note-off at the end of each delay
> interval before re-banging the note-on.

You have to keep track of all the information, thats why [pipe] would
serve better than [delay].
I made a [pipeall] abhaXion which would let you pipe also lists or any
other message. if you combine that with some kind of feedback you should
be able to deal with not-offs correctly, you would not need to just shut
off notes, the delayed notes could overlap and would have the same
duration as the original...

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

Creating an arbitrary number of delays