Floating Point

I've made a little patch that uses poly~ for its standard purpose, and it works fine. It is used to play back percussion samples, with one unique buffer per MIDI note. The percussion samples are unusual in that they are quite long (up to 15 seconds duration). They are actually recordings of single strikes of various bells, some of which ring for a long time; one bell sample per pitch.

So the problem is that if I have some number of voices assigned to the poly~ object and a pitch (midi note) is played again while its previous strike is still ringing, poly~ will assign a new voice to the repeated note, resulting in the effect of having two bells playing in unison instead of the same bell being struck twice.

I need to have such a note assigned to the previous busy voice so that it cuts off the previous note if that note is still being played, (even if it is not repeated directly after, but has other pitches played in between the two same-pitch repetitions).

Hope this makes sense. Any suggestions? I can post a small eg patch to illustrate if someone asks.

I've made a little patch that uses poly~ for its standard purpose, and it works fine. It is used to play back percussion samples, with one unique buffer per MIDI note. The percussion samples are unusual in that they are quite long (up to 15 seconds duration). They are actually recordings of single strikes of various bells, some of which ring for a long time; one bell sample per pitch. 

So the problem is that if I have some number of voices assigned to the poly~ object and a pitch (midi note) is played again while its previous strike is still ringing, poly~ will assign a new voice to the repeated note, resulting in the effect of having two bells playing in unison instead of the same bell being struck twice. 

poly-and-non-contiguous-repetition

How about something simple like this (using target message).

if I understand correctly, your solution implies I would have to have the number of voices for poly~ the same as the number of sample-buffers used (39 altogether), so that each sample is effectively 'hard wired' to a specific voice.

I guess I was blinded by the ability of poly~ to dynamically assign voices to samples, whereas I actually don't need that feature at all.

Correct me if I'm barking up the wrong tree.

Thanks Zachary, I think that may work--
if I understand correctly, your solution implies I would have to have the number of voices for poly~ the same as the number of sample-buffers used (39 altogether), so that each sample is effectively 'hard wired' to a specific voice.

Correct me if I'm barking up the wrong tree.
T


Quote: Terry McDermott wrote on Sat, 10 January 2009 19:57

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

> Thanks Zachary, I think that may work--

> if I understand correctly, your solution implies I would have to have the number of voices for poly~ the same as the number of sample-buffers used (39 altogether), so that each sample is effectively 'hard wired' to a specific voice.

You got it. That will solve your problem, and I think that's exactly what Zachary was talking about.

Quote: Terry McDermott wrote on Sat, 10 January 2009 19:57
----------------------------------------------------
> Thanks Zachary, I think that may work--
> if I understand correctly, your solution implies I would have to have the number of voices for poly~ the same as the number of sample-buffers used (39 altogether), so that each sample is effectively 'hard wired' to a specific voice.
>

You got it. That will solve your problem, and I think that's exactly what Zachary was talking about.


Cheers, thanks for the confirmation. It's always a pleasant surprise when a max patch is actually _easier_ to build than first expected.

Cheers, thanks for the confirmation. It's always a pleasant surprise when a max patch is actually _easier_ to build than first expected.
Terry


poly~ and non-contiguous repetition