On Freitag, 8. März 2019 05:45:38 CET Jacek Roszkowski wrote: > This is my second approach to handling polyphony. I'm not submitting > it into bugzilla, since I'm not sure if that's the way it should be > resolved. It works for me, but it's not thoroughly tested even for my > needs.
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 understand that you already invested more time in this feature than you wanted to. So my suggestion: just open a report for now and attach your patch so it won't get lost, and a bit later I might come up with an alternative implementation to achieve this feature, which won't happen in the next couple weeks or so though. 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: http://doc.linuxsampler.org/sfz/ ( http://svn.linuxsampler.org/cgi-bin/viewvc.cgi/doc/docbase/sfz/ ) But as you can see it is also not more than a start ATM. > 6. signed/unsigned mismatch for sfz opcodes > These are declared as int, even though most of them (according to > http://www.sfzformat.com/legacy/) are unsigned with values from 0 to 4 > Gb (4294967296), and the "end" opcode can even take values from -1 to > 4 Gb. This spec is weird, since 32 bit ULONG_MAX is 4294967295. It's > not such a big deal, but the patch depends on off_by default value to > be -1, since AbstractVoice requires iKeyGroup to be non-zero to > processGroupEvents() 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 > 7. My reference sfz engine is ARIA 1.933 with sforzando VST plugin. > Unfortunately it behaves differently with note_polyphony opcode. My > patch releases oldest voices first. ARIA releases most recent ones. I > think it's a bug, not a feature, because if there are two regions Yes, that's definitely not an appropriate behaviour. I don't know the ARIA engine much. But I know that many players don't have any real voice stealing algorithm implementation. So many engines simply pick random old voices instead of caring about to pick appropriate old voices. > I've sent it here to get your opinion, but I suppose I'm not going to > develop my concerns further, only bugfixing. No problem. I appreciate your effort though! CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
