Who Owns the Data?

Sometimes you need to think about code more than writing code.

As evidenced today by the very light commit:

Add all (if mostly empty) SongSections

JerkyTreats

It triggered a lot of interesting thoughts about the code, though.

I started by thinking about which Musical Strategies should be in each Song Section.

In most of the sections, there is a strategy to create a new bit of music, and then repeat that bit of music.

I have the CreateMotif function, which solves for the create, but essentially need a RepeatMotif strategy.

The actual logic of RepeatMotif would be pretty simple, what’s harder is where the data is stored.

Repeat Yourself

In order to repeat something, I need to store something to repeat.

So I have to think very carefully about what object owns the data that needs to be repeated.

Candidates:

• ComposerState
• Song Section
• Motif Object?

Song Section makes sense, as each song section can have their own motifs- A Refrain/Chorus section needs to remember the Motif(s) to repeat.

And ComposerState owns the SongSections, so kind of get that by default.

But the Big Brain Idea was to return some kind of Motif object.

Big Brain Mode

Currently CreateMotif has this massive data object used to generate somewhat musical sounding motifs:

Untitled

JerkyTreats

It’s essentially static data initialized by CreateMotif().

The idea is to have this not be just static data.

What if this object contained both the FInstrumentSchedules the function currently creates, and the abstracted musical idea that can be consumed by RepeatMotif?

It doesn’t necessarily need to be FCreateMotifData in its entirety.

The main point is to have some kind of object like:

// Struct returned by MusicalStrategy
struct FMotif {

	// This maps Notes/Beats, consumed by audio player
	TArray<FInstrumentSchedule> InstrumentSchedules;
	
	// Simplified InstrumentSchedule consumed by Composer 
	TArray<int> MotifStructure;
}

Have SongSection own a (set of?) FMotif, which it can create with CreateMotif, and pass to RepeatMotif.

There’s a cost to doing this, as I need to change the MusicalStrategy signature, which has long ranging effects.

I think it might be time to revisit this idea of a common MusicalStrategy interface.

I know it’s a Design Pattern and all, but there’s a real thought that the limitations might exceed the benefits.

But that requires a set of Big Brain Thoughts I don’t have time for today.