Feature request: make SampledEvent/Instrument step position driven

[hypeastrum]

It's not so flexible and handy to calculate sample position instead of step position. I've spend some time to understand that sample start/end/length are measured in samples not steps.

[igorski]

@hypeastrum I understand that sample based values are cumbersome, however they provide more flexibility when using the engine within contexts that aren't timed strictly "on the grid" (for instance : if you want to introduce "swing", drifting early/late events, you would have to displace them at the sample level to get the right effect).

However, in utilities/bufferutility.h you will find several convenience methods that translate time based values into sample based values. Additionally, I have just pushed a utilities/eventutility.h into the master-branch that provides a convenience method to position events within a sequenced step position-context. These two classes are also available to Java.

[hypeastrum]

I think, this method can be incapsuleted in BasiEvent.

Any way EventUtility::positionEvent methot seems to be not precise when many subdivisions used:
I suggest replace:

startOffset += ( bytesPerBar / subdivisions ) * offset;

with

startOffset += offset * bytesPerBar / subdivisions;

On 9 нояб. 2015 г., at 22:17, Igor Zinken notifications@github.com wrote:

@hypeastrum I understand that sample based values are cumbersome, however they provide more flexibility when using the engine within contexts that aren't timed strictly "on the grid" (for instance : if you want to introduce "swing", drifting early/late events, you would have to displace them at the sample level to get the right effect).

However, in you will find several convenience methods that translate time based values into sample based values. Additionally, I have just pushed a into the master branch that provides a convenience method to position events within a sequenced step position-context. These two classes are also available to Java.

—
Reply to this email directly or view it on GitHub.

[igorski]

@hypeastrum I think you're right, there is no need for a separate utility when the code is specific to AudioEvents !

I have created a branch "audioeventposition" featuring your request : #15

Can you review whether the implementation meets your request ?

[igorski]

Merged into master, updated Wiki.