Posted
Hi.
I'd like to suggest a few tweaks that would enhance snippet playback in the direction of one-touch ease and efficiency, particularly when dealing with a set of complex snippets where they are really meant to only be played one-at-a-time.
The current possible workflow for this I call "sweep, schedule, launch". It works, it just takes more time and motion than would be ideal.
I'm calling the circled icon above the "sweeper" (it looks like a broom to me).
Current steps for "sweep, schedule, launch" are:
1. Prepare any currently playing snippet(s) so they will all stop at the designated moment. Do this by left-clicking on the broom.
2. Schedule the snippet(s) you want to take over by right-clicking on its arrowhead.
3. Make the switchover by left-clicking on the launch icon (rocketship)
Sticking with the existing paradigm and functions, here are the additions I propose:
Auto-Sweep - when engaged, step #1 of the above sequence becomes unnecessary. The system, in effect, pushes the sweep button for you after every Launch (or launch equivalent).
Auto-Launch - when engaged, left-clicking on any snippet arrowhead performs the Launch operation, no need to make a separate trip to the Launch icon to click on it.
if both Auto-Sweep and Auto-Launch are enabled, the effect is "one-click exclusive single snippet playback", this is the goal.
If neither Auto-Sweep nor Auto-Launch are enabled, operation remains exactly as it is now.
I believe adding Auto-Sweep and Auto-Launch as described would result in full accommodation for most accurate and efficient playback of either simple or complex snippets in exactly the desired fashion for either/both cases.
Finally, (and please advise if any of these are already available) keyboard shortcuts for Sweep, Auto-Sweep, Dice, Launch, and Auto-Launch would all be useful and welcome.
Thanks!
Thu, 2025-01-02 - 18:28 Permalink
You don't need the launch button. If you are fast enough, you just left-click all the snippets you want to launch and they will take over at the next sync point (1m usually) automatically.
The right-click(s) plus launch sequence is only needed if you want to spend some time thinking about which snippets you want to launch.
Keyboard shortcuts would be useful, yes.
Thu, 2025-01-02 - 19:25 Permalink
Hi.
My observation is that if the Launch button is not used, then the Sweep will not take place.
Just left clicking arrowheads leaves prior running snippets still running.
IOW, to actually take over (stop all old, start all new) you must currently use the Launch button.
I'm observing this right now. Are you observing differently?
Thu, 2025-01-02 - 20:40 Permalink
I haven't used the broom in a long time. Remembered it wrong.
Auto-launch sounds useful. Any left-click launches the particular snippet plus all pending snippets that have been armed/disarmed with right-click (or the broom).
However, it takes some concentration and focus to do this right. While you schedule several snippets you must be aware in advance which will be the last one. I find it more intuitive to just schedule any number of snippets and launch them when I'm done.
Auto-sweep ... not sure.
Scheduling snippets should be as intuitive as possible. I'd rather not have different modes. AFAIK Ableton Live doesn't have multiple modes and became wildly successful for its Clips. A single mode should work for at least 80% of users. There is a solution but it needs more thought.
Thu, 2025-01-02 - 21:23 Permalink
A bit buried in my paragraph is the highest level goal:
"one-click exclusive single snippet playback"
No, Ableton does not have this, and that's a major problem/limitation with Ableton! Synfire can be better.
Maybe they will follow you!
--
Here is the use-case:
Each (complex) snippet is a fully realized song section. (Could be a full verse or chorus, could be a few bars - length does not matter and is up to the user).
They are meant to be played back one-at-a-time.
We simply want to select the playback order dynamically in realtime, with a single mouse action or keyboard key touch (or, ultimately, touch on a remote control surface).
Super simple concept, right?
Now, the broom and rocket buttons, and the way they divide their operation does take a moment to wrap one's head around, but it is flexible for what it does. I'm fine with it myself, for exactly what it is.
But we ALSO need : "one-click exclusive single snippet playback" (OCESSP).
Since OCESSP is by definition very different from the entire existing snippet playback design, there's no avoiding different "modes" in some way, shape or form.
The suggestion I wrote above was designed to keep everything that currently exists and adds on to it in a way that would let the user configure for either OCESSP operation or legacy (current) operation as needed or desired.
However, if you want to re-imagine the snippet playback UI entirely, go for it.
Just please realize that we
a) need the functionality we have now, esp. for dealing with playing many simple snippets at once, and
b) need the new OCESSP functionality alongside of it.
c) added: one-hand, one-touch operation is highly desirable
Thanks.
Thu, 2025-01-02 - 22:01 Permalink
I note the the Dice operate conceptually as a combined "sweep, schedule, launch", just merely that the schedule part is done (with some randomization) by the system instead of by the user.
It would certainly be possible to have a 4th icon (e.g. "1" or "Xcl") dedicated to set the Snippets Matrix to perform OCESSP.
You could even put the two "manual" icons (broom and sweep) next to each other, and the two "automatic" icons (Dice and "1") next to each other, maybe even render the two pairs in two different colors.
As you say:
There is a solution but it needs more thought.
Please dream on it! ;^)
Fri, 2025-01-03 - 14:12 Permalink
Hi.
One-handed operation for OCESSP is an important goal here.
One-hand, one touch.
A proliferation of alt- keys (used with the mouse) will always fall short of that.
Hence, I suggest that switchable/toggle-able modes should not be reflexively considered as evil.
Also, icons that change color (and/or picture) can often serve a double-purpose as both one-touch controls and as status/mode indicators. So, here also, matching an effective tool with a given job can make sense.
Suggested design goals:
Changing modes should be one-hand, one-touch.
Operating a given mode should be one-hand, one-touch.
Definition and operation of modes to be a simple as possible, consistent with meeting the goals.
--
To accommodate both OCESSP and current behavior, some aspect of "mode" must exist because the operational actions differ. It's just a question of whether the mode is a "mode of behavior required of the user" (as using an Alt- key, or not, every time!), or whether the mode is remembered by the program until the user chooses to change it. The later is much more desirable, IMO.