Direkt zum Inhalt

Last Container from "Make Arrangement from Last Session" is Created Differently

Posted

Hi,

Consider this picture:

It is the result of playing back 8 snippets memories in sequence, for 4m each, ending by pressing the Stop button on the transport with timing just as-if I were scheduling a 9th memory.

As can be seen, the last (8th) container is named differently from the first 7.

Shouldn't it be named "H"  (with the little circle symbol for Harmony ...), rather than "Part 2"?

File attached (not displayed), in case that is useful.


Di., 20.02.2024 - 16:17 Permalink

Well observed.

Shouldn't it be named "H"

In theory, yes. That container "H" existed temporarily but was removed because it was empty. Probably because "Part 2" grabbed all the phrases. It then moved up to fill the resulting gap.

The memory button names are merely a default label, just so the container isn't blank. The final structure is exclusively collected from which phrases played when and for how long. It often bears little resemblance to the sequence of buttons originally pressed.

Sa., 24.02.2024 - 00:04 Permalink

Hi.    Thanks for your reply.

The things I know:

The Snippet Memory H was not empty.    Part 2 and Part 3 were not existing entities available to "move up" - they are creations of the "Make Arrangement from Last Session" process.  

 I don't think Part 2 and Part 3  should even exist in this Structure.   As I see it, they came out of thin air.

It is not clear to be if your explanation is meant to share the technical aspects of a bug's cause, or is suggesting that there is no bug. (?)

 

Sa., 24.02.2024 - 00:16 Permalink

What could be  the relation between part 1, 2 and part 3 ..think about that ?

Sa., 24.02.2024 - 08:13 Permalink

If the music plays as expected, it's not a bug but merely a cosmetic issue. Rename "Part 2" to "H" if that is important to your workflow.

It is likely that what has originally been "H" just became "Part 2" as a result of how the reduction algorithm works internally. The reduction of tree structures based on node properties is not trivial and may have a side effect like this where the final node is the result of pulling up the "remainder" of what's still playing.

Sa., 24.02.2024 - 15:36 Permalink

I just did a test with only Snippets memories A and B, defined exactly as rows.   The same thing happens.  So, it seems quite consistent.

Thanks for the commentary, insight, and suggestion.

I suppose the point we differ on is the word "merely".     I'll state my POV and then be quiet about it.

Snippets, Containers, and the Structure display are primary paradigms of Synfire.  Whether users can see and perceive these things as harmonious and consistent with each other, and clearly understandable as to their behavior is, IMO, a very important thing.     Everything Synfire does is "wizardry behind the scenes".  Some parts of that wizardry are easier or harder from a development POV, and maybe presenting a consistent, immediately understandable UI using these paradigms is one of the harder parts.   Nevertheless, hard or easy, it is critical for the user's sake (and arguably the ultimate level of market success of the program) that displays/behaviors which induce cognitive dissonance be identified and rectified.  The question devolves to whether it should/must be on each and every user  to discover, catalog, memorize, and work around such things, or whether these things are best addressed/solved once for everyone by developers at Cognitone who have the highest level of understanding of causes and remedies.   Obviously, I'm advocating for the later, basically regardless of how many "special cases" need to be coded for.  Every special case solved is a win, for the users and for the product.   Users have a limited tolerance for things that on their face don't make sense.  Every time such a thing receives a decision of "Eh, let 'em live with it", there is a withdrawal from the bank of tolerance, goodwill, and good word.    IMO, the behavior described/shown in this topic on it's face doesn't make sense, and so it's a non-trivial win if you can fix it.    End of opinion.   Thanks for considering it.    ;^) 

 

 

Sa., 24.02.2024 - 20:53 Permalink

I'm with you regarding cognitive dissonances. Whenever possible we want to avoid them. Automatically generated labels for containers don't make much sense. You will want to rename them anyway, if you continue editing the structure.

As a small team we need to set tough priorities. Every day spent fixing things is lost for other very urgent tasks. A product as complex as Synfire is an incremental process. Things land on "the list" and get picked when their priority is due.