Export Clips as MIDI

Very nice what you've done in Synfire 2.5.1 b2 wrt. the exporting of MIDI clips.

Super fast!  

They  drag perfectly right into Ableton Live.   They will drag into Bitwig as well, but Bitwig does not offer the Ctrl- key option that Live does to make them land the way they should.     One can also follow the path (if both DAWs are available):  drag into Live for layout, save Live .als file, load .als file into Bitwig.   The point is, it all works!

In Cubase, I notice there is some meta-info (text stuff) that drags in "in the way" and in general requires extra effort to delete.   It would be good to have an option on the Synfire side to suppress that meta-info if you know it's just going to be in the way at the destination.

It is quite nice to be able to browse the extensive tagged libraries of the DAWs to assign instruments there.

Thanks very much for this great new capability!   

Hi.

I see that the exported clip .mid file names contain more information than the track names internal to the files.

For example, here are output .mid files for 8 snippets in a group:

but inside each file, the MIDI data resides on a track with track name of '06 Pad' in every case.

As it turns out, clips dropped into Ableton Live are examined as to track name and that is the name assigned to the clips, like this:

As is seen, files all having the same identical internal track name leads to clips all with the same identical clip name.

So, there are two important items of information that are captured in the file names, but are not captured in the clip names:   channel   and   sequence#

This information is needed on the DAW side.    The sequence# distinguishes one clip from another, and the channel is needed in case you will be sending out to a hardware instrument which has a multi-timbral configuration expecting data for certain sounds on certain channels.

Thus, clips would be desired to arrive in the DAW with names like this:

Pad 04-01
Pad 04-02
Pad 04-03
Pad 04-04
Pad 04-05
Pad 04-06
Pad 04-07
Pad 04-08
 

and in order to do that (in Ableton Live anyway) those need to be the track names inside the .mid files.

Whew!   

When you get a chance, please tweak the MIDI clip export algo to stamp the track names accordingly (or similar).    

Thanks!

All clips should bear the name of the snippet as showing in the grid.

Ah, well, that's a very long name as it currently exists.   

There is alot of redundant information there that would only have to be edited out by hand on the DAW side, for each and every clip.    No please, let's not require that.   That would be worse than the current situation.

Referencing what's posted above, everything starting with "Chunk" and to the right is extraneous.  We do not want supercalifragilistic.expiala.dotious.long.names  as the default names of clips inside the DAW after import.

Ideally there should be no need to edit the names that arrive in the DAW.  They should have the information that needs to be known by the user, and in a very short format that doesn't take up real-estate for no purpose.

We need to know:    a) what kind of clip (e.g. drums, bass, viola, IOW the Instrument), b) the channel if that is known (as it is currently when I export using my external device description, yay!), and  c) a sequence number to distinguish one clip from another.

Am I missing anything?

I've suggested a specific output here - is there something about it that you consider problematic?

I wasn't talking about the long file names. Just the short names in the grid.

Let me put up a visual, consistent with the discussion above.

There is no value in having the text "Chunk." as the beginning of the names.   This seems true to me in Synfire itself, but is definitely true over on the DAW side.

If you are saying that you will aim to stamp the tracks names as, for example,  "02 [06] Pad", then that makes sense to me and will support an efficient workflow.  

If a name is too long you can easily change it.

Ah, no, not true from the user's POV.   It is critical to recognize when something is x8, x16, x32, x64, or whatever.

What is seemingly easily done just once is not easily done x8, x16, x32, or x64 etc.   This is the very definition of workflow killer!

In the DAW, ready-to-go!    That is the goal I'm advocating for.  It is definitely achievable - if the names are well-chosen.

Ultimately when there are many users all expressing many diverse wants then it might be considered necessary to offer user configuration of naming output.   That of course requires a new UI, alot of thought, and time to implement.  I know you don't want to go there now (or maybe ever), and I understand that.

That's why I'm really drilling in on getting the best possible default naming here, and that's the naming that carries all the needed information in short form and requires no further editing.    It's important!

Thanks.

Hi.

Thanks for 2.5.2, but to be honest, the track naming is still problematic and very disappointing.

The text "Chunk." is absolutely useless here, and worse than merely useless because to edit it on the DAW side is a one-at-a-time operation.

Please understand, I have dozens songs in process.  Every song has a snippets matrix not less than 6x8 (=48 cells, minimum).  All these songs have snippets with names that include the "Chunk." text for the simple reason that the Synfire MIDI file import process created the names that way.   (Yes, actually I would suggest that be changed as well!)

On the DAW side, that's nearly 2000 cells all with terrible names.    For the user to fix them, that's nearly 2000 cells that have to be hand-edited one-by-one.  And that's just for the works in progress right now, not even considering the future.  And that's just for one user.

OTOH, if you would simply throw away (filter out, replace with Null) that undesired  text "Chunk." at the point in the Synfire code where you write the track name into the clip being exported then the entire situation is solved, now and forever, for everyone.

Would this take more than 5 minutes to implement?

I ask you to please reconsider the relative efforts involved at "home base" as compared to "in the field".

Please help us out here!   Please filter out the text text "Chunk." from exported track names in the next release.

Thanks.

The chunk prefix comes from auto-splitting takes in a Phrase Pool into smaller chunks. That has happened long before any snippet grid got involved. You probably created the snippet groups by dropping phrase pools that had those names already in it.

Yes.

You'd need to name the phrases in your libraries in a way that makes sense to you before you drop them on a grid.

Agreed in concept.   However, is necessary to be clear though that I didn't name the phrases with "Chunk."   I never typed that in, and never would.   It is an artifact of the Synfire processes involved in ingesting the data.   Having to visit (hundreds, thousands of) those names one-by-one to change them manually is the problem.   Synfire-side, or DAW-side, same problem!

Your comments though dovetail with an insight I had overnight, which is that a fix at the source is both possible and desirable.

The source in this case is the names in the library.

A perfect fix IMO would be if Synfire would allow a bulk find-and-replace on those names, similar to this:

MIDI export can't fix that. 

Well, it could (at least in theory), but the better idea is probably above, I think.

I'm sure coding Find-and-Replace for library names is less sexy than most of the other things that are on your radar, but hopefully you can see how this would solve the problem, with minimal to zero perturbation of the things you'd rather leave alone, and therefore I hope you will consider implementing this solution to the problem at some point where you can best fit it in.

Thanks.

With mass import into libraries and splitting takes, it is inevitable that phrase names are indexed by number.

Sure.

Guessing meaningful names for arbitrary phrases is probably possible with some help of a well-trained AI (extremely costly though). But then, how many users will agree those names are useful for them personally? I think the whole selection process and the intentions behind it are very subjective.

I'm not sure what brings that up.  I haven't suggested anything like that.

That said, have you checked out Pool >> Renumber ... ? That's a comfortable way to index phrases with any prefix you like.

The null prefix is not accepted.    The nearest one can get to a clean name is to used a single letter as a prefix.

IOW, after Pool -> Renumber it is possible for

Chunk.01
Chunk.02
Chunk.03
etc.

to become

n.01
n.02
n.03
etc.

What would really be desired here is simply

01
02
03
etc.

Is there something about that period character that is essential to the Synfire internals?  

Even more to the original point, Pool -> Renumber has to be done individually for every pool, in every folder in every song.   Not good!

Pool -> Renumber, as it currently exists, doesn't get us accurately or quickly to where we need to go.

But if you extended the idea of it so that the operation could be done in one step on all the pools in all the folders in a Library, well, it would be alot closer.

A library full of

n.01
n.02
n.03
etc.

is much better than a library full of

Chunk.01
Chunk.02
Chunk.03
etc.

and

n01
n02
n03

would be even better

and

01
02
03

would be better still.   (Best!)

So, I still like the idea of generalize find and replace, but if your concern is that the period must remain (?) for internal reasons, then by all means please let Pool -> Renumber be applied to the entire library at once, and the period can remain safe from user tampering.

Thanks.

P.S.    I still see no upside in the use of "Chunk." in the first place.    

This was perhaps not as problematic prior to the Clip Export capabilities.   Now that we have these great new capabilities, the real-estate issue is much more in play because we want to be good-to-go immediately on the DAW side without having to stop and do renamings to recover lost real-estate and/or know what we are looking at.

A cleaner (shorter names) Snippets Matrix in Synfire itself would also be a benefit of doing away with "Chunk." on the import/split pathway.

If we need the period (?), why not just go with "n." as the original name-stamp prefix, rather than "Chunk."?

I dont support changing pool->renumber to work on a whole library. It applies to a pool, 
Happy to see a new function library->renumber, 

Yes, of course.  I agree with this.

The dot is used to separate the index from the name. The name hints at how a phrase was created, e.g. by splitting a take into chunks. A pool may contain a mix of phrases, some resulting from import, some from splitting, etc. The names reflect that.

I track what you are saying here.  It's a sort of historical record.   Nothing wrong with that, per se, IMO.

But when then information is not needed by the user, and its presence is inimical to other goals, then the user should have an easy way to remove and/or replace it (in bulk).

Back to what we are actually getting in the output at this point, both in the Snippets Matrix and in the DAW:

Everything but "Chunk." is information the user may need to know:  Seq#, Channel#, Instrument/Sound.  Good!

And, those 3 items of information are in a good order.  You can narrow the column down to as narrow as the 2-digit Seq#  (if "Chunk." were not there)  and still be oriented in the DAW.   This is good real-estate management!

If someone does want to keep "Chunk." for the sake of being an "origin record", OK, fine.  I wouldn't, but I'm not out to take anything away from anybody else!

So, a Library -> Renumber operation as mentioned above seems like a good way to accommodate all.

I would prefer if this Library -> Renumber would allow me to remove both before the period and the period itself.    That's my pref.   But I'll work with leading "n." (at the cost of doubling the required minimum column collapsibility) if that's what has to happen.   IOW, I'd rather lose 2 characters-worth of real-estate per column than perform 2000 manual edits.    Just so long as I can get to that point by running a Library -> Renumber operation just once on the whole library.

Thank you for Synfire Pro v2.5.3!

The audio results from Synfire into Live are very nice  -  

From this:

to this:

to this:

This is workable!

The full names remain quite long, which you have your reasons for, but the important part is up front and what we see immediately after the drag-in makes sense!   In most cases, I'd rate this as good-to-go!

If the user cares about seeing the sequence numbers, they are next up with just a slight expansion of any column:

And finally, with the exported names arranged as you did it, anyone who really wants to shave down the names in bulk can easily do it rapidly at the file level before dragging into Live:

Super!

I presume this was all intended.   If it was merely luck, you should go to Vegas!

BIG SMILE.      

Thanks again.

Well chosen defaults are always very nice to have - they save alot of work and time.

Likewise, user-options to set your own defaults are pretty much ideal.

Here is a pic of naming offerings from another of my favorite go-to programs:

Please feel free to do something similar for Synfire at some future point.  :^).
Cheers!