Posted
Hi.
I'm back from 3 weeks of travel to Norway, Estonia and Finland. I had a great trip and now I'm looking forward to digging in deep to Synfire 2.4.6 (and beyond).
I am very happy for saving snippets and snippet memories into libraries. With this feature we can really go to the moon with Synfire!
My first new feature suggestion from here is for snippets and snippet memories from libraries to retain their names when dragged into the structure view.
A snippet is a thing, and we must and do give things names to designate, identify, catalog, search and find them.
Snippets and snippet memories will be dragged from libraries into Structure routinely, and then from Structure back to the Snippets Grid routinely. The names need to go with them!
Mo., 13.05.2024 - 10:06 Permalink
Can't test at the moment (I'm on the road today). Snippets should be restored using their original name already.
If you rename items in the library manually that's merely to distinguish multiple versions. For example you may add memory A multiple times and they will be named A, A(2), A(3) etc. You may label one "First Version" or "Best Version", but when it is eventually restored, its original name will be used.
Same for containers.
Mo., 13.05.2024 - 12:35 Permalink
re: "For example you may add memory A multiple times and they will be named A, A(2), A(3) etc. "
Yes, as of now, "A, A(2), A(3)" is how they will be in the library when dragged in (repeatedly from snippet memory A), which gives them individual designations in the library, and this is as it should be.
The use-case / workflow here is that snippet memory A is being used as the "build area" for successive rolls of the dice, chosen nice results of which are then being moved to the library to keep.
The issue is exactly as you describe, namely that they won't be "A, A(2), A(3)" when dragged back out of the library!
The need is for those individual names to persist ever after until/unless changed.
Mo., 13.05.2024 - 12:36 Permalink
As a concrete example, suppose "A, A(2), A(3)" represent 3 good dice rolls for guitar, pad, and synth where drums and bass have locked down (kept the same).
The "A" in this case represents a specific combination of drums and bass, and the " (2)" and " (3)" represent that I have two more variations (of the other instruments) that also use that same drum and bass.
I may be happy to accumulate snippets in a library just like that, or I may choose to rename "A, A(2), A(3)" to "D1B1, D1B1(2), D1B1(3)" or some such (possibly even longer, like "Verse 1a, Verse 1b, Verse 1c").
You can see that any such naming logic might easily expand across a whole song.
Each user, over time, is going to (have to!) come up with some naming logic of their own. The specifics of those individual logics (and even a single user might have more than one of them) cannot be anticipated in advance.
However, the need to keep those user-created/understood names as the library items are dragged/moved/copied to Structure or the Snippets Grid (or anywhere else possible now or later) does and will always apply.
Mo., 13.05.2024 - 13:58 Permalink
It occurs to me that the concepts of "short name" and "long name" might well be applied.
There would be places in the program where either short name or long name could be displayed, at the user's request, but there might also be places in the program were displaying the long name would be impractical as it would be too long to fit (in the available real-estate, at the current zoom level).
When long name is too long for in-place display, it could be made visible by hovering over the short name, as well as in any inspectors which are currently visible.