Feature/cycle mapping

[emuell]

See #13

This allows mapping identifiers and other existing note values in cycles to custom note values via a static map (a table, in Lua):

cycle("bd(3,8)"):map({ bd = "c4 #1" })  

... and via a function callback:

cycle("4 5 4 <4 [5|7]>"):map(function(context)
  local notes = scale("c", "minor").notes
  return function(context, value)
    -- dummy example: emit a cmin note arp with 'value' as octave
    local note = notes[math.imod(context.step, #notes)]
    local octave = tonumber(value)
    return { key = note + octave * 12 }
  end
end)

Context in map functions contains global info such as transport timing and also maintains step counters which are running individually for each channel in the cycle.

---Context passed to 'cycle:map` functions.
---@class CycleMapContext : TimeContext
---
---channel/voice index within the cycle. each channel in the cycle gets emitted and thus mapped
---separately, starting with the first channel index 1.
---@field channel integer
---Continues step counter for each channel, incrementing with each new value in the cycle.
---Starts from 1 when the rhythm starts running or after it got reset.
---@field step integer
---step length fraction within the cycle, where 1 is the total duration of a single cycle run.
---@field step_length number

---

Only single notes can be used as mapped value. Chords and thus also stuff like note('c4') values are not yet supported. This will be done in a separate PR.

As soon as we allow chords in mappings, we can also add some helper mappings and function to ease mapping scales and stuff.

@unlessgames We likely do conflict here: I've added a new "string" property to Event, which is used as key for the mapping.
Decide you if we merge this PR or yours first.

[unlessgames]

These functions were moved into Value on my branch. The issue I see with the implementation here is that the string returned is not the actual parsed literal as this comment suggests, instead, it is a string derived from the value

• ab3 will become g#3
• A3 will become a3
• .2 will become 0.2
• floating point precision related issues might show up

So I think this should be copied to the event from the Single's string field at this point which is the actual string literal that was in the input (parsed here).

I'd rather implement this on my branch and merge that first.

[emuell]

From what I can see and what I've tested, this is the raw string from the Pest Pair<> and not a serialized value:

afseq/src/tidal/cycle.rs

Line 31 in 8f4e78a

let string = pair.as_str().to_string();

[unlessgames]

Edit, nevermind. I got confused by seeing you've added the Pitch to string but I can see now that's only for tests.

[unlessgames]

I would rather merge my branch first and this one later but it's fine either way.

[unlessgames]

Now that the feature branch is merged, should I resolve the conflicts here?

[emuell]

No, thanks. I'm on it already.