Hi guys. I put together an adsr envelope abstraction a while ago to get the functionality I wanted where each segment of the envelope could have its own specified exponential curve. It generally works great, except that when I play glissandi in the synth patch I'm building one note appears to get stuck on every time if I play up to amount of polyphony. I assume there's something going on with the voice stealing, but I can't exactly see what or how I could fix it. Y'all have any advice? I'm attaching the whole synth patch in case it helps to look at it in context. The abstraction is adsr.pd which references expLine.pd to make the curves.

Thanks for any help you can give with this!
Little Ringy.zip

Playin around, still pretty baffled. This behavior happens fairly infrequently, and is hard to reproduce on demand, but happens certainly enough that I'll encounter it a handful of times in any session of messing around with the synth. I wonder if maybe something external to Pure Data could be making it miss the midi note off event? The only thing I can see from looking at the adsr patch that would account for the behavior is not receiving the note off message to trigger the release, but I could be wrong. Sometimes it seems like it might happen more when the computer is under more strain, so maybe something with the midi to usb interface I use is responsible? Hard to quantify.

Also willing to take advice on replacing the slightly hacky way I'm using threshold~ with something more correct. Though I don't think the threshold~ object is contributing to the problem itself.

Hi! I looked at your adsr quickly. To narrow down if the problem is voice stealing, you could set your poly object to
{poly 6 0} and see if the problem goes away

Recently, I've just been setting my note stealing to off (0). But I remember back when I was working on other synths a long time ago I had some kind of scheme set up to process a stolen note differently. If setting the args to 6 0 makes the problem go away I could dig up some old stuff and see if I can figure out what I was doing

Having taken a quick look at your patch, I would say that my instinct agrees that the use if threshold~ is a likely culprit. The fact is that in the control realm, relying on pd to poll numbers fast enough to catch the 0.0001 decimal every time is a risky move. Even in the audio signal realm, such a task could be tricky when there are lots of notes being thrown at it. If you want to generate an ADSR with specific transients for each and trigger them with line~, I find the better way is to write the envelopes to a table with the last index of the table set to a value that will trigger the next set of parameters to the line object, until finally the release ends at zero. In other words, there would be a table for each, A, D, S and R. the last value of the table would always be set to some number that is outside of the range of your line~ that will get picked up by a sel or route object to trigger the next line until the release. When a noteon message is receiveed, it knocks your line of tables down like dominos. It does not rely on every tiny fractional decimal point value being polled, so its more likely to complete the sequence without getting stuck. Instead of sensing the signal for a tiny window, it simply reads off a precalculated list of values in order, and if it skips a few values for lack of speed, it will still end up at the next set of instructions. I hope I explained this well. I can do an example if you need. Outputing the tables to another line object can help smooth out choppy transitions if there are any. hope that helps.

Thanks for all the suggestions about this. I'm going to keep plugging away and report back when I find the fix, though I'll probably ultimately take th8a's suggestion of using tables for the envelope segments so I can eliminate the hacky way I'm using threshold~.

I've been building in lots of print and env~ objects to try to figure out where the exact problem is. I believe I've successfully determined that it's NOT the voice stealing or the threshold~ object. All the midi info seems to be getting routed to the right voices, and the decay segment seems to be playing correctly even in notes that get stuck on, which it's the purpose of the threshold~ object to trigger.

For some reason the midi off control seems to be sent to the envelope, but it isn't registering it. I can fake another off event with messages and the envelope releases normally at that point. I've been playing around with a slightly more complex synth patch that uses the same envelope abstraction, which is actually a little more helpful because it has multiple oscillators for each voice, and they do NOT all seem to get stuck on at once. In fact, the base oscillator seems to be the only one that gets stuck on, whereas the 2 suboscillators do not, which suggest to me that I might have screwed up the construction of how the oscillator patch interacts with the envelope. But I'm still only closer to figuring it out; I haven't had much time to mess around with it lately.

Okay here's another conundrum: the help file for threshold~ says that it triggers when it EXCEEDS the target value, which is why I have the .9999 nonsense in the adsr patch. Further testing suggests that it actually triggers when it HITS the target value. I'm attaching a small patch to demonstrate. Is this just an infelicity in the help file, or am I overlooking something?thresholdTester.pd

It's much nicer to have it bang on the target value, as I can use it like a signal-based select, rather than having to specify a target value that is vanishingly close to the actual end value of the attack segment.

@catkisser666 In the help file for extended it says "equals or exceeds". It looks like that is still the case, and it was not copied over to the Vanilla help.