Roman Haefeli wrote:
Thanks for your input!
i think there is tons of such abstractions around. anyway, i like to re-implement it again and again everytime i need it, because there is always little things that i would like to have different from the current implementation and also it is always a good exercise (and probably i do better this time than last time).
Hmm, I get your point. I had hope to do the sample_player to end all sample_players (and then make some music with it) :-)
i wouldn't make your abstraction [phasor~] based, because of the problem you already sketched out: if you change the rate during the playback, you don't know when it is finished. that is why i propose to make any table based sampleplayer based on [vline~]. since you need to calculate the start-, endpoint and duration, you know at any time, where the index currently is (by calculating the current position from [timer] output and the three values i mentioned above). this way you can change the rate at any time you want,
I don't understand. Below you state "that you cannot continuously change the playback speed", what's the difference?
you just need to recalculate start, end and duration for [vline~]. it looks more complicated at the beginning, but it is the cleanest solution i can think of.
there is one disadvantage of the [vline~]-approach compared to the [phasor~]: you cannot continuously change the playback speed. so it is yours to decide, which way to go.
I just know, one day, I'm gonna want to touch that pitch bender of modulate that playback rate...