Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
parameters: Unify/simplify dynamic/continuous parameters
Mutwo parameters that can be identified by only one value inherit from 'core_parameters.abc.SingleValueParameter'. But what if these parameters are dynamically changing during the duration of one event (e.g. glissando, ritardando, crescendo, ...) ? Before this patch this problem was approached in two different ways: (1) The 'SingleValueParameter' Pitch has the attribute '.envelope'. This '.envelope' attribute can host a pitch interval trajectory that can be applied on the main pitch to create a glissando. Therefore all pitch classes have the option of an optional glissando. Whether this '.envelope' attribute is ignored or used is a decision of a given converter (or other (mutwo) code). (2) The 'SingleValueParameter' Tempo doesn't have the attribute '.envelope', but it is still possible to represent dynamic tempo trajectories by an additional 'TempoEnvelope'. This additional 'TempoEnvelope' itself isn't a 'Parameter' and certainly not a 'Tempo', but an 'Event' (that inherits from 'Envelope'). Mutwo infrastructure either expects a 'TempoEnvelope' or a 'Tempo', but never both. This patch aims to unify the way how 'SingleValueParameter' approach representations of continuous states. Instead of (1) or (2) another solution is declared, that also aims to significantly simplify how users can define continuous and discreet states of 'SingleValueParameter'. The unification aims to reduce code duplications and to make it easier to understand the 'mutwo' framework (provide only one way that needs to be learned and apply it for everything). Generally we could say that (1) is better than (2), because it treats continuous and discreet parameters in the same way and therefore makes it flexible to switch between them as needed. But more precisely, the solution (1) actually generalizes all discreet parameters to be continuous by giving all parameter classes an '.envelope' attribute: therefore actual discreet values don't exist anymore. This means that if users only want to use (the simpler) static parameters they still carried within their code continuous representations while they aren't needed. Furthermore this approach has the problem that the trajectory always needs to be relative to the identity of the parameter itself to be generally apply-able to all parameter implementations. This mean practically that trajectories can only be described in relative to the central value via deltas. In case of 'Pitch' this means we can only describe glissandi via pitch intervals that represent the moving delta to the 'Pitch' identity, but we can't describe glissandi by Pitch interpolations. The unifying solution therefore is different than approach (1) or (2). Neither do we add an '.envelope' attribute to all 'SingleValueParameter' nor do we use external events to describe continuous parameters. Instead, we do add a new 'parameters.abc' class: 'ContinuousParameterMixin'. In order to create a continuous version of a parameter, the new class can be created by inheriting from the parameter abc and the 'ContinuousParameterMixin'. This newly created class is both a 'Parameter' and an 'Event'. It must equally well implement the 'Parameters' interface, so that it is usable just like any other implementation of the given 'Parameter', but it must also behaves like an 'Envelope' so that dynamic trajectories of the parameter can be represented and interpreted if needed. This default version is an absolute envelope (as this is simpler), but a relative version could also easily be implemented if a user prefers this representation.
- Loading branch information