[PD] a full-featured sampleplayer

[Roman Haefeli]

On Thu, 2008-08-07 at 23:41 +0200, Atte André Jensen wrote:
> 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) :-)

yo, i get your point as well ;-)

> > 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?

sorry, i think i was not clear:
if you go for the [vline~] route, then you can change the speed at any
time, but only at message rate (you have to send it a new message for
the new speed). theoretically you can send it as many messages as you
want, but this is probably not too effficient. on the other hand, you
can send a continuous audio signal to the left inlet of a [phasor~],
which means, that you can continuously change (no steps) the speed of
the sampleplayer. 
personally, i never had a case where i needed to _continuously_ change
the speed and i would lack the math to calculate the current position
anyway, so i always went for [vline~] route.

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

yo, this is what i meant with continuously changing the speed. hm.....
actually i don't know how to do that, if something like crossfading is
needed. interesting task.

roman


	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de