Nicholas Davis

 problems before and went to the forums and noticed the history of its troubleshooting. Rest assured, I would not be making this post unless I'd looked at as many 

forum posts as I could. I have also looked at the 

 tutorial and many youtube videos. I'm having trouble seeing what the problem is. I have a feeling that because there is no midi, the busy signal will not work.

I've tried many different ways of telling 

 instance 1 that it is busy and to not accept any messages until the 

 is finished with its playback, and nothing has worked. I got so desperate that I tried sending a message from within 

 a different voice after one has been triggered, which is just silly. I've tried 

; and signal from the actual sample directly to 

 because I am going to be switching each sample when I feel like it, and envelope tracking each sample to an 

 object seems like a lot more work (also more CPU usage) than needed in this scenario: maybe I'm wrong.

For context: I'm trying to make a simple sampler that will be used as a drum machine. It has a 

 object, controlled by a metro, that is sending bangs to 

 objects for each instrument. For simple, forum troubleshooting sake I have only included one instrument. The reason I want to use 

 for each instrument is because I want each sample to play out in its entirety when triggered so that there are no clicks, among some other things (unless I tell it to!). So when a bang comes into the 

 it should mark the instance as busy, unmute the instance, play the sample, then mute the instance and mark it as not busy. All the while should another bang come in while the first instance is busy, it will use the second instance, and so on. This has not been the case, and I am at my wit's end trying to figure out why not.

Any help would be much appreciated. For now I'm going to move on to other things about the patch that I should work on before I lose my mind!

comment

toggle

number~

gate~

message

play~

button

number

out~

thispoly~

loadbang

flonum

inlet

combine

info~

buffer~

waveform~

meter~

poly~

dac~

sig~

polybuffer~

pipe

outlet

unpack

matrixctrl

counter

metro

panel

Note: the main, upper level patch is using a 

. The main, upper level patch has a few settings loadbanged, and I have included a sample kick.wav file in this post for convenience.

Apologies, I know poly~ is a sore spot on this forum. I've had poly~ problems before and went to the forums and noticed the history of its troubleshooting. Rest assured, I would not be making this post unless I'd looked at as many poly~forum posts as I could. I have also looked at the poly~ tutorial and many youtube videos. I'm having trouble seeing what the problem is. I have a feeling that because there is no midi, the busy signal will not work.

I've tried many different ways of telling poly~ instance 1 that it is busy and to not accept any messages until the play~ is finished with its playback, and nothing has worked. I got so desperate that I tried sending a message from within poly~ to the upper level, back to poly~ to tell it to target a different voice after one has been triggered, which is just silly. I've tried mute 0, 1; mute $1; toggle directly to thispoly~; sig~ directly to thispoly~; and signal from the actual sample directly to thispoly~. I have not tried using ADSR because I am going to be switching each sample when I feel like it, and envelope tracking each sample to an ADSR object seems like a lot more work (also more CPU usage) than needed in this scenario: maybe I'm wrong.

For context: I'm trying to make a simple sampler that will be used as a drum machine. It has a matrixctrl object, controlled by a metro, that is sending bangs to poly~ objects for each instrument. For simple, forum troubleshooting sake I have only included one instrument. The reason I want to use poly~ for each instrument is because I want each sample to play out in its entirety when triggered so that there are no clicks, among some other things (unless I tell it to!). So when a bang comes into the poly~ it should mark the instance as busy, unmute the instance, play the sample, then mute the instance and mark it as not busy. All the while should another bang come in while the first instance is busy, it will use the second instance, and so on. This has not been the case, and I am at my wit's end trying to figure out why not.

Note: the main, upper level patch is using a polybuffer~ for the play~ object inside poly~ poly_kick. The main, upper level patch has a few settings loadbanged, and I have included a sample kick.wav file in this post for convenience.

Hello,
Apologies, I know poly~ is a sore spot on this forum. I've had poly~ problems before and went to the forums and noticed the history o

-poly~-problems-with-busy-no-midi-sampler-drum-machine-using-play~-inside-poly~-with-polybuffer~-will-not-stop-using-instance-1

Apologies, kick.wav did not attach. Attempting again here... Hmm not working. Here is a link to a 

Apologies, kick.wav did not attach. Attempting again here... Hmm not working. Here is a link to a freesound.org kick.

the delay 10 should not be needed. it will only cause trouble when a second trigger comes to the same instance while the first one still plays.

eventually you want to add an envelope later, based on line~, then you have a superb bang flag coming from there to indicate the voice is no longer busy.

what i dont see is that you´d stop new input from beeing received when the instance is busy?

it is not a bad approch to use a poly patch for different samples that way, but in my opinion it would be easier to use "target" and do all the voicemanagement outside the poly (i always say that at this point. sometimes i think that i think that people might think it is more right when you keep repeating the same propaganda. but "target" is sooo cool.)


the delay 10 should not be needed. it will only cause trouble when a second trigger comes to the same instance while the first one still plays.

eventually you want to add an envelope later, based on line~, then you have a superb bang flag coming from there to indicate the voice is no longer busy.

what i dont see is that you´d stop new input from beeing received when the instance is busy?

it is not a bad approch to use a poly patch for different samples that way, but in my opinion it would be easier to use "target" and do all the voicemanagement outside the poly (i always say that at this point. sometimes i think that i think that people might think it is more right when you keep repeating the same propaganda. but "target" is sooo cool.)


Fair enough, perhaps I was being a little too thorough with that. My intent was to allow the sample to play out entirely before turning off the DSP inside 

I am not opposed to a final envelope of some sort in 

 I've been hesitant to add some kind of envelope because of two reasons. 1 the samples I will be using in this are all drum samples, which is to say that their amplitude ends with a fade out (for the most part, I think.. ;-). 2 adding another function, like an envelope (line~ or ADSR), within 

 adds to CPU usage (instatiation is a slippery slope!) and seeing as how the sample itself has a fade out, then it should not be necessary. If it comes to a point where I need to, I definitely will. But for now the clicking is absolutely coming from voice management.

 over any other bang? Is it simply because it is 'quantized' with the end of the playback? If so, I should think the 

 when playback has ended would be just as effective.

, restricts any outside signal to its instance within 

, audio signal, etc) aside from administrative messages, e.g. 

, etc. Maybe this has been my mistake this whole time? If I mark 

, I still have to provide some logic to stop a signal from coming into the instance? That seems to defeat the purpose of even having a 

 status in the first place, no? If I have to build it myself, what does 

This is very good advice, and I am going to give this a shot when I next work on the patch (probably tomorrow heh). My brain is buzzing with ideas from this advice!

Thanks for the response Roman! I really appreciate you taking the time to take a look at the issue. I'll report back when I've had another look at it by your suggestions.

Fair enough, perhaps I was being a little too thorough with that. My intent was to allow the sample to play out entirely before turning off the DSP inside poly~ to avoid clicks from sudden mute.

eventually you want to add an envelope later, based on line~, then you  have a superb bang flag coming from there to indicate the voice is no  longer busy.

I am not opposed to a final envelope of some sort in poly~. I've been hesitant to add some kind of envelope because of two reasons. 1 the samples I will be using in this are all drum samples, which is to say that their amplitude ends with a fade out (for the most part, I think.. ;-). 2 adding another function, like an envelope (line~ or ADSR), within poly~ adds to CPU usage (instatiation is a slippery slope!) and seeing as how the sample itself has a fade out, then it should not be necessary. If it comes to a point where I need to, I definitely will. But for now the clicking is absolutely coming from voice management.
I'm not sure what you mean by "...a superb bang flag coming from [line~] to indicate the voice is no longer busy." What is superb about a bang from line~ or ADSR over any other bang? Is it simply because it is 'quantized' with the end of the playback? If so, I should think the bang sent from play~ when playback has ended would be just as effective.

It is my understanding that the thispoly~ object, once marked as busy, restricts any outside signal to its instance within poly~ (bang, audio signal, etc) aside from administrative messages, e.g. voices $1, target $1, etc. Maybe this has been my mistake this whole time? If I mark thispoly~ as busy within poly~, I still have to provide some logic to stop a signal from coming into the instance? That seems to defeat the purpose of even having a busy status in the first place, no? If I have to build it myself, what does busy even do?

...in my opinion it would be easier to use "target" and do all the voicemanagement outside the poly...

in poly, only midi messages support voice stealing etc etc.

So either use that, or then address the voices using

Another problem you have is double triggering.

because you call getcolumn $1 twice, check -1 and swing output.

I guess most of the sounds are rather short, but if you want to use

ride or crash cymbal, you need as many voices as needed,

and to avoid clicking if all -1 voice are busy fade out

in poly, only midi messages support voice stealing etc etc.
So either use that, or then address the voices using
target message.
Another problem you have is double triggering.
unpack i i i i .... to sel 1 triggers twice
because you call getcolumn $1 twice, check -1 and swing output.
I guess most of the sounds are rather short, but if you want to use
ride or crash cymbal, you need as many voices as needed,
and to avoid clicking if all -1 voice are busy  fade out
next before it needs to get retriggered.
Report status of voices :


the rest you can figure out
simplified poly_kick


"Is it simply because it is 'quantized' with the end of the playback?"

yep, just like that outlet from play~, which you can also trust. you are using it right, it was made for exactly that, no safety delay required. :)

"It is my understanding that the thispoly~ object, once marked as busy, restricts any outside signal to its instance within poly~ (bang, audio signal, etc) aside from administrative messages"

maybe i wasnt looking closely enough. the busy state will indeed do this, as long as stealing is off, too. i thought you were using mute 1 mute 0, cant remember now.

however, i think this design doesnt make much sense here. 

a sequencer application or a human user wont know when the sample has finished playing. what if he decides to play another note? then what? then it wont be triggered if played too early? what kind of instrument behaviour is that? :)

i would either allow to retrigger the play~ - or make 8 voices for each sample. or both.

yes, that makes mute groups a bit more complicated, but it will be a bit more "realistic" overall.

(just ignore what i said when you already have a good reason to design it like that.)

in the "pro version" of that you would use 2 voices, and whenever a new trigger comes in, the seocnd voice will start playing while at the first one, which also still plays, a "release envelope" is started" whose fixed lenght c an be shorter or longer than the time left to play - with certain consequences for what happens when the third note on comes in.

(it is probably better to ingore that, too. i am just talking to myself)

mute 1 mute 0... only turns audio on and off. but which is normally enough for this kind of stuff. just like you did it with that [t a b c d 0] (for a "mute 0" to thispoly~) it will always work as intended. (ideal would be high priority input, but that is only for "optimization" trolls like me)


"Is it simply because it is 'quantized' with the end of the playback?"

yep, just like that outlet from play~, which you can also trust. you are using it right, it was made for exactly that, no safety delay required. :)

"It is my understanding that the thispoly~ object, once marked as busy, restricts any outside signal to its instance within poly~ (bang, audio signal, etc) aside from administrative messages"

maybe i wasnt looking closely enough. the busy state will indeed do this, as long as stealing is off, too. i thought you were using mute 1 mute 0, cant remember now.

however, i think this design doesnt make much sense here. 
a sequencer application or a human user wont know when the sample has finished playing. what if he decides to play another note? then what? then it wont be triggered if played too early? what kind of instrument behaviour is that? :)
i would either allow to retrigger the play~ - or make 8 voices for each sample. or both.
yes, that makes mute groups a bit more complicated, but it will be a bit more "realistic" overall.

(just ignore what i said when you already have a good reason to design it like that.)

in the "pro version" of that you would use 2 voices, and whenever a new trigger comes in, the seocnd voice will start playing while at the first one, which also still plays, a "release envelope" is started" whose fixed lenght c an be shorter or longer than the time left to play - with certain consequences for what happens when the third note on comes in.

(it is probably better to ingore that, too. i am just talking to myself)

mute 1 mute 0... only turns audio on and off. but which is normally enough for this kind of stuff. just like you did it with that [t a b c d 0] (for a "mute 0" to thispoly~) it will always work as intended. (ideal would be high priority input, but that is only for "optimization" trolls like me)


[poly~] problems with busy. No midi. Sampler (drum machine) using [play~] inside [poly~] with [polybuffer~]. Will not stop using instance 1.