Both CYCLE and INTELL are early digital vintage time-stretch algorithms suitable for the vintage style TAL Sampler. Clean results w/o artifacts can't be achieved.pummel wrote: Sun Aug 10, 2025 2:52 pmI'd like to augment goal sound design with real time TAL sampler stretch mode, but only if it can be done cleanly using CYCLE or INTELL.
TAL Sampler - discussion
-
- KVRAF
- 2069 posts since 8 Feb, 2013 from Switzerland
-
- KVRAF
- 7356 posts since 19 Apr, 2002 from Utah
..
Vendor‑Dependent Copy Protection: Customers lose. Pirates win.
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
(Also: I'm Accused of lying about Linux—it boots, runs my pro audio workflow, stays stable, updates--though yearly dismissed as “niche”. Yet I'm the deluded one.)
-
- KVRer
- 14 posts since 5 Jun, 2014
Hi there! I have a suggestion about the recent microtuning support through MTS-ESP. This is extremely cool! 
Thanks for implementing it TAL folks. Here's an addition that could make it even better, and which is hopefully easy to implement.
Let's assume the patch/layer/etc. has sample regions S₁...E₁, S₂...E₂ and so on. Disregard velocity etc. for now. Then, in the standard tuning mode, given a MIDI note N, the sampler picks sample(s) k for which Sₖ ≤ N ≤ Eₖ.
Now, as far I'm aware from testing, currently under a custom tuning when a MIDI note N is given, the sampler still chooses the same set of samples. This works alright when the tuning has 12-ish notes per octave that are relatively uniformly spaced— for example, many historical Western tunings —but has sample mapping wrong frequency-wise in cases the tuning is, for example, 19 notes per octave, or has notes bunched up, like something we'd get if we add chromatic notes to "enharmonic" Hellenistic-time scales. That's because a MIDI note range S...E is an obvious proxy for some frequency range [s; e], and it is this range that should remain invariant under any keyboard retuning.
Thus, a suggestion for an alternate sample choosing procedure for an input MIDI note N. Knowing the frequency f this note is now tuned to, calculate a "fractional MIDI note" ñ by unapplying the standard MIDI frequency mapping: ñ = 69 + 12 log₂(f / 440 Hz). Then use ñ instead of N when checking to which regions Sₖ...Eₖ the note belongs, only now check if Sₖ − 0.5 ≤ ñ ≤ Eₖ + 0.5 to avoid unmapped gaps. (Also likely choose one of these inequalities as < instead of ≤ to avoid very rare clashes of regions; choosing both as < will again make for (as rare) unmapped cases compared to the original mapping.) That's practically everything that needs to do to ensure we're choosing by frequency.
I know samples are chosen not just by note, but also by its velocity and maybe other things. I haven't got into the thick of things with TAL-Sampler myself yet to list which exactly, but I'm more than sure there should be no non-obvious or complicated additions to this algorithm. For example if there's keytracking, it's also natural to use ñ instead of N for its input, because again in keytracking MIDI note is a proxy for the actual frequency, on which modulated parameters depend, instead of a (proxy for a) physical keyboard key.
Now, to compare with others, a frequency approach like this should already be implemented in Shortcircuit XT (open source) and Decent Sampler, but alas no other microtunable sampler out there, to my knowledge (for example, TX16Wx supports MTS-ESP but doesn't pick samples by frequency either, if nothing's changed while I wasn't looking). In SCXT this is the only mode; in DS there are two modes: legacy and this one. So TAL-Sampler can just add a new shiny mode together the current one as an opt-in option to not harm users' existing projects. It is useful to save the choice between "by-MIDI-note" and "by-frequency" globally as a default for new plugin instances — and save each instance's choice in the DAW saved state, but not save it with patches themselves on saving a patch (tuning way doesn't have anything to do with the tuning-agnostic patch).
Trying to condense this proposal to have it a quick read, I might've worded something too laconic, so I'll answer all questions about implementation. (Well, probably except "but still why": it behaves more correctly/nicely for the user of tunings, there's no other argument but a hope there's some extra time to implement this.)
[I tried to consistently denote integer quantities in upper-case (S, E, N) and fractional (whichever the implementation) quantities in lower-case (f, s, e, ñ); and k is just a sample identifier.]
Thanks for implementing it TAL folks. Here's an addition that could make it even better, and which is hopefully easy to implement.Let's assume the patch/layer/etc. has sample regions S₁...E₁, S₂...E₂ and so on. Disregard velocity etc. for now. Then, in the standard tuning mode, given a MIDI note N, the sampler picks sample(s) k for which Sₖ ≤ N ≤ Eₖ.
Now, as far I'm aware from testing, currently under a custom tuning when a MIDI note N is given, the sampler still chooses the same set of samples. This works alright when the tuning has 12-ish notes per octave that are relatively uniformly spaced— for example, many historical Western tunings —but has sample mapping wrong frequency-wise in cases the tuning is, for example, 19 notes per octave, or has notes bunched up, like something we'd get if we add chromatic notes to "enharmonic" Hellenistic-time scales. That's because a MIDI note range S...E is an obvious proxy for some frequency range [s; e], and it is this range that should remain invariant under any keyboard retuning.
Thus, a suggestion for an alternate sample choosing procedure for an input MIDI note N. Knowing the frequency f this note is now tuned to, calculate a "fractional MIDI note" ñ by unapplying the standard MIDI frequency mapping: ñ = 69 + 12 log₂(f / 440 Hz). Then use ñ instead of N when checking to which regions Sₖ...Eₖ the note belongs, only now check if Sₖ − 0.5 ≤ ñ ≤ Eₖ + 0.5 to avoid unmapped gaps. (Also likely choose one of these inequalities as < instead of ≤ to avoid very rare clashes of regions; choosing both as < will again make for (as rare) unmapped cases compared to the original mapping.) That's practically everything that needs to do to ensure we're choosing by frequency.
I know samples are chosen not just by note, but also by its velocity and maybe other things. I haven't got into the thick of things with TAL-Sampler myself yet to list which exactly, but I'm more than sure there should be no non-obvious or complicated additions to this algorithm. For example if there's keytracking, it's also natural to use ñ instead of N for its input, because again in keytracking MIDI note is a proxy for the actual frequency, on which modulated parameters depend, instead of a (proxy for a) physical keyboard key.
Now, to compare with others, a frequency approach like this should already be implemented in Shortcircuit XT (open source) and Decent Sampler, but alas no other microtunable sampler out there, to my knowledge (for example, TX16Wx supports MTS-ESP but doesn't pick samples by frequency either, if nothing's changed while I wasn't looking). In SCXT this is the only mode; in DS there are two modes: legacy and this one. So TAL-Sampler can just add a new shiny mode together the current one as an opt-in option to not harm users' existing projects. It is useful to save the choice between "by-MIDI-note" and "by-frequency" globally as a default for new plugin instances — and save each instance's choice in the DAW saved state, but not save it with patches themselves on saving a patch (tuning way doesn't have anything to do with the tuning-agnostic patch).
Trying to condense this proposal to have it a quick read, I might've worded something too laconic, so I'll answer all questions about implementation. (Well, probably except "but still why": it behaves more correctly/nicely for the user of tunings, there's no other argument but a hope there's some extra time to implement this.)
[I tried to consistently denote integer quantities in upper-case (S, E, N) and fractional (whichever the implementation) quantities in lower-case (f, s, e, ñ); and k is just a sample identifier.]
-
- KVRer
- 11 posts since 16 Oct, 2017
Feature request: save/load presets for the resampler section, independently of other settings (sample mappings, FX, modulations, etc.). Basically nest TAL-DAC's preset browser inside TAL-Sampler's resampler section.
I guess you could say that is already possible, simply load TAL-Sampler's default preset, modify the resampler to one's liking and save the preset. But you still can't, say, use an existing preset and quickly swap out different resampler settings to try out different sounds without losing all your settings outside the resampler.
Right now I can leave the resampler untouched and send TAL-Sampler's output to TAL-DAC, where I can easily try out TAL-DAC's factory presets or save/load my own presets, but IMHO the resampler section would benefit from its independent preset browser. No worries if Patrick doesn't like this idea or think it's not worth the effort though, at least I have this current workflow
I guess you could say that is already possible, simply load TAL-Sampler's default preset, modify the resampler to one's liking and save the preset. But you still can't, say, use an existing preset and quickly swap out different resampler settings to try out different sounds without losing all your settings outside the resampler.
Right now I can leave the resampler untouched and send TAL-Sampler's output to TAL-DAC, where I can easily try out TAL-DAC's factory presets or save/load my own presets, but IMHO the resampler section would benefit from its independent preset browser. No worries if Patrick doesn't like this idea or think it's not worth the effort though, at least I have this current workflow
-
- KVRAF
- 1755 posts since 26 Apr, 2019 from Netherlands
Still not possible?xrch wrote: Sat Dec 13, 2025 12:00 pm Feature request: save/load presets for the resampler section, independently of other settings (sample mappings, FX, modulations, etc.). Basically nest TAL-DAC's preset browser inside TAL-Sampler's resampler section.
I guess you could say that is already possible, simply load TAL-Sampler's default preset, modify the resampler to one's liking and save the preset. But you still can't, say, use an existing preset and quickly swap out different resampler settings to try out different sounds without losing all your settings outside the resampler.
Right now I can leave the resampler untouched and send TAL-Sampler's output to TAL-DAC, where I can easily try out TAL-DAC's factory presets or save/load my own presets, but IMHO the resampler section would benefit from its independent preset browser. No worries if Patrick doesn't like this idea or think it's not worth the effort though, at least I have this current workflow
5 years ago:
Hi Patrick,
About the Resampler section of TAL Sampler, there are five DAC modes which you can customize. Is it possible to save and load those customized DAC modes like you can with TAL-DAC?
Thanks for the email. It's not possible. Maybe we can add a DAC lock
some time. It's something we have on our TODO list.
Best regards,
Patrick
TAL Software GmbH
-
- KVRer
- 11 posts since 16 Oct, 2017
I'm pretty sure it's not yet possible. A DAC lock feature could work too, although I'd say it's a small subset of what saving/loading resampler presets can do. Glad to know Patrick is interested in the idea though!
-
- KVRist
- 64 posts since 5 Apr, 2004 from Fighting against the Bias that I feel for others!
Can anyone confirm if their sampler demo or full version also doesn't automate the Loop/sample start and end of each layer? They appear as option to automate in the demo, but don't do anything.
-
- KVRian
- 886 posts since 14 May, 2014
Very cool! comparing to the original song, there's a lot more high-frequencies. I think if you were to further. The original song sounds a lot more "low-passed" without sounding dull. If the processing were to be taken much further, it might sound closer.SeleDreams wrote: Fri Jul 04, 2025 10:37 pm I find it very cool how TAL Sampler even allows to reproduce how the Nintendo DS sounded. By tweaking its resampling settings, we can get sounds very close to DS games. I even went further and sampled some original instruments Pokemon Black and White used (PlugSound Pro Accoustic Piano and SampleTank String Orchestra) and played a song from the games and it sounds very accurate.
You can hear how it sounds here https://soundcloud.com/seledreams/unwav ... c20ca27118
It's playing "Unwavering Emotions" from Pokemon black and white
-
- KVRian
- 528 posts since 27 Oct, 2004
Am I actually the only one who is bothered by this visual bug (the text being cut off)? This is in there since years now...
-
- KVRAF
- 1721 posts since 7 Dec, 2017
You have good eyes. I've never noticed that.fladd wrote: Sun Jan 18, 2026 10:29 pm Am I actually the only one who is bothered by this visual bug (the text being cut off)? This is in there since years now...
-
- KVRian
- 528 posts since 27 Oct, 2004
Oh weird. Maybe it's a Mac thing. But the mistake is also in the official screenshots on the TAL website
