Posted
Hi,
Am I correct in observing that the Snippets page always schedules changes within a column to take place on the next upcoming bar/measure boundary?
We really need options here! (e.g. 1, 2, 3, 4, 5, 6, 7, 8, length of snippet, length of progression)
I commend you to the flexibility of Ableton and Bitwig in this respect.
Mon, 2024-01-01 - 18:42 Permalink
Just now seeing this post. I made a similar recommendation in my response to another post you made. I suggested something like Follow Actions would be cool, which would include the option for one shots (at least that's how it works with Ableton).
Sat, 2024-06-01 - 15:05 Permalink
I'd just like to bump this topic.
Now that we can library our snippets and snippet memories, and repopulate the snippets grid at will from saved library items it's straightforward to fill in a snippets grid with excellent material.
Controlling that material precisely during playback, however, remains challenging. This situation would be greatly improved by syncing/quantizing snippets scheduling change-overs to known/selected musical structures (other than merely the next barline).
Sat, 2024-06-01 - 18:26 Permalink
Ableton Live works on static content (audio, MIDI) that can be split into small chunks easily.
Synfire renders melodic segments dynamically with voice leading. Segments may cross measure boundaries, etc. If this continuum is chopped into 1m pieces, it still sounds ok most of the time (as it is now). If you chop it into 1/4 or 1/8, you'll get, well, noticeably chopped output. The VL will be gone, melodies will be torn apart, etc.
Might work with simple EDM, but anything more musically expressive will suffer.
Sat, 2024-06-01 - 22:49 Permalink
Good to remember!
Please let me note though that the ad hoc suggestion of lengths:
(e.g. 1, 2, 3, 4, 5, 6, 7, 8, length of snippet, length of progression)
are all intended (my me anyway) to be 1 measure or longer.
Not shorter.
The goal is to postpone (when so configured) the next scheduled change until the currently playing snippet has run it's course.
So, for example, with a set of full-band mixed snippets, intended to be played back one-at-a-time, if I want to set them to always run for 4m, then I have 4m in which to trigger the next change, which will then take place on the 4m boundary (generally relative to the overall start point).
Or, considering Synfire's special harmony abilities, we could potentially configure for the next triggered change to take place at the point the current harmony runs out.
Sun, 2024-06-02 - 13:06 Permalink
The goal is to postpone (when so configured) the next scheduled change until the currently playing snippet has run it's course.
This causes queues to grow over time (per group), especially as snippets can be much longer than 1m. When more than one snippet in a group is armed to play next, you no longer know what's going on (and it's difficult to visualize).
You can simply wait until the desired snippet has run its course and then schedule the next. If the snippet is that important for the verse scheme or narrative (e.g. drums, harmony), you keep your focus on it anyway.
Additional modes of playback make sense, but choosing the right ones is not trivial.
Sun, 2024-06-02 - 15:04 Permalink
You can simply wait until the desired snippet has run its course and then schedule the next. If the snippet is that important for the verse scheme or narrative (e.g. drums, harmony), you keep your focus on it anyway.
This need is specifically what is desired to be eliminated - required capture of user's attention!
No way do I want to have to keep my attention on a snippet (or set of) for, say, 4m just to make sure that it does not end after some weird, odd, arbitrary, unintended # of repetitions.
I simply want that baby to play to a 4m boundary on it's own once I have triggered it, allowing my attention to go elsewhere as soon as I have made that triggering take place.
Sun, 2024-06-02 - 15:11 Permalink
Additional modes of playback make sense, but choosing the right ones is not trivial.
Yes, I agree with this.
But I think it is important to understand that alot of work (e.g. Ableton and Bitwig) has already been done in this respect, as to how things can or should work.
I'm not saying that their work needs to be exactly aped, or that there is no room for improvement or enhancement of it.
I would say though that the basics have been decently established in the clip-based DAW world, and will be directly understood by many users who have experience with those products if the same ideas are available in Synfire.
I would suggest the goal be to actually improve on Ableton and Bitwig by understanding their models thoroughly - adopting what is clearly fundamental and good, and enhancing beyond where they have left off.
Users who have Ableton and Bitwig familiarity can probably I think be very helpful with suggestions along these lines.