Looping within a wav file

choons

Hi- I'm trying to make a sample-based app that uses wav files. For instruments like a trumpet where the note can be sustained for up to several seconds, I play the wav sample from the beginning up to a pre-determined loop point in the file and then loop that section for the remaining duration of the note. I've been able to make this work seamlessly with vline~ and a del that bangs in the new vline~ parameters and a metro that keeps playing the loop.

I'd like to be able to bend the note, so I have been trying to use a vline~ to play the beginning part of the file and a del to trigger a phasor~ to play the loop part, but there is an audible lag between the end of the vline~ played part and the start of the phasor~ played loop.

I've also tried to get the note bend by using the vline/metro approach and making the looped section short and varying the metro period on each pass, but while that allows the seamless transition from the beginning part to the looped part the bend sounds awful.

Having worked with SoundFonts for some time, this seems like a very basic functionality. Can someone advise me the best way to play a wav file to transition from the initial attack portion into the loop section seamlessly and have the smooth note bend that the phasor~ gives?

mod

i'd just roll my own 'virtual phasor~' using a very fast (1ms) metro, a counter, a conditional expression, and a vline~ object.

so:

sorry, there's probably bits you'll have to fill in for yourself, but i hope that helps?

to do a pitch shift, you just scale that initial [+ 44.1] in your counter up or down.

choons

thanks, mod. I did end up with the same solution of keeping it all going through one vline~ and handling the looping with a metro like you have outlined.

To get the note bends to work in that setup, I shortened my loop sections in the wav file to around 1000 samples so that each pass through the loop is only about 20 ms or less. That way I can change the metro period slightly on each pass to give a smooth pitch bend without the audible stepping effect I was getting with longer loop sections.

I found the loop sections also need to be closer to the front of the file so that the initial attack portion of the instrument playing isn't too long before the note starts to bend. I'm finding that 75-100 ms before the looping section works well to get the character of the instrument and still have a bend that sounds right. Shortening everything up obviously loses some of the character of the recorded instrument, but is also good for me since I intend to use this on mobile devices as well.

I'm satisfied with the result, but still wonder why transitioning from a vline~ to a phasor~ doesn't happen cleanly?

At any rate, the solution you gave is more elegant than what I came up with and I hope it helps other folks having the same problem.

Maelstorm

@choons said:

still wonder why transitioning from a vline~ to a phasor~ doesn't happen cleanly?

It's probably because of how you are switching from [vline~] to [phasor~]. When trying to work with sample-accurate processing in Pd, you have to be aware of the fact that certain objects will only update at block boundaries, and some don't. And sometimes there are tricky hacks you'll need to do to get around that.

Also, you might want to look at [bsaylor/susloop~]. I think it does what you're looking for.

choons

thanks, Maelstrom. The way I was doing it was to simultaneously bang the vline~ values in and start a del with the same duration as the vline~. The del bangs in the frequency value to start the phasor~. All values pre-calculated, just needing a bang.

Like I said, there's always a lag from when the vline~ stops playing to when the phasor~ begins playing, whereas using the same del to bang new values into the vline~ to start the loop part playing and a metro to keep it playing works seamlessly.

The only thing I can think of is that a slight lag is introduced from the [*~] and the [+~] that the phasor~ output is routed through to get the sample offset & scaling before it goes into the [tabread4~] object. I don't think it's a discontinuity from what I hear, but just a lag from when the phasor~ is triggered to when it's actually "on."

Does a phasor~ object being used for the first time, with a given frequency banged in have some kind of block issue where it doesn't start at or very near zero as it begins ramping?

Also per your suggestion, I have to stay with vanilla Pd since I'm using this with libPd for mobile applications.

Maelstorm

When you bang a float to a signal inlet, such as the frequency inlet of [phasor~], it will ALWAYS update at the end of the block. [vline~] will make ramps that can start and stop in the middle of blocks, so unless it stops right at a block boundary, you'll get some timing issues.

If you need sample accuracy, you have to work with signals and avoid banging floats when possible. One thing you can try is testing the output of [vline~] with [==~ ] to test when the ramp is finished.

That will start the [phasor~] at the exact sample that [vline~] stops.

choons

ahh OK, that's a very subtle but obviously important distinction. Now I can emulate a SoundFont nicely on Pd! Thanks for the great help both of you.