Allow string values for Named in cycle

[unlessgames]

Instead of filtering down to an Option<f64> we could allow for string value in Target::Named that could be remapped later like Value::Name.

This might be interesting to remap using input parameter values for example or having hardcoded defaults that are easy to change from the outside.

For example you could do something like (assuming a separate mapping function here for volume for simplicity)

cycle("c:v=p1 d"):volume(function(context, value)
  if value == "p1" then 
    return context.parameter.p1
  else 
    return value 
  end
end)

This would let you cleanly flag steps in the cycle to be later controlled via parameters (or other logic) at runtime for any property.

[emuell]

This could indeed be a better approach than the ones we've discussed here: #84, because it doesn't conflict with the existing map function and serves a single, well described purpose. If it's about mapping input parameter I'd prefer #95 though.

[unlessgames]

This could indeed be a better approach than the ones we've discussed here: #84

Note, this isn't an alternative to that I think. To me that discussion is mainly about being able to map the actual event with all of its properties available instead of just the raw note string whereas this is just to make substitution for property values convenient, in fact, this is an additional feature on the cycle side and would actually need the discussed transform function to be meaningful.

[emuell]

Why do you think the transform function needs this to be meaningful? Maybe I'm missing something here.

[unlessgames]

It's the other way around, this feature would need a transform function that applies (or at least supplies) the properties to you instead of overwriting the properties afterwards (resetting whatever you did like the current map), so that you can remap named property values as described here as well as regular ones.

The volume function above was just for the sake of decoupling from the undecided transform concept (probably more confusing in the end, sorry), in actual use ideally this could be used more like

-- "event" here already has all properties applied
cycle("c:v=steppy d e [g:v=steppy f]"):transform(function(context, event)
  if event.v == "steppy" then 
    local stepping_volume = context.step * 0.1
    event.v = stepping_volume - floor(stepping_volume)
  end
  return event
end)

[emuell]

I see. So this is just a technical detail about how Cycle stores properties, so that features such as transform can be added later? I think we'd do that in one go then when adding such a transform function as it else doesn't really serve a purpose.

The term 'transform' definitely makes sense here, as it is operating on fully evaluated note events, unlike 'map', which operates on string inputs to create note values.

[unlessgames]

So this is just a technical detail about how Cycle stores properties

We'd need to implement this on both sides, the cycle would accept string values for targets and the emitter would need to allow for such string values to make it through apply_cycle_note_properties, then we'd need an extra step after transform to validate that all such strings have been resolved to a valid float/int, similar to how it works with remapping named notes now.