Author: pacoeme

thanks for your help, im making a guitar patch that i´ve already done in other software, so i need to record or read a soundfile, then play it backwards or in different speed or starting in different points, i´ll share it when its finished thanks!

(with negative speed numbers)

http://www.pdpatchrepo.info/hurleur/Playback_speed_+_trigger.pd

>>
A metro, that is set to trigger every file-length divided by sample rate, divided by speed<<

the problem here is that if you change speed midway there will be funny biznizz

Heres an alternative using vline that doesn't have any funny bizness. When the rate is changed it calculates the time to the period end and from the period start to current point of change, so you can change the rate anywhere in the phase

I cant rememeber who made this - it was the result of constant badgering to make a phasor~ that resets phase sample accurately hence vphasor~

http://www.pdpatchrepo.info/hurleur/vphasor~.pd

I can't work out how to adopt this vphasor~ into a player.

@hardoff said:

>>
A metro, that is set to trigger every file-length divided by sample rate, divided by speed<<

the problem here is that if you change speed midway there will be funny biznizz

That's why If you change the speed you should let the metro know by banging it simultaneously.

@hardoff said:

disadvantage: the phase will only be reset at the start of the next block (64 samples by default). so, for slicing, phasor~ will cut off between 1 and 64 samples from the start of the next slice. for percussion sounds with a sharp attack, this can really dull the sound.

Can you tell me where i can find more info about the restarting of the phase? I don't really understand why phase would only reset after the next block. I trust you it does, but why/howcome?

to find more info... hmm, it's kinda hard, as far as i know, the block-boundary reset thing is not really documented much in pd's documentation. there have been several discussions about it on the mailing list though, so you could try searching the list archives with terms like 'phase, block, phasor' etc

as for why...there are audio processes that rely on having audio in blocks (FFT etc), and also cpu-wise i think there are probably savings from triggering a block at a time rather than sample by sample. ..but the main reason is that when miller designed pd, he designed it to work in blocks. i think some other softwares don't set blocks unless you instruct them to. a few of my friends won't use pd precisely because of the block restrictions. it seems like a bit of an arbitrary decision, and there are undoubtably pros and cons to both approaches, but pd is built around blocks, and will almost certainly stay that way.

some one throw me a float... (!)

(and not [float])

@hardoff said:

a few of my friends won't use pd precisely because of the block restrictions. it seems like a bit of an arbitrary decision, and there are undoubtably pros and cons to both approaches, but pd is built around blocks, and will almost certainly stay that way.

would [block~ 1] not remedy that? Supercollider works to a vector block size of 64 by default i think