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
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list
