On Montag, 25. Februar 2019 16:56:33 CET Jacek Roszkowski wrote: > <schoeneb...@linuxsampler.org> napisał(a): > > Then it might make sense to extend the existing key group handling code by > > optionally using the number provided by the patch. You might want to have > > a > > look at AbstractEngineChannel::HandleKeyGroupConflicts(). > > That method was my starting point, but I don't understand exactly > what's going on inside:
No problem, that's what this email ist is for. > // send a release event to all active voices in the group > RTList<Event>::Iterator itEvent = > ActiveKeyGroups[KeyGroup]->allocAppend(pEngine->pEventPool); > *itEvent = *itNoteOnEvent; > > This is my understanding > 1. there's a new event created using pEventPool memory > 2. it's appended to the ActiveKeyGroups at the KeyGroup index > 3. it's set up as the copy of the note on event, which caused this > voice to be launched All correct. > 4. why does it make all active voices in the group killed? I suppose > it's because the condition itEvent->Param.Note.Key != HostKey() is > true in sfz::Voice::ProcessGroupEvent, but I don't understand the > logic behind Ok, looks like you already found all relevant code sections for this feature, up to the final point where the voices are finally released in Voice::ProcessGroupEvent(), the latter method is implemented by each one of the 3 engines separately by the way, so that way it is possible to implement behaviour individualization regarding key group conflicts for the individual engines/formats. When Voice::ProcessGroupEvent() is called, it is passing a copy of the original note-on event which triggered the key group conflict. The comparison with the key number you mentioned is currently intended to let it a) kill notes on other keys (of the same key group), but b) never kill notes on the same key. And when you look at the implementation of that method implementation for the gig engine (src/engines/gig/Voice.cpp), you find a fat comment where we did not agree how this behaviour should be precisely. In that source code comment I wrote that it would not sound natural for drumkits to kill notes of the same key. We had a discussion about that on the mailing list as well (probably even several). And that's already the main reason why I don't think that it would make sense if you would address this issue separately in the sfz engine's source files alone. Because this is an important issue that we will need to address for all engines, because the precise behaviour of key group conflicts needs to be configurable one day for all engines, not just for sfz. > It's a good question whether extending key group handling is the way > to go. I don't know if there are similar capabilities in gig or sf2 > formats. In sfz format group opcode makes a group "exclusive" only if > off_by is set to the same value. Setting group without off_by doesn't > mute consecutive hits, but it does with polyphony=1. However, default > polyphony is not 1, but is limited to sampler maximum voice limit (at > least in sforzando vst player). If you can point out similar > properties in other engines, i'll refactor the patch to use more > common code. I'm going to implemet As you might imagine, the sf2 engine is not really a priority, but for the gig engine there will definitely be new configuration options being added. They don't exist with the original gig format, but we are extending the original gig format all the time for important new features, and these options you are talking about are very important ones for natural drumkits. From what you described so far, I don't see why you would need to open a separate concept to the existing key group conflict concept. As far as I can see it, the key group concept just would need some additional options for allowing what you want to do. Additionally to what you are working on (amount of voices per key group, and whether a key group shall use a soft release or rather harsh kill), there will most probably be other options in future as well, for instance what to do on sustain pedal? Should a pressed sustain pedal ignore key group conflicts, yes/ no? Still sceptical? :) CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
