Feature request: "Instancing" or "Patterns"

[GoogleCodeExporter]

I'm just a beginner with EOF, so maybe I'm not using it correctly, but I think 
it's quite painful to use at the moment for one specific reason: every note is 
treated as unique.

This is almost never the case in songs, where mostly there are a couple of 
riffs that repeat throughout the song and a solo or two, plus intro/outro or 
other minor sections.

So right now I can select a couple of notes and then add them to the catalog. 
Let's call this "riff 1". I can now paste this riff from the catalog into the 
song at all the positions it's repeated at, however if I want to make a small 
change to the riff these changes do not apply to the pasted riffs, only the 
original notes used to create it. So I have to delete all the previously pasted 
versions of this riff and then figure out the positions to paste the new one 
instead. That's a lot of manual work for something that can be automated.

***The only information that's really needed is A) a Riff index in the catalog, 
B) the position to place it and C) the number of times this riff repeats from 
position B.***

Now imagine that you want to make a change to the riff, you can change the 
notes around at only one single position and all other instances where the riff 
is shown will be automatically changed.

Or as the riff repeats, it gets slightly out of sync, so you need to tweak the 
riff length. So you change the riff length in the catalogue, and you DON'T need 
to change any position at all, because the riff start point (which I called B) 
will always be manually placed and thus correct, and the repeated riffs from 
those manually placed start points (B) will automatically place themselves at 
the correct location as I tweak the one and only parameter of the riff length. 

Same thing with difficulty settings, you just need to change the different 
unique riffs once and all the instances of those unique riffs are updated.

Is this already supported and if so where can I find this functionality? This 
is how I've worked with computer music before with trackers 
(http://en.wikipedia.org/wiki/Music_tracker).

Original issue reported on code.google.com by quarns...@gmail.com on 24 Apr 2013 at 8:27

[GoogleCodeExporter]

This is an interesting idea, but these changes could be difficult to implement. 
 How much editing to an instance of a catalog entry should be allowed before 
it's no longer considered to be a related pattern?  People would undoubtedly 
need to be able to move the notes in an instance to account for timing 
differences in the composition, but what about adding a technique, or replacing 
a sustained note with multiple notes?  What if one note was moved to a 
different string/fret?  I'll need to put some more thought into it, but it's 
more likely that a proper search and replace function gets added.

Original comment by raynebc on 24 Apr 2013 at 6:31

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

> How much editing to an instance of a catalog entry should be allowed before 
it's no longer considered to be a related pattern?

IMO none. It's either exactly that pattern with only relative information 
applied to the whole pattern (ie full pattern transpose, full pattern position 
in time), or it's a different pattern.

> what about adding a technique, or replacing a sustained note with multiple 
notes?  What if one note was moved to a different string/fret?

Are we talking about changing one instance of the pattern only? Then it's a 
different pattern as I see it.

I'll probably cook up my own simple program to accommodate my needs in the 
short term, but if I were to fork EOF I'd make the main song view readonly and 
only use it for previewing, changes would instead be done directly in the riff 
catalog, and there would be a new view where you chain riffs from the riff 
catalog together thus forming the song.

Original comment by quarns...@gmail.com on 24 Apr 2013 at 7:49

[GoogleCodeExporter]

What about timing changes, ie. the distance between two notes in the pattern 
(measured in beats) is longer in one instance than the original pattern?  
Should it still be considered the same pattern?

Timing aside, the stricter that this logic is (ie. an instance has to have the 
same number of notes and the same lane/fret combinations for each to be 
considered the same pattern), the easier it would be to implement.

Original comment by raynebc on 24 Apr 2013 at 8:46

[GoogleCodeExporter]

Think of it from a functional programming point of view where the input is the 
original pattern and the output is a transformed pattern. Each instance entry 
then specifies a source pattern and a lambda expression performing the 
transform. If the change can be expressed this way, it's the same source 
pattern otherwise it isn't.

I'm at the moment mostly interested in a time offsetting transform which adds a 
fixed amount of time to each note in the pattern, but other transforms such as 
transposing, repeating, reversing, gradual volume change over time, etc 
wouldn't be that much work as they all follow the simple input pattern->output 
pattern formula.

Original comment by quarns...@gmail.com on 24 Apr 2013 at 9:21

[GoogleCodeExporter]

With issue 260's progress the need for this one is greatly reduced IMO.

Now that I have a little more experience with EOF, I think there's some 
groundwork done already to work with something like this. The feature I'm 
thinking about are the markers for "Rocksmith phrases". I don't know how strict 
RS is when it comes to phrase equality, but since the markers should be placed 
anyway a checkbox to "instance previous phrase with the same name" to link the 
phrases would be enough from a UI perspective.

Behind the scenes I understand that there is probably more work to manage a 
change in the base instance showing up in the linked phrases, but like I said 
the need for this one for me personally has greatly reduced with the progress 
made to issue 260.

Cheers!

Original comment by quarns...@gmail.com on 2 May 2013 at 7:45

[GoogleCodeExporter]

Also now with the Dynamic Difficulty Creator tool I see no need for this one 
personally. Feel free to close as far as I'm concerned.

Original comment by quarns...@gmail.com on 22 Feb 2014 at 8:46

[GoogleCodeExporter]

Alright, I'll go ahead and close it for now.  I'm not sure that there would be 
any easy way to implement this kind of change.

Original comment by raynebc on 22 Feb 2014 at 10:11

• Changed state: WontFix