search

monome / teletype

monome eurorack module
GNU General Public License v2.0
204 stars 84 forks source link

TT: copying Queue to a pattern erases complete pattern #295

Open wolfgangschaltung opened 2 years ago

wolfgangschaltung commented 2 years ago

TT: copying Queue to a pattern erases complete pattern

Teletype v4.0.0 CBAEE74

What steps are required to reproduce the bug?

  1. load empty scene
  2. ensure you are in Live mode
  3. P 63 1 (in Live mode, set index 63 of working pattern to 1, working pattern is 0)
  4. Q 2 (in Live mode, place 2 into the queue)
  5. Q.N (in Live mode, get queue length: length is 1)
  6. Q.2P (in Live mode, copy entire queue to current pattern)
  7. TAB twice to see Tracker
  8. in Tracker, index 0 of pattern 0 contains 2 (expected)
  9. in Tracker, index 0 of pattern 0 contains 0 (unexpected, expected to still be 1 per step 3)

Notes

As I am not a developer, my code knowledge is extremely (!) limited, so please take the following with the proverbial grain of salt, as it is just a dilettante thinking out loud: Both lines 524 and 535 in teletype/src/ops/queue.c say int8_t end_at = PATTERN_LENGTH < Q_LENGTH ? PATTERN_LENGTH : Q_LENGTH; which to my naive understanding indicates that the copy process should end at either the pattern length (if it is shorter than the Queue length) or at the Queue length (if this is shorter than the Pattern length), which leads me to believe that the current behavior is a bug.

Beside this, clearing a whole pattern with 64 entries while copying a queue of 16 into the pattern seems a rather substantial data loss.

Thanks for having a look into this!

wolfgangschaltung commented 2 years ago

P.S. I just learned that the maximum Q size has been updated to 64, so my second to last sentence (in which I mention "a queue of 16" is not correct.

While the current TT Queue documentation correctly describes the currently implemented behavior "Copy entire queue to current pattern…", this is at odds with what the code seems (again, I am not a developer!) to say: the copy process should end at either the pattern length (if it is shorter than the Queue length) or at the Queue length (if this is shorter than the Pattern length).

From a user perspective, it would be great to have at least the option to have the copy process respect the length. Perhaps with an additional command like Q.N2P (or Q.2PN)?

This would allow to use one part of a pattern for interaction with a queue shorter than 64 elements), and have the remainder of the pattern being used for storing other data.