hi all

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). but sorry, i don't have anything at hand, that matches your needs. i only have a recommendation (and i wonder, if others agree on that):

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, 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.

roman

On Thu, 2008-08-07 at 17:39 +0200, Atte André Jensen wrote:

Hi

I've build a sample player abstraction, and now I just thought of one more feature it needs, and that makes me think I need to redo it again. So here goes:

I need a sample player "motor" that is flexible enough to handle any (most) things I throw at it, at least:

• Handles stereo/mono, various sample rates and bit depths transparently.
• Allow changing of playback rate during playback
• Both lopping and non-looping mode
• Optional crossfade looping with configurable crossfade length.

First: Is there such a thing outthere already (before I redo it all again)?

Second: If not, a thing that I can't figure out is the cross-fade part. I thought about having two phasors, and every SAMPLELENGTH-XFADETIME restarting the idle one, and fading it up in XFADETIME while fading the running one down. Problem is that if the playback rate has changed since last cycle the switch will not be at the end of the running sample. Instead I guess the way to go is to look at the output of phasor~ and from it's output determine when it's time to start the fade, which should occur at (SAMPLELENGTH-XFADETIME)/SAMPLELENGTH. How can I inspect an audiosignal and get bang'ed when it's it reaches some value? I looked at [<~], but it seems to output audio, so I guess I can't use that. Or am I totally off in my approach?

Any input appreciated...

Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de