Storing the pattern pool in child tracks of its track, on any sub-level (all sub-levels allowed)

[michaelsjackson]

While not ideal, Hackey Patterns stores the pattern pool at a time point late in the project.

Why not saving the pattern pool in child tracks instead of adding in later time? The patterns in child tracks could stay there always MUTED, thus the child track themselves do not have to be muted. Or to be sure, both could be used. Items muted in child track, plus the child track itself, also muted. The advantages would be:

• No need to scroll to end of arrange
• As many child tracks as you need are possible
• Listening without adding to main track in arrange would be possible, just unmute item, unmute track, child tracks are automatically routed through parent track
• Child tracks on any sub level would still work, you could build the child patterns, hierarchically, gradually adding more details for example. But still being able to remove/mute details out again.
• Depth dimension would be used, rather than being ignored.

[JoepVanlier]

This occurred to me as well, but I decided against it for several reasons mostly involving automation.

• The most important reason for not doing this is VST duplication. In order to have the same automation envelopes on those subtracks, you'd need all the same VSTs on that subtrack (or at least the ones that do have automation). This would increase CPU usage like crazy.

• Additionally, there are no facilities for adding envelopes, so the user would have to create the envelopes for these sub-tracks himself.

• I'd have to verify the envelope order as well which is very impractical. When being on the same track, it is guaranteed that all properties are the same.

• When an envelope is added, I'd have to recopy the entire track. Delete all the items on that newly created track, move all the pool items from the old pool track to the new track and then delete the old pool track.

Anyways, the code is not written generally enough that this change can easily be accomplished and it is not likely that this alternative storage will be implemented.

[michaelsjackson]

No problem, thanks for the detailed explanation.