Updated performance timing to ticks instead of time.

[FelixWohlfrom]

This will make the overall implementation a lot easier
since we only need to take care of one time for both
performance and program wheel, not two separate ones.

Related: #16

[Tiedye]

It does not resolve #16, #16 is a different issue.

[FelixWohlfrom]

Yes, you are right. I confused it, since the commit was an outcome out of discussion in #16.

[mozi-h]

This has been sitting for a while now.
So, what exactly would be the benefit of only using ticks?

Separating them making sense as time is always tied to elapsed real time, when ticks are based on a changeable speed (that of the "crank"). Whether timed or ticked, the question of what happens to events after the time was edited remains (e.g. You post-edit in a crank speed change in the beginning of a performance).
So far, not making this editable (or only the last one) gets around this, whilst restricting performance construction (and editing), which would be nice to have.

[FelixWohlfrom]

The benefit would be a simplified implementation. As far as @Zakgriffin (or @ollpu) mentioned in discord (it's quite some time, sorry that I don't remember who of you it was), our playback framework used to play the audio also only uses ticks to play the song.
So if we stick to ticks, we will make our life a lot easier since we won't need any synchronization mechanism between ticks and time.

My proposal would be to do it in a staged approach - Version 1 works with ticks only (we will have enough to do to get that working) and once that is ready, we can continue to get real timed events then in Version 2 or whatever version after.