> Ok, I have reviewed your patch. There are several issues with your suggested > patch, some which you already pointed out, but also you are doing things which > are not real-time safe, and overall it simply looks like more changes than > actually required.
I think that there's no need for a voice to release itself and in the third iteration a public pure virtual function in AbstractVoice implemented in derived classes should be enough. The decision about releasing a voice can be made in EngineChannelBase (like in the patch) without group processing queue (which in my opinion is counter-intuitive with sfz format's group and off_by opcodes. > And one important thing: Please also describe (or provide links) in the report > how the new sfz opcodes shall behave exactly in your opinion. Because I am not > using sfz much. So I don't know the common behaviour of existing sfz opcodes > of other players. And good (free) documentation about sfz is still a bit > sparse. For the latter I once started this: I will submit it. > I don't think that's an issue at all. I don't expect anybody to have a demand > of so many key groups. You probably barely find an instrument with more than > 88 > key groups. And for the negative issue on our internal implementation side: > for that purpose we do have the optional<> template class, which behaves > (almost) identical to its equal named template class from the boost library > and STL17: > > http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/linuxsampler/trunk/src/common/ > optional.h?view=markup I think later on I can convert sfz engine to use this class and unsigned ints where appropriate to make linuxsampler more compatible with the spec (that's the only reason). I was using far more than 88 groups in my drumkit instrument because of no polyphony support. Imagine a ride cymbal hit, choose one zone (bow) out of three, multiply it by velocity layers (8) and in each layer there's a group of 4 round robin regions * 2 samples (overhead and room). It's 72 groups for ride cymbal. And there are 16 layers for snare, and positional sensing :) Now I can put all ride samples in one group, choke it with another off_by group and manage concurrent voices by note_polyphony (let's say 2) with note_selfmask=on which is great for cymbal hits, but setting polyphony to 6 for a group allows me to save resources. > No problem. I appreciate your effort though! Maybe in some (long?) time I will share the final result - something like a DIY poor man's Pearl Mimic Pro. _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel