Direkt zum Inhalt

Allow Max Phrase Pool Size for Imports

Posted

Hi,

Currently on MIDI file import all the contents of track wind up in one Phrase Pool.

Example:   31 phrases in the pool

Sometimes that is fine, but when the goal is to be able to drop Phrase Pools on Snippet Groups it doesn't work out well because all the phrases in the pool beyond the row or column size of the Snippets grid are not accessible that way.

The idea here is to split the import of a single track across multiple phrase pools of a user-chosen size.  (e.g. 8, 12, 16  as per Snippets grid sizes)

In that way, the pools in the Library become right-sized and "ready-for-Snippet-Group-drop" immediately after import.

I have been thru the time-consuming process once of laboriously constructing a "ready-for-Snippet-Group-drop" Library.   Not recommended!

Please let the computer handle this for us.

Thanks.

 


Di., 30.01.2024 - 16:42 Permalink

In addition to having this happen at import time, the ability to process an existing LIbrary to split its Phrase Pools in the same way for the same purpose would be great to have.

 

Di., 30.01.2024 - 17:03 Permalink

There are potentially hundreds of similar situations, parameters, preferences, preprocessing steps with batch import. It is impossible to add a specific feature for all of them. Scripting would be great, but we don't have that.

At some point, the earlier the better, you need to decide whether a phrase makes good building material for your style. If you import MIDI files and use the results without manual review, you will inevitably end up with a huge pile of redundant, repetitive and insignificant stuff. Unless someone else already reviewed the files, that is.

Di., 30.01.2024 - 17:30 Permalink

At some point, the earlier the better, you need to decide whether a phrase makes good building material for your style.

I acknowledge that point, truly, but without believing that it invalidates my suggestion/request.

First, I'm just aiming at having Synfire be internally consistent.   Snippet Groups have a limited, defined set of sizes.  I think Libraries that directly support those should be easily constructible.

Second, one of my main approaches to composition is based around finding new, serendipitous combinations of musical elements.  I'm not alone here.   I came to Synfire based on my perception (from research, the marketing, etc.) that it would be a superior platform for this kind of work.   And I do think it is ...  BUT there are some roadblocks the clearing of which will make a big positive difference in productivity.

Third, exactly as you say, "pre-vetted".   Yup.

--

This might be a good place to say that the recent adding of 'Simple' slicing on import has been IMMENSELY helpful in getting the desired elements, as such, into Libraries.   Thank you for that, big time!

Now, we just need to finish up the pipeline into Snippets.   

I think this suggestion would do that, without requiring any fundamental paradigm or object changes.   That's good, right?

 

Di., 30.01.2024 - 18:31 Permalink

one of my main approaches to composition is based around finding new, serendipitous combinations of musical elements.  I'm not alone here.

Absolutely! That's what I do all the time. I didn't mean to dismiss your suggestion, I just wanted to add a note of caution because feature bloat is a dreaded lure among developers. The goal must always be to have a finite collection of features that may look simple in isolation but that can be combined in many ways in order to achieve more complex tasks (instead of adding a new feature for each of those tasks).

I'm not yet convinced that splitting a pool into chunks based on the current snippets UI (which may change) is a good idea. That would make a library much less concise and difficult to navigate. Actually it's up to the snippets grid to decide which phrases of a pool it will accept.

Whether to establish a direct relationship between batch imports and snippet grid sizes is a fundamental question. That cannot be rushed. I'll rather collect more workflow suggestions and let them sink in for while.

Di., 30.01.2024 - 21:52 Permalink

I appreciate your sympathy for the goal very much.

Certainly the specifics are worth a think!

After a nap, I had another idea:

Currently, we can drag over a single phrase from a Library and drop it into a single Snippet.

How about if alt-drop started with the given phrase and then auto-dropped sequential phrases from the pool into sequential snippets - up to the end of the available phrases or the end of the snippet row/col, whichever is hit first.

Example #1:    From a pool with 31 phrases, drag and alt-drop  p25 onto the first snippet.  Snippets 1 - 7 get filled with p25 - 31.

Example #2:   From a pool with 31 phrases, drag and alt-drop  p1 onto the first snippet.  Snippets 1 - 16 get filled with p1 - 16.   (for 16 item Snippet row/col)

Or, to avoid wearing out the alt-key, there could be a modal choice between single-drop and multi-drop as described.

Mi., 31.01.2024 - 13:04 Permalink

This would be consistent with:

Actually it's up to the snippets grid to decide which phrases of a pool it will accept.

The snippets grid would just make a different decision (so to speak) depending on drop vs. alt-drop.

No need to make any special Library layouts in this case to accommodate Snippets, yet still all that needs be done (i.e. fast, efficient population of the snippets grid) gets accomplished.
 

Mi., 31.01.2024 - 20:19 Permalink

It's not that easy. The phrase doesn't know its position in the phrase grid. What's more, the view may choose to sort the phrases differently.