Would like to compile and curate a list of easy OS fixes for the a future (likely final?) Octatrack update. Easy of course is a very hard to define term - especially without being the developer of the OS. It does seem we have some programmers here so perhaps we could work together and make some guesses at what would be easiest to implement.
It should be noted that any change involving new attributes to patterns (trig probability, etc.) is likely ruled out. These types of changes would require changes to how patterns are read and wrote. Backward compatibility with previously saved projects would be required. All timely and easy to introduce bugs.
I’ll start with…
Pattern Reload
-
Find enough free working ram to store a copy of a pattern - perhaps hard because pattern size varies depending upon number or p-locks? Would need to reserve the maximum possible single pattern size (4 bars, all notes triggered on every step, max p-locks).
-
On pattern change, use existing copy function to load pattern to the buffer described in step 1.
-
Add handler for reload-pattern key combo, use existing paste function to paste the reload buffer into the current pattern.
Ways to make this easier
The machine must already have the working ram describe in step 1 above reserved for the existing copy pattern function. Perhaps create a personalize option that 1.) always copies the pattern when a new pattern is loaded 2.) creates a confirm step when attempting to overwrite the copy buffer. The confirm step would prevent the user from losing the auto-copied pattern backup.
Another option would be a personalize option that reserves a particular pattern, P16 might be a good choice, as a reload buffer. On selecting any pattern, pattern p16 is overwrote with the newly selected pattern. To reload, the user could either use a new key combo to restore from p16 or (even easier for the developer), manually copy P16 to the original location.
