Here's a list of caveats and things to remember/building blocks when dealing with the mapping screen [@Thomas: pls correct anything I got wrong]
0) First and foremost the whole mapping screen (all 70 [= hex 45] lines!) is executed/processed 100 or more times for each row in one of your patterns. E.g. when your song runs at 120 BPM (2 beats per second) the mapping screen is processed 125x for each row in any of your patterns.
This is great for reacting to external controls (e.g. faders connected via I2C) but requires extra means when you wish to do stuff in relation to the musical events in your pattern.
1) Synchronize processing of (some) mapping screen functionality with your sequence
This is achieved via the function XMAP <some mapping row> that you can place in the function part of a sequencer row. It will process exactly this one row of the mapping and nothing else [outside of the normal mapping processing].
The content of <some mapping row> is then processed and completely in sync with your sequence. Fine.
Now we need to make sure this line is excluded from normal mapping processing (remember, 125x per row, see above).
This is done by placing something like
directly in front of row <some mapping row> (the one we process via XMAP <some mapping row> from our pattern).
The SKIP cmd conditionally skips 1 (or more - up to 8) following rows from processing. By choosing a condition that is always TRUE (like VA == VA - whatever the value of VA it will always be identical to itself) we can assure that this row is executed only when the pattern says so via XMAP.
2) The above works great for things that can be done in a single mapping row. However sometimes we may wish for more complicated processing. For this we can expand the trick we applied above:
Code:
SKIP 1 = VAVA
CALC INC VAVA > SETV V A
SKIP <n> = VAVB
<n> rows of mapping processing
...
The trick is that during normal processing the line
will be TRUE (provided we made sure VA and VB started out the same) and the following <n> rows will normally not be processed. Only when we process
Code:
CALC INC VAVA > SETV V A
from our pattern (by means of XMAP <row # of that row>) it will be activated. To make sure it will be processed just once we have to reset the condition by something like
Code:
VAR # A #000 > SETV V B
<n> can be up to 8 rows. If we need particularly complex processing we can repeat the above pattern like
Code:
SKIP <n> = VAVB
<n> rows of mapping processing
SKIP <n> = VAVB
another <n> rows of mapping processing
SKIP <n> = VAVB
yet another <n-1> rows of mapping processing
VAR # A #000 > SETV V B
Be aware to put the last line (aka resetting the condition) into the last block of rows to process!
Kind regards,
Michael
PS: I will expand this as I come across other things I find useful as building blocks
@Thomas
Wishes for extensions to the mapping processing:
1) SKIP cmd
It would be handy if the SKIP command would get at least a constant value of 0 as an additional second value, e.g. like:
SKIP 7 = VA#0
Comparing against 0 is so common that it seems a waste to always have a variable fixed to that value. It's probably possible to trick some row value (that implicitly is always 0), but that would create a debugging nightmare if for whatever reason that will change.
2) VAR cmd
Fast scrolling UP through the values works just fine. DOWN seems to stop when the first digit is 0 and from then on one needs to use slow scrolling to e.g. reach #000. Please ammend
3) Copy and paste in mapping screen
I'm sure it is on your TODO list but I thought I'd mention it anyway
When editing/developing more complicated processing I often need to insert rows. I'm not aware of a way to achieve that (other than to re-enter all the lines below).
