Repeaters

[Mettra]

Repeaters are sections of notes that can be defined, then places into a song along the timeline. Repeater sections all reference the same underlying notes, meaning that any modifications to a Repeater will automatically transfer to the same sections throughout the timeline.

UI Mockup:

Repeaters can also be shortened relative to their true length, meaning only that subsection of the Repeater will be present at that time

[Mettra]

@aggrogahu Did I get all the details for this?

[aggrogahu]

@aggrogahu Did I get all the details for this?

I'll explain Reaper's usage of Repeaters, which would probably be easier to implement.

There are Repeaters and then there's the 'populate repeaters' action. The 'populate repeaters' action is basically copying all target cues from the first instance of a repeater section, and pasting them into all subsequent instances of that repeater section, replacing any existing target data. This is opposed to a system where changes to any repeater section automatically get pushed to all other repeater sections. In Reaper's implementation, the first instance of a repeater section is the reference, and targets only get copy/pasted to the other instances of repeater sections after the user executes the 'populate repeaters' action.

An example flow for a user would be like this:

• define the sections that you expect would need to be repeated, for example, a song's chorus.
• start mapping the target pattern you like under the first instance of a Repeater section
• run 'populate repeaters' to have that pattern duplicated into other instances of that Repeater section
• if you want to make tweaks to the chorus, you can alter targets under the first instance of the repeater section
• once you're satisfied with the new changes, run 'populate repeaters' to have those changes pushed to the other Repeater sections

The way the midi uses it is notes of pitch 107-127 are each their own repeater section markers. So you could use pitch 107 to mark the choruses, 108 to mark verses, etc. and when you run 'populate repeaters', then each unique section duplicates to their respective pitches. The issue this creates with NotReaper is that current UI mockup doesn't account for multiple repeater sections. Here's how it looks in Reaper for the OST song Addicted to a Memory (I labeled what each Repeater was used for in context of the song)

They also have it so that repeaters have a handType as well (so if you only had a RH Repeater defined, then running 'populate repeaters' would only copy and paste RH target data) but I think that implementation is clunky, as most times you want to copy/paste whole sections instead of only copy/pasting a specific hand's targets. However, if we want perfect compatibility when using the cues2midi converting scripts, then repeaters still need to have handType. A way accommodate this is when defining one Repeater section, have NotReaper automatically save it as three Repeaters, with handType 0, 1, and 2.

This is how current Repeater data is stored in the cues files for the OST song Destiny OST:

Also, here is the lua implementation of populate repeaters for use in Reaper reaper_populaterepeaters.txt

[aggrogahu]

Again, this is just how Reaper's implementation works. I think for sure that if the data is already saved in the cues file for OST songs, might as well take advantage of it. However, having the repeater sections automatically update when you make a change to any instance of repeater section could be a valid workflow as well. It's a matter of whether you want the work flow to be the same as Reaper or if you think the alternative work flow would be better and is worth the development time.