Thanks for the 3.2.0-beta.12 update! The new {{spoken}} notation is an incredible feature, being able to separate what’s displayed on the Setlist UI from what is actually spoken by the TTS engine makes the interface so much cleaner.
Now that this spoken content is decoupled from the visual section names, it would be amazing if we could also unlock flexible lead times for the count-in attributes, beyond the current 2-bar limit ([c:1] and [c:2]).
In many songs, melody pickup lines (anacrusis) or longer spoken instructions start 3 or 4 bars before the actual downbeat of the next section. Fixed 1-bar or 2-bar lead times are often too short for the full phrase to finish speaking smoothly before the music hits.
It would be extremely helpful to allow any custom numeric bar count, such as [c:3], [c:4], [c:5], or higher, without a hardcoded 2-bar limit (including precision beat positioning like [c:3.1] or [c:4.3]).
This would allow the Sections track to be fully self-sufficient and handle everything on its own, eliminating the redundant rework of maintaining both a Sections track and an additional +OSC [/cues/say] track just to work around current limitations.
I think that for your situation, having a separate OSC track is the best way to go since it allows you to place cues freely. To make this easier, I’m thinking of adding a +CUES track format that would work similar to the “+OSC [/cues/say]” track format, but allows AbleSet to generate all cues beforehand so they can be played immediately the first time they’re reached.
Let me know what you think, I’m looking forward to your reply!
Thanks for explaining! That approach makes total sense regarding performance and zero latency.
I just have two quick questions regarding how this workflow would operate in practice:
Two Tracks Workflow: Does this mean we would still need to maintain two separate tracks: (strictly for the Setlist UI/navigation) and (for flexible cue timing)? Is there any possibility of allowing to handle both natively in the future, or is separating them the intended design for stability?Sections+CUESSections
Audio Export / Bounce: Currently, we cannot export audio from a"+OSC [/cues/say]" track via Ableton’s native Audio Export because the TTS audio is synthesized outside Ableton’s audio engine. Since the new format will pre-generate the audio files on disk, will we be able to export/bounce those cues directly into an audio file (like we do with the Sections track)?
Yes, that would mean having two separate tracks since your extra cues aren’t sections, strictly seen. I think having both on one track isn’t the best way to go.
That should be possible. I’m thinking of also adding the ability to add a separate AbleSet Cues VST on these tracks so you could route different types of cues to different outputs. If no AbleSet Cues plugin is available on the track, it will speak the text on any other available track.
Adding a dedicated AbleSet Cues VST is a game-changer! Being able to route different cues to specific outputs and easily export/bounce those tracks natively inside Ableton solves the biggest limitation of the current /cues/say method.
However, looking closely at the practical workflow, having two separate tracks would actually introduce extra rework for my use case. Let me explain with a quick example:
Current Workflow (Single Track Idea):
On bar 8, I create a single MIDI clip on the Sections track named Verse {{Verse B. Drums and vocals enter heavy}}. This keeps the Setlist UI clean (showing only “Verse”), while the TTS speaks the full instruction. But because of the [c:2] limit, the 2-bar lead time isn’t enough for that long phrase to finish before bar 8 hits.
New Workflow (+CUES Track):
I would have to create a clip on the Sections track for “Verse”, and then create a second clip on the +CUES track with “Drums and vocals enter heavy” positioned 3 or 4 bars early. While this gives total positioning flexibility, it doubles the work of creating and managing clips across two tracks for the same section.
For 90% of songs, standard [c:2] works fine, but for those specific sections with longer cues, having extended directives like [c:3], [c:4], or [c:5] directly on the Sections track would be much faster and avoid duplicating clips.
That said, your +CUES track idea completely solves the flexibility and audio routing limitations—it’s just an extra step in the arrangement process. I really appreciate you taking all these workflow nuances into consideration!
