Posted
Hi,
The new 'One Snippet Playback Mode' (OSPM) in SF3 works great when we click on the Snippets matrix with the mouse. This let's us have a set of multi-instrument snippets in the matrix and switch between them (always one-at-a-time) with a single mouse click. One-handed, one-touch action - wonderful! (and a great prelude to enabling footswitches and controllers)
I notice, however, that the Snippets Dice do not seem to respect 'One Snippet Playback Mode' (OSPM).
IOW, if I roll the Dice then more than one MI snippet will still schedule and playback (unless other measures have been taken, e.g. locks and probabilities).
It would be superb for the Snippets Dice to also respect 'One Snippet Playback Mode' (OSPM).
Thanks!
Do., 20.11.2025 - 12:33 Permalink
If you want mixed snippets to be mutually exclusive you need to put them all in a single group. The point of having multiple groups is that they can be combined at the same time.
For example, you could have a group for drums, percussion and bass. And another for multiple string instruments or other embellishments. But if you if you have snippets that use all instruments, they need to go in the same group.
When multiple mixed groups are involved and only one snippet is allowed to be picked, it gets mathematically interesting. All those snippets are assumed to be one "virtual" group that somehow combines all probabilities. That becomes unintuitive and confusing quickly.
Single Snippet Playback Mode is really just a convenience that spares you clearing the schedule manually. The dice are for making many selections at once which are difficult to handle manually.
If you want only a single random snippet, why not just just click on one (without thinking too much)?
Do., 20.11.2025 - 15:53 Permalink
For example, you could have a group for drums, percussion and bass. And another for multiple string instruments or other embellishments.
Yes, one could have MI snippets where each is "less than full band", and then you'd typically want more than one of them upon randomization. This use-case has been anticipated and is accommodated currently, just as you describe.
Now, there is another use-case: each MI snippet is "full band", and in this case, you NEVER want more than one of them upon randomization.
Please let's accommodate both of these use-cases!
For randomizing (Dice) the "full band" case, there is nothing to compute re: probabilities. Just pick a different random MI snippet and play it, without regard to probability settings at all.
Consider also another scenario: a set of full-band MI snippets, and a set of SI snippets holding various single-line motifs, melodies or lead lines. In this case, we could easily want a dice roll to give us a) 1 random MI snippet, and b) 1 (or more!) random SI snippets.
Considering the actual use-cases, I now see that what would really fully serve here is:
MI Snippets OSPM: On/Off
SI Snippets OSPM: On/Off
I'll go out on a limb and say that technically, this is certainly do-able, and doing it would allow all users to work to their desired scenario. That is most-to-be-desired, IMO.
P.S. The immediate problem with work-around of putting alternatives in a single group is the 24 cell limitation. I typically work in chunks of 64 (8x8). What I very much want to standardize on (and show off via demo videos) is 8x8 SI snippets along with 8x8 MI (full-band) snippets. The real-estate is there for this, it is easy to layout, easy to see, easy to understand, and will map most excellently (someday) to 8x8 external controllers.
Please consider this real-world plea! <g>
Fr., 21.11.2025 - 09:34 Permalink
I get the idea. But introducing virtual groups (spanning multiple groups) with new selection behavior is a bit overkill merely for extending the number of alternative snippets in a group. Changing the underpinnings of the grid in this fundamental way is also not trivial (risk of breaking things). Let me explain.
The simple logic behind the grid is
- Groups are layers that can be combined (playing or silent)
- Snippets within a group are mutually exclusive (alternatives)
- A group with only Harmony in it has special status (e.g. SHIFT avoids a change)
This logic is easy to understand and use. 80% of users won't bother diving into the details and just play around with this and have fun. For the other 20% there are additional options (as you suggested):
- In Single Snippet Playback Mode the grid is cleared when the next one is scheduled
- Random selection can be limited to single-instrument groups or mixed groups
The new feature you are suggesting can already be accomplished:
- Put all multi-instrument snippets in one group
There's a maximum of 24 alternative "accompaniments". That may sound limited but think a moment how long it takes you to come up with that many "working and approved" accompaniments that are sufficiently distinct for their difference to be noticed. It's the same instruments, same (current) harmony, with only slight variations in rhythm, dynamics, phrasings, etc. I'd be hard pressed to come up with more than 12 for any finite set of phrases.
Remember that you can still have additional mixed groups for subsets of instruments.
If there is a potential problem to solve, it's merely capacity. I'd rather not complicate the grid with additional settings and fake "virtual" groups of groups, just to get more than 24 alternatives.
Fr., 21.11.2025 - 15:05 Permalink
Actually, not so very long.
Since different experiences and assumptions can arise from different working methods, let me explain mine, FWIW.
I begin with a "normal" set of N single-instrument (SI) groups (drums, bass, pad, synth, guitar) in an 8xN matrix (N = # of instruments).
Here is a picture with N = 5.
This is typical for me. It makes a "full band", and matches perfectly with a very extensive library I have prepared that has many Folders each with 8 drums performance, 8 bass performances, etc. (I created this via Imports, Magic of Synfire #1)
IOW, I can populate the 8xN with radically different compete sets of performances very quickly (just drop from the Library onto a Group). Magic of Synfire #2 here!
Why 8? Two reasons - 1) the library is built that way (from imports) 2) 8 is a sufficient number for core variations/sections in the compositions I build. (e.g. Intro, Verse1, Pre-Chorus, Chorus1, Bridge, Verse2, Chorus2, Outro - or similar)
Now, what really "makes" a section? Simple, the drums. Each section will use a different drum performance, and by doing so be instantly perceived.
OK, so now comes Magic of Synfire #3 - lock the Drums group to Perf #1 and roll the dice. Like it? If not, roll again. Like it? If so, drag to snippets memory A to capture the vetted MI snippet, then drag that to back into the matrix further to the right. Repeat x8. I now have 8 MI snippets based on Drum Perf #1.
Repeat the above for Drum Perfs #2 thru #8. I now have an 8x8 matrix of MI snippets. Typically about and hour to create, sometimes less. And lots of fun doing it!
--
For some purposes, I am now essentially done. I can now use recording or dragging to create Structure (Magic of Synfire #4), export to DAW, carry on as desired. This suffices when the final goal is only a fixed recording.
But there is also often another, different application/goal:
Semi-random Generative Live Performances (which are also themselves recordable)
You see, I now have 64 curated MI performances. All valid, all desired to be candidates in the mix. all present in the snippets matrix, ready-to-use. And I can replicate this workflow, quickly, again and again.
I simply need to select them one-at-a-time via randomization. I'm looking for Magic of Synfire #5 here!
Conceptually, this is very simple, and from the user POV, I think it's a fair ask - especially as it opens up an entire new field of application for Synfire.
--
I appreciate your explanation in the post above, it is clear and elegant. No doubt, every capability created for the users has a cost to it - in thought, time, effort, complexity, maintainability, etc. May I say that paying that cost is exactly what creates the "Magic of Synfire"? <g>
The distinction between All Groups/ SI Groups / MI Groups has already been (brilliantly!) shown to be deliverable wrt. 'Groups Selected Randomly'.
My hope here is no more or less than to extend that same distinction wrt. 'One Snippet Playback Mode'.
Fr., 21.11.2025 - 15:05 Permalink
So, if it never happens, can I still get to Semi-random Generative Live Performances ?
Yes, with hugely more work I can export every clip from Synfire, import them into Ableton or Bitwig, and (re)build it there. More applications, more expense (already paid in my case, but certainly not in the general case), more files, more complexity, MORE TIME, etc.
As opposed to just flipping an option in Synfire itself!
And then when (if <g>) people say "Wow, what's doing that?" the answer is "Ableton" or "Bitwig".
The answer could be (should be, IMO) "Synfire!".
Fr., 21.11.2025 - 16:48 Permalink
Thanks for taking the time to explain your workflow. You are taking a very systematic approach.
I didn't say it's not possible. It's just that a maximum of 24 snippets in a mixed group will have to suffice for a while. At the moment we don't have the capacity to zoom into this fractal (a redesign of how the grid allocates snippets randomly). The risk of breaking or overcomplicating things is real when there isn't enough time to focus on it. Snippets will eventually become the focus again.