monty_mcmont

I'm writing a sampler that enables the user to stop all samples that are playing at any time. The sampler uses a buffer~ object to store an audio sample, and play~ objects contained within the voices of a poly~ object to play the audio polyphonically. The sampler normally operates in monophonic mode, though the user can optionally activate polyphony.

I am having two problems with this patch.

1) In monophonic mode, I load an audio sample into the buffer~ object, and click the green 'Play' button, and the audio plays as it should. The mutemap correctly updates itself to show that one voice is un-muted, as expected. However, when I use the red 'Stop' button to stop all of the voices, then I click 'Play' again, the sample does not play the first time I click 'Play'. The mutemap appears to show that the first voice is un-muted, as expected, but there is no audio. Can anyone explain why the sample doesn't play until I click 'Play' a second time?

2) In polyphonic mode, the same problem occurs, however I have to click 'Play' the same number of times as there are voices in the poly~ before any audio comes out. The mutemap shows that the correct voices are un-muted, therefore I suspect that this is related to problem 1. Curiously though, the live.gain~ meters show an increasing audio level as I click 'Play' repeatedly, although there is no audio coming out. Can anyone explain why this is happening?

I suspect that these problems are related to muting of the poly~ voices. If the poly~ patch is prevented from muting voices, by removing the red connection between the 'mute 1' message and thispoly~, the sampler plays as expected, however the live.gain~ meters always show a level (why, I don't know!). When I switch between samples this causes an audible click, which is unacceptable, so simply disabling muting inside the poly~ object isn't an option.

I have created the following model patches to illustrate the problem. I am starting to tear out what little of my hair remains, so any help with this would be very gratefully received! I have attached a .zip file to this post, and I have also copied & pasted the compressed patches below, for your convenience.

Poly~ object, called poly_with_stop_inlet.maxpat:

poly-muting-misbehaviour-s

You're not sending a busy state as well as a mute state to [thispoly~] in the subpatch which might cause problems. You are also sending the messages to the first voice three times due to not patching your [counter] correctly: the third outlet sets a toggle rather than just sending a bang, try connecting a [print] object to see what i mean.

Cheers for your tip about my misuse of [counter]; I have added a [select 1] object between the third [counter] outlet and the '1' message, which is now only banged once when the counter restarts.

My poly~ patch doesn't send busy state messages to thispoly~, no. I didn't see the need because I'm not using the automatic voice allocation via the 'note' message. If you change the 'mute 0' message to 'mute 0, 1' and the 'mute 1' message to 'mute 1, 0', the patch behaves identically so I'm pretty sure that the lack of busy state messages isn't causing the problems... thanks for your suggestions though!

Cheers for your tip about my misuse of [counter]; I have added a [select 1] object between the third [counter] outlet and the '1' message, which is now only banged once when the counter restarts.  

My poly~ patch doesn't send busy state messages to thispoly~, no. I didn't see the need because I'm not using the automatic voice allocation via the 'note' message. If you change the 'mute 0' message to 'mute 0, 1' and the 'mute 1' message to 'mute 1, 0', the patch behaves identically so I'm pretty sure that the lack of busy state messages isn't causing the problems... thanks for your suggestions though!


Could this be related to the mute behavior I discovered recently?

https://cycling74.com/forums/profile.php?id=6769

Hey EMV, thanks for your helpful message. I had read your thread but I didn't think it was relevant to my patch because I'm not using global muting; the stop messages that are being sent to the poly~ object halt the play~ object in each voice, and then mute the voice from inside the poly~ object. However, I gave it a second look and realised that this issue may be related.

I experimented with sending a global 'mute 0, 0' message to the poly~ object after I'd sent the 'stop' message. This partially fixes the problem. It solves issue 1) and makes the 'Play' button work as desired in monophonic and polyphonic modes. However, now that the voices aren't properly muted the live.gain~ meter seems to get 'stuck' after the 'Stop' button is hit, leading to undesired clicking when the sample changes. This is a show-stopper for this patch, and there must be a way to sort this out, but I'm still baffled! Does anyone have any ideas?

The code for the amended parent patch is below; I've coloured the parts that I've added in orange for clarity.

Poly~ muting misbehaviour :-S