Posted
Hi.
Currently, we can drag a snippet memory into a library, but cannot drag it back.
Though the snippets from the memory slot are placed in a Folder for visual organization, they are no longer a group to be draggable elsewhere. They are just individual phrases in the library, treatable one-at-a-time as such. The Folder gains you only a visual indication that these were at one time in the past together in a Snippets Group (from which they were dragged to the library).
Basically the same thing happens if we drag a container out of the Structure timeline. It gets decomposed into phrases which are then stored.
It would be great if we could (optionally) store actual containers (not just their phrase contents) as-such in Libraries.
If the "thing" in a library were a full-fledged container, it could be dragged back to any Structure timeline, or into any Snippets memory.
These would be a new, higher-granularity "nuggets" for us to accumulate and work with. I think this capability would be quite empowering for repurposing partial materials from one project to another without having to rebuild those materials from the bottom up in order to do so.
Mon, 2024-02-05 - 11:41 Permalink
it could be dragged back to any Structure timeline, or into any Snippets memory
This idea has haunted me for years. But there's a catch.
A similar thing once existed (container import from other arrangements) and was streamlined away because every arrangement has different instruments and sounds. Even within the same arrangement instruments change all the time. The next day your library might no longer match.
The dialog that popped up to handle the mapping of source instruments to target instruments, parameters to include/exclude, how to handle inheritance and aliases, all that was very complex overhead. It's easier to drop each phrase directly where you want it to go and use the wizard to handle the sound assignment.
Snippet memories don't include phrases, by the way. Merely the numbers of the active snippets.
Mon, 2024-02-05 - 15:16 Permalink
Snippet memories don't include phrases, by the way. Merely the numbers of the active snippets.
Indeed.
I seem to notice though that I cannot replace a snippet which is referred to by one of the memories without destroying the integrity of the memory. IOW, after such replacement, the new snippet will not be invoked by the memory.
I would rather the opposite. IOW, once I establish a set of numbers in the memory, whatever I have in those locations will be invoked by the memory, even if I make changes.
Yes, of course after a replacement the "set" is no longer identical with the set as originally saved. So what? If I didn't want it to be different, I wouldn't have replaced anything in it!
What I don't want is to have to reconstruct memories when my only intention was to change a single snippet to one that I decide I like better. This is extra work, time, and possible error for no upside (IMO).
So, I suggest that Snippet Memories retain their pointers until explicitly overwritten (or cleared to null, which is needed) by the user.
Fri, 2024-02-16 - 22:42 Permalink
This idea has haunted me for years. But there's a catch.
A similar thing once existed (container import from other arrangements) and was streamlined away because every arrangement has different instruments and sounds.
Containers carry their own Figures, and other parameters, yes?
Would it be conceivable for containers to carry their own instruments?
Or alternatively, could containers "marry" instruments to figures ala the way a DAW "track" marries MIDI data to a plug-in instrument?
I'm sure this has been much thought about along the way ...
IMO, creating/saving/reloading/rearranging/remaking structures at a higher level than the individual phrase is essential. I'm concerned that if this has been de-prioritized or been made technically un-doable by the current object designs then the product won't be able to rise into the Great Beyond.
Sat, 2024-03-09 - 17:03 Permalink
I think this idea is starting to haunt me too. ;^)
Snippet memories don't include phrases, by the way. Merely the numbers of the active snippets.
If we can make an alias physical, I suppose by analogy a Snippet could be made physical too for the purpose of storing and accumulating snippets in Libraries.
Since existing Libraries are all about phrases, maybe alternative Library Types could be a way to go.
I'm thinking 'Snippets Memory Library' and/or 'Container Library', etc.
If I'm thinking clearly, such Libraries would not have to themselves be complex and hard to manipulate tree objects.
The only goal would be storage and retrieval of the complex objects themselves (Snippets Memories, Containers).
I don't know if Snippets Memories (SMs) can or cannot be treated in the same way together with Container Structures (CSs). That would be ideal, but even if it is too much of a mess to treat SMs and CMs as one commonality, it would still be very powerful at the user end to have either or both of these be accumulatable and retrievable as such.
From my user POV, if it were to turn out that there were 2 or 3 Library Types instead of only one, I would profoundly not care! I just want to accumulate and retrieve completed objects as such.
When retrieving, if the Instruments are already available in the destination then just link to them, and if they are not already available then add them Wizardly as done now wrt. Phrases pulled in from Phrase Libraries.
I agree that dealing with Instruments as they come and go can be complex and confusing to the user (I raise my hand!) , but I think the answers to that are: a) clear education, tutorials, help and b) perhaps some extra explanation and clarification of the dialogs involved at the point of presentation.
IOW, once a process cannot be made any simpler, because it is actually intricate at the conceptual level, then it will be on the user to learn management of whatever complexity cannot be coded-away.
However, when I say "on the user" I don't mean user-on-their-own. I mean, rather, that excellent education is available and can be easily pointed to (again, and again, and again, as necessary). :^)