For the last couple of months - since i've bought a small midi keyboard actually - i've been busy rebuilding my main synth to be playable with midi. Before i always played everything from a pc keyboard and my synth had a fixed amplitude envelope. However i wanted the midi version for each voice to have it's own amp envelope. This seemed more difficult than i had forseen, since the envelope actually influences the voice engine. Now after quite some work i have something which works rather well (an occasional voice gets stuck sometimes). I started this before asking around how other people would implement this, or is there some kind of object around which takes care of all this hassle?

If someones interested in the patch i'll post it, although i still have fix some issues first.

d.

I'm not too clear on what the issue is (maybe a patch will help clarify), but what do you mean by "the envelope influences the voice engine?" Each voice should just have it's own envelope generator. It sounds like you have an envelope outside of the actual voices.

Ok, i was not clear enough i guess. Indeed, each voice has it's own envelope. I'm having 16 voices right now (being it a synth, a sampler or any kind of instrument which wants to be polyphonic). Above the actual voices sits something (what i call a voice engine) which assigns the incoming notes to available voices. The main question for the engine is: when is a voice available? In my design a voice is only available when its entire envelope is finished (also the release). But that makes it tricky because now the voicing engine actually needs to know about each voice's envelope, something which i didn't want. That's why a had to write a lot of plumbing code to handle all of this. So what i wanted to know is if there are useful objects to help with this and i also wanted to find out how others would implement this. Or am i making things too complex. Tonight I'll strip the engine out of the patch and post it, that will probably make it clearer.

I know there is the [poly] object which does voice allocation, but it seems to me that it doesn't take the envelope release into account to allocate a voice (note off means the voice is available again, even when there's a 30 second release).

I hope this makes a bit more sense now.

I'm not sure I understand your problem. If you're not using [poly] but the synth is polyphonic (16 voices) maybe you intend that you already have one voice made by 16 oscillators. If so, just make an abtraction of that and duplicate it n times (10 if you want to use all your fingers). Then use poly. Thake a look at help browser Pure Data/7.stuff/synth/1.poly.synth.pd
Sorry if the problem is a different one.

Mmm, apparently i'm still not clear enough.

[poly] does voice allocation, but how does it know when a voice is free?

In my solution each voice (yes, i have 16 of them, each with its own amplitude envelope and audio workings inside, but these are not abstractions, yet) should be allowed to traverse its entire amplitude envelope (for now its simple, there's attack, hold and release). Only when the entire envelope has finished, the voice is thrown back into the free-voice pool for a new allocation (unless the same note is played before the envelope has finished). That's why i've written my own version of [poly] i guess. Because it seems to me that [poly] allocates a voice when a note-on is received, and deallocates when a note-off is received. Like said my implementation is working fine, but it took quite some work and now i was wondering if there are other useful alternatives, approaches.

There's a few tools in the rjlib, have a look at [u_makepoly], [u_robinpolymono] and [u_robinpoly]

For example in [u_makepoly] you can set voice stealing as an argument

https://github.com/rjdj/rjlib

i just checked those, and they still only work for note on/off messages, not for release time as well.

Dom, looks like you're sailing uncharted waters, perhaps.

it's certainly possible to do what you want, and it sounds like you have it (almost) working ok. So, if you just post what you've done, we can have a look at it and see where we might be able to eliminate those final glitches.

I think Kurzweil use a good implementation that's supposed to reassign the voice that will cause the least audible cutoff. I guess that means they sample the instantaneous value of the amplitude envelope (i.e. a [snapshot~] for each voice) and pick the lowest value. Of course if you have a complex multi-stage envelope, a low value may not mean that it's reached the final release stage, so you could account for that as well...

Here's the patch in its most simple form (so far hopefully). It's a simple sinewave synth which demonstrates the voice allocation engine. I've tried to annotate as much as possible to make things clear. My goal is to have the engine so, that the actual audio-generation sub-patches could be implemented as an abstraction. Right now I just implement one instance, copy it 15 times and draw some cables. This is a bit cumbersome, but then I have easy access within each voice of all the global parameters (for this version there are no parameters of course). So for me it remains to be seen if the advantage of going abstractions would be easier than my current approach.

Have fun with it,

d.

http://www.pdpatchrepo.info/hurleur/synth.pd

I unfortunately don't have time to really dig into your patch just yet (though I am really interested to see how you went about it), but I'm thinking it might not be too difficult to use [poly 16 0] to prevent voice stealing. To make sure you still finish releases of current notes, you could have something in each voice that will prevent a new note from retriggering if it is still in its release stage and just send a note-off for that new note back to [poly] to free it back up. As long as you don't double-trigger the same note (which shouldn't happen with a MIDI keyboard), I don't think you will run into problems.

dom, i just made a random note generator to test with, and have not got a single stuck note under any circumstance yet.

what you should do, is jut mess round with your keyboard until you reproduce the stuck note problem, and then try to find the exact condition that causes it.

otherwise, i reckon this seems to work ok?

http://www.pdpatchrepo.info/hurleur/synth-check.pd

Maelstorm, thanks for the suggestion. If one day you would implement this that would be great to compare. Mod, thanks for testing it out. I suspect that 'hung notes' usually occur when I'm developing the actual audio voices, because then I only hook up 1 voice, but when I actually trigger more then 1 note all the others will get stuck. I just thought this could be an interesting framework for others who want to build a cpu friendly polyphonic velocity sensitive instrument, that's why I'm looking at abstractions to completely isolate the audio implementation of the rest of the framework.