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... -- peace, love & harmony Atte http://atte.dk | http://myspace.com/attejensen http://anagrammer.dk | http://modlys.dk _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
