The key pitch input to getHarpStrata currently instructs the key of the harp returned. It could instruct the key that will result on the given Pozition. This may or may not be beneficial.
How this is delivered depends on the use cases which develop. I need to have a think about this.
I'm anticipating that the UI components for switching Pozition will want to identify the resulting key next to each Pozition. If the key is locked to the Pozition rather than the harp then these will all be the same and it will actually be the harp key which would be differently mapped from each position. Therefore this requirement would imply that we might want to also understand what harp key is returned in each position.
If we are returning a HarpStrata for each Pozition then this will be clear from the Pitch at HalfstepIndex 0, but it could be that returning 12 HarpStratas simultaneously would be quite a performance hit.
Depending on what we offer in the UI, it might be necessary to return even more HarpStratas than this, so it makes sense I think for this requirement to be elaborated further once the harpguru UI has been built with the existing harpstrata.
The key pitch input to
getHarpStratacurrently instructs the key of the harp returned. It could instruct the key that will result on the given Pozition. This may or may not be beneficial.How this is delivered depends on the use cases which develop. I need to have a think about this.
I'm anticipating that the UI components for switching Pozition will want to identify the resulting key next to each Pozition. If the key is locked to the Pozition rather than the harp then these will all be the same and it will actually be the harp key which would be differently mapped from each position. Therefore this requirement would imply that we might want to also understand what harp key is returned in each position.
If we are returning a HarpStrata for each Pozition then this will be clear from the Pitch at HalfstepIndex 0, but it could be that returning 12 HarpStratas simultaneously would be quite a performance hit.
Depending on what we offer in the UI, it might be necessary to return even more HarpStratas than this, so it makes sense I think for this requirement to be elaborated further once the harpguru UI has been built with the existing harpstrata.