[PD] a full-featured sampleplayer

[Roman Haefeli]

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