In an attempt to reduce the logical complexity of the Composer, this change flattens the FInstrumentScheduleData and FMusicalStrategy objects.
The interaction between ScheduleData and MusicalStrategy were unclear to me. By flattening them, I hope to reduce the overall complexity of the data objects being managed, and have a clearer idea of exactly what data objects are strictly needed.
As part of this, I've also started using Shared Pointers for USTRUCTs more. The thought being that a reference to an object is probably better to use than a copy of the object.
This surprisingly worked without issue.
I may need to reintroduce Strategy Data, but the complexity of a ComposerData holding a set of InstrumentData, which holds a set of MusicalStrategies was bonkers. Now ComposerData is the king.