Snippet Bounce to Disk

That could be automated but which harmony to use?

Choices that immediately come to mind are 

1. whatever harmony (if any) is present in the (each) snippet being rendered.
2.  the last harmony in effect  (e.g. if you have previously clicked on, for example, a harmony-only snippet)

Would there be any other plausible possibilities?

Since it is possible that both of the above (or more) could apply (conflict), I suppose that automated audio export of snippets would require offering the user choice/configuration as necessary to resolve any ambiguities prior to the rendering.

In Synfire's music prototyping paradigm, the question "which harmony to use?" is one that always needs to be answered, somehow, by the user before anything anywhere can be played back or rendered.

There are various ways that the answer is provided in various contexts, right?

If the context of "bounce/render a snippet to disk" requires (or benefits from) the question being answered in a way that differs from (adds to) the currently available ways, so what?   The user will (have to) learn how to provide that answer just like they have had to learn how to provide the current answers.  It goes with the paradigm!

So, I'm hoping the posing of the question is not a dismissal of the idea/request.

It's very powerful that Synfire allows us to create complex snippets, save them in libraries, and then move them back to slots in the snippets matrix.   Being able to bounce/render these complex snippets for convenient further use in DAWs would really open up a wide area of productivity.   

Of course, some might want to do the same with simple one-instrument snippets.  To each his own!

Incidentally, easy interoperability of this sort would relieve Synfire of being asked to do things that DAWs already do very well and that Cognitone may not consider to be on the desired main line of further feature developments.  (BTW, is there any roadmap?)

If you wanted to, you could even go all the way to exporting a snippets matrix entirely and directly into Ableton Live format (which can also be ingested by Bitwig Studio).   This is what Novation Ampify Studio did, and this is a killer feature of that product.  I mostly mention it just because it has already been done, which is always encouraging in the face of what might be imagined to be a large/risky effort.

Hi,

The innovation of clip-enabled DAWS such as Ableton Live and Bitwig Studio, as beyond earlier linear-recording only softwares, lies explicitly in their implementations of the clip view matrix.  A clip, of course, can be a mere bar, a few bars, or a whole verse or chorus section of music.  Clips are, by definition, "static bricks" as you call them.  The particular and extensive capabilities of these DAW in working with these bricks has made them massively popular around the world for making all kinds of music.

The DAWs do not do what Synfire does.   Synfire does not do what the DAWs do.

The goal here IMO is smooth, efficient interoperabiity.   Artists will do a million things with tools that work together with a smooth, efficient workflow.  There is no upside in pre-judging the results.  The upside is all in enabling the possibilities.

The script that exports an audio file per snippet is very interesting.  Please say more!
 

With audio you need to have all clips match the same harmony and play for a multiple of that length.

Well, that in itself is a special case, albeit a very common one.   Certainly it is to-be-accommodated!

However, if my snippets are complex snippets, each with their own Harmony parameter, I think most of that is moot.    

IOW, I have a snippet that is Verse1, a snippet that is Verse2, a snippet that is Chorus1, etc.   Each of these is a "full band" multi-instrument snippet.     The harmonies can and will differ.   Not a problem.

I build such in Synfire because it offers me ways to do so that no other program does!

Length will have to be specified for the export.  If we have no specified or suggested length data in each snippet, which is the case currently, then the practical work-around would be to instruct the process to export for the length of the longest one.  This length would be supplied by the user.   The other exports would then be nominally "too long", but could easily be cut-to-size once in the DAW.

IOW, if Verses are to be 16 measures, and no other section is to be longer, then export every snippet for 16m.  Drag the files into the DAW and go from there.

I admit that at this point I'm not really clear about the "seamless loop" part.  

Is that relevant for complex snippets?    Don't Verses cold-cut to Choruses all the time in modern music?

The current script dumps files as you listen to all snippets being played. Three times each (in order to be able to grab the seamless loop in the middle).

Let me see if I understand the 3-passes bit.

Snippets contain figures.  Figures are abstract specifications, not literal note sequences, but they become literal note sequences at playback time when processed by the rendering engine (RE).  The RE, in general, can and does often produce different final output at the start of a snippet playback depending upon what came before, and at the end of a snippet playback depending on what's scheduled next.   Hence, in general, you don't really know how a snippet playback literally will begin or end until you know what context it plays back in - what came before and after.

Is the above correct?    Please clarify as might be needed.

If the above is correct, then rendering of snippets to audio will differ depending upon if there is something going on before the snippet is "played back" (and what that something is), and if there is something going on after the snippet is "played back" (and what that something is).     Yes?

If all the above, then OK, I can see why rendering "snippet in the middle" may have a different outcome than rendering "first snippet played" or "last snippet played" - even though it's the same snippet.    Yes?

If all the above is basically correct, then it seems that rendering is (potentially) different for

first snippet played
snippet in the middle
last snippet played
only snippet played

Before I ask or say more, how far on or off track am I with the above?

a feature/option that records one audio file per instrument

I have no quarrel with that, it would be nice-to-have, on it's own terms.

load those into a daw and split the files up into clips

Ack!  No, this is the workflow killer for the clips-into-DAW workflow, exactly what 'Snippet Bounce to Disk' is aiming to avoid!

It also addresses the harmony issue and the problem with stopping audio recording and cutting off the release part of trailing notes.

Unless I misunderstand the situation, slicing audio in the DAW is just making the "cold cut" in a different software environment.   You are cutting off instrument tails just the same, regardless of where you do it (yes?).

To be clear about my own POV - I'm personally mostly fine with "cold cuts"  for most of what I do.  The ability to to work with musical "bricks" and re-arrange on-the-fly is more important to me (most of the time) than concern with an instrument or reverb trail at part boundaries.  When I am concerned with the later, then (and only then) I "go linear" - because you have to if that is your concern (right?).

I believe I see the point Andre makes about the maximally smooth continuity that results from doing a full-length final render inside of Synfire.   It's one (good) reason to own and use Synfire along with your DAW(s).

But almost everything winds up in a DAW, right?    That's where you add vocals, live guitar, live horns, etc. as well as FX and mastering, and more.

'Snippet Bounce to Disk' is about efficiently enabling Synfire/DAW workflows that make use of the extensive clip-based aspects of modern DAWs, rather than treating them only as linear recorders.

I also think some great Synfire/DAW workflow videos could come out of this, to the benefit of Synfire sales.

Just to bring it back up out of a deep (and necessary) discussion - 

IMO, the ability to change Harmony and then re-render all the snippets to audio clip files ready for drop into the clip matrix of a DAW would be HUGE.

What better way to fill a DAW clip matrix with different performances in different harmonies?

Aside -  I've just posted a new Feature Request here:

https://users.cognitone.com/topic/live-recording-library-auditions

with a short demo video which is indicative of how I often work with "bricks".

As a thought experiment (and question), what if Synfire could/would print audio clip files as it goes, sliced at the playback boundaries of each library item clicked on?     There would be no 3 passes, only one pass.  How would this differ from Snippet-Bounce-to-Disk?

The point of exporting audio clips is to have them immediately usable with a DAW. If possible even including meta data like tempo, time signature and whatever an export format supports. They should be trimmed already to sample precision. No manual post-processing required.

100% agree!

Waiting 10-20 minutes for an export should be fine if you get an immediately usable product.

Of course, I'll take it!   But if it could all be done in non-realtime in only 30 seconds that would be quite nicer.  Do I understand that Synfire is currently only built for realtime rendering?   If so, I can understand that changing that might be tantamount to writing a whole new product.

You are correct. The reason to play a snippet 3x is to grab the second round only, which includes the releasing sounds of the previous "loop" at the beginning. And yes, it's important to render in a context in which the snippet is looping. The third round is not recorded (it could be empty), but it's needed to re-synch with harmony and avoid the releasing sounds to run into the next snippet. That algorithm can certainly be optimized, but you get the idea.

Offhand, I'd suggest considering a 1x/3x switch.  

After all, any snippet can be performed first, last, or as a singleton.    Using 1x would mean:  treat it as a singleton.   Since there is no prior snippet and no following snippet for a singleton, there would be no need to play three times and take all that extra time.    The user could then decide based on their use-case whether 1x was fine, or whether 3x would be more appropriate.

BTW, for my video demo referenced above, would there be serious hearable difference between 1x and 3x rendering?

But even if there would be, quite possibly it would be desirable in some cases for each clip to have a fresh start (as if nothing is hanging over from before it).    After all, isn't that how it is in a DAW for bespoke clips?  (unlike if a linear performance has been merely sliced, in which case tails slop over).

Excellent news thank you very much for this!

(I'll start a new topic for questions and further discussion of 'Export Clips')