TAL Sampler / DecentSampler: fix boolean flags that were never honored#198
Merged
git-moss merged 4 commits intoJul 18, 2026
Merged
Conversation
Disabled groups were only skipped when the attribute was written as enabled="0". Presets in the wild write enabled="false" (e.g. drum kit libraries which switch between several kits via a drop-down in their UI where each kit is a group and only one is enabled). All those kits were converted stacked on the same keys and played simultaneously.
The flag is stored numerically (0/1) in TAL preset files - the creator of this application writes it that way as well - but it was read with a true/false text parser, so reverse playback was always lost. It is now read numerically like the other TAL flags (e.g. loopenabled, sampleenabled).
The loopEnabled attribute was never read: a loop was created purely from the presence of loop points, so a loop which the preset explicitly disables was still audible after conversion. An explicitly disabled loop now suppresses the loop points and the loop markers from the sample file chunks as well. Presets without the attribute behave exactly as before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #195 (contains its commit) - once that one is merged this PR reduces to two commits.
Both fixes are of the same class as #195 and were found by auditing all detectors for boolean attributes which only accept one lexical form:
reverseflag is stored numerically (0/1) like all other TAL flags - the creator of this application writes it that way as well - but it was read with a true/false text parser (Boolean.parseBooleanviaXMLUtils.getBooleanAttribute), which returns false for "1". Reverse playback was therefore always lost. It is now read numerically like the neighboring flags (e.g.loopenabled,sampleenabled).loopEnabledattribute was never read - a loop was created purely from the presence of loop points, so a loop which the preset explicitly disables withloopEnabled="false"was still audible after conversion. An explicitly disabled loop now suppresses the loop points and the loop markers from the sample file chunks as well. Presets without the attribute behave exactly as before (verified: a test preset with two zones converts to loop_mode=no_loop for the disabled one and an unchanged loop_continuous with the original loop points for the other).Related: #197 documents the same pattern for the Kontakt 5+ group mute/solo state, left as a design question.