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!

[sfread~] will do the trick. If you can find it.

does it do different speeds? backwards?

maybe i read somewhere once about some sort of upsampling hack to do that, but i can't remember.

the only way i know how to manipulate audio speed and jump around from point to point is to store it in an array, and then use [tabread4~]

if you're going to do that, then when loading the soundfile, you need to add a -maxsize tag to override pd's default limit for arraysize,

[read -maxsize [soundfilename] [arrayname] (
|
[soundfiler]

i think i read somewhere that you don't need the -resize tag if you use -maxsize, but didn't actually check yet.

As a foot note, are there any cases where you would use a [phasor~] rather than a vline~/metro combo to index the table?

...Or is it a preference thing?

I guess that the [phasor~] approach offers more flexibility since it can easily speed up/down, reverse, slice all by just altering the frequency/phase. It's also possible with [line~] or [vline~], but it becomes a little more complicated since you have to construct messages using [pack].

first approach, phasor~:

advantages: "it can easily speed up/down, reverse, slice all by just altering the frequency/phase"

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.

second approach: traditional vline~:

advantage: instant triggering allows for precise control of the audio stream.

disadvantage: you cannot change the rate of a vline~ once it is set.

my favourite approach: counter-driven vline~

make a very fast metro ([metro 1] is even ok), then connect that to a [f p]x[+ n] counter.

this counter is in turn connected to vline~ driven by [pack p p+n]---[$1, $2 1(, where n is the speed and p is the position.

to reset the sound, or jump to a different slice, just send the new value to the right inlet of the [f p], and then bang the metro to start straight away. by changing the value of n, speed / direction changes will take place within 1 ms, or instantly if a new slice is triggered.

probably didn't explain that too well, patch attached.

http://www.pdpatchrepo.info/hurleur/counter-vline.pd

Thats a very cool idea- means you get the best of both approches

but it aint half making Pd sluggish. Whats with that? Is it the 1ms metro? I'm running on one of the latest iMAcs

S

**edit** that would because I connected [print] to the output of the message box b4 vline~ then

tip - don't do that

IMO phasor~ is best for loops, vline~ for one-off samples

great stuff. just trying to work out how to get it to loop (by recognizing when playback has reached the end of the sample (or designated value).

Select seems to be too slow to catch the sample position (output of [metro] - [float]).

got it!

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

However, any ideas for the loop to work backwards too?

(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