Hi folks
I'm trying to build your classic sample player, with multiple key zones etc, but I'm getting kinda stuck with looping.
Any thoughts on how I might gracefully implement a player which plays a sample from the beginning when triggered, but then only loops a section, like my hardware sampler does?
The best solution I can think of is to use 2 tabread4~'s, crossfading for every pass of the loop. Anybody have a better idea?
I know I could just use a softsynth for this, but in a beautiful reversal, in this case it's actually easier to use pd.
Take that, propellerhead.
cheers dafydd
On 2/14/07, Dafydd Hughes dafydd61@gmail.com wrote:
The best solution I can think of is to use 2 tabread4~'s, crossfading for every pass of the loop. Anybody have a better idea?
I know I could just use a softsynth for this, but in a beautiful reversal, in this case it's actually easier to use pd.
Take that, propellerhead.
I believe that your solution for the loop is the "classic" solution that most samplers implement.
I didn't understand your comments about the soft synth though - are you saying that you think it's easier making a sampler in PD, than using a pre-made sampler? That seems a surprising conclusion, based on my own dabbling trying to create a sampler in Pd versus using software samplers (though the one I like best NI Intakt, which is more for one-shots, beat-slicing, and loops, and not for multi-samples).
~David
Hallo, Dafydd Hughes hat gesagt: // Dafydd Hughes wrote:
The best solution I can think of is to use 2 tabread4~'s, crossfading for every pass of the loop. Anybody have a better idea?
I'd do the looping a bit differently: Standard would be to use a [phasor~] scaled so that it plays a certain section of the sample with [tabread4~].
Example: Assuming you want to loopplay samples 1000 to 1050 at a loop-frequency of 100:
[phasor~ 100] | [*~ 50] because: 50 = sample_end - sample_start | [+~ 1000] because: 1000 = sample_start | [tabread4~ yoursample]
Playing the sample in full could be done with [vline~] as in one of the example patches in the docs (or use [play-samp~] from RTC-lib].
Now the tricky part is how to switch from the normal play to the looping phase without clicks. Maybe this can be realized most easily by just crossfading from the [vline~] player to the [phasor~] loop. Again RTC-lib might be useful: It has a little [crossfade~] abstraction that does constant-power crossfades.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hi Frank
The problem with the phasor~ is that I can't get a crossfade over the loop end (unless there's something I'm missing). Bummer - my loops aren't that clean.
I will look at RTC-lib. Thanks for the tip.
cheers dafydd
On 2/14/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Dafydd Hughes hat gesagt: // Dafydd Hughes wrote:
The best solution I can think of is to use 2 tabread4~'s, crossfading for every pass of the loop. Anybody have a better idea?
I'd do the looping a bit differently: Standard would be to use a [phasor~] scaled so that it plays a certain section of the sample with [tabread4~].
Example: Assuming you want to loopplay samples 1000 to 1050 at a loop-frequency of 100:
[phasor~ 100] | [*~ 50] because: 50 = sample_end - sample_start | [+~ 1000] because: 1000 = sample_start | [tabread4~ yoursample]
Playing the sample in full could be done with [vline~] as in one of the example patches in the docs (or use [play-samp~] from RTC-lib].
Now the tricky part is how to switch from the normal play to the looping phase without clicks. Maybe this can be realized most easily by just crossfading from the [vline~] player to the [phasor~] loop. Again RTC-lib might be useful: It has a little [crossfade~] abstraction that does constant-power crossfades.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hallo, Dafydd Hughes hat gesagt: // Dafydd Hughes wrote:
The problem with the phasor~ is that I can't get a crossfade over the loop end (unless there's something I'm missing). Bummer - my loops aren't that clean.
I will look at RTC-lib. Thanks for the tip.
Something else came to my mind: The [susloop~] external does everthing you need.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
susloop~...
Oh that's sweet!
I'd still love to get a crossfade happening, but this will do the trick for now.
I think 2 buffers will be the solution eventually, but my brain is beginning to hurt from the math.
Thanks for your help, guys
cheers dafydd
On 2/14/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Dafydd Hughes hat gesagt: // Dafydd Hughes wrote:
The problem with the phasor~ is that I can't get a crossfade over the loop end (unless there's something I'm missing). Bummer - my loops aren't that clean.
I will look at RTC-lib. Thanks for the tip.
Something else came to my mind: The [susloop~] external does everthing you need.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 2/14/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Dafydd Hughes hat gesagt: // Dafydd Hughes wrote:
The best solution I can think of is to use 2 tabread4~'s, crossfading for every pass of the loop. Anybody have a better idea?
I'd do the looping a bit differently: Standard would be to use a [phasor~] scaled so that it plays a certain section of the sample with [tabread4~].
I'm not sure this is good, for most uses. You can't assume that you have good loop points, I like to set random loop points on the fly, in fact - and so I think you really do need two buffers, because you are fading out the start at the same time you are fading in the beginning
- otherwise you get clicks. Or am I missing something in your
explanation?
I'm almost positive that the two buffer solution is what typical hard/soft samplers do, isn't that true?
~David
Hallo, David Powers hat gesagt: // David Powers wrote:
On 2/14/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Dafydd Hughes hat gesagt: // Dafydd Hughes wrote:
The best solution I can think of is to use 2 tabread4~'s, crossfading for every pass of the loop. Anybody have a better idea?
I'd do the looping a bit differently: Standard would be to use a [phasor~] scaled so that it plays a certain section of the sample with [tabread4~].
I'm not sure this is good, for most uses. You can't assume that you have good loop points, I like to set random loop points on the fly, in fact - and so I think you really do need two buffers, because you are fading out the start at the same time you are fading in the beginning
- otherwise you get clicks. Or am I missing something in your
explanation?
Actually I was assuming that you have good loop points indeed. From my (short) tracker days I remember that tuning the loop points in a sample was an important step to get it right. Fading in and out or cross has the disadvantage that you may get artifacts from the amplitude modulation.
However some approaches for fading (even with a single [tabread4~]) are shown in the docs in the various *sampler*.pd files.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On 2/14/07, Frank Barknecht fbar@footils.org wrote:
Actually I was assuming that you have good loop points indeed. From my (short) tracker days I remember that tuning the loop points in a sample was an important step to get it right. Fading in and out or cross has the disadvantage that you may get artifacts from the amplitude modulation.
However some approaches for fading (even with a single [tabread4~]) are shown in the docs in the various *sampler*.pd files.
Hi, I wonder, if I set loop points in SoundForge, which is my sound editor of choice (unless I'm doing very simple command line stuff in Sox), if PD has any way to get the .WAV metadata about the loop points???
Anyway, regardless of that, when I load samples into Native Instruments Intakt, I can set my own loop point on the fly. I often use this with glitchy samples, to choose a small portion and get an arbitrary pitch based on the loop length. The other thing that's cool is to take a longer sample - say of some kind of weird industrial machines - and arbitrarily set the loop to random points.
I suppose looping a clarinet or cello sample would be a whole different story, I guess if I'm working for something so traditional, I'd rather find something pre-looped than be bothered with that kind of pedantic thing... which again makes me think how nice it would be to support some different sampler formats in PD!
~David
Hallo, David Powers hat gesagt: // David Powers wrote:
I suppose looping a clarinet or cello sample would be a whole different story, I guess if I'm working for something so traditional, I'd rather find something pre-looped than be bothered with that kind of pedantic thing... which again makes me think how nice it would be to support some different sampler formats in PD!
You could use the [fluid~] externals for playing soundfonts.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Wed, 2007-02-14 at 21:26 +0100, Frank Barknecht wrote:
Hallo, David Powers hat gesagt: // David Powers wrote:
On 2/14/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Dafydd Hughes hat gesagt: // Dafydd Hughes wrote:
The best solution I can think of is to use 2 tabread4~'s, crossfading for every pass of the loop. Anybody have a better idea?
I'd do the looping a bit differently: Standard would be to use a [phasor~] scaled so that it plays a certain section of the sample with [tabread4~].
I'm not sure this is good, for most uses. You can't assume that you have good loop points, I like to set random loop points on the fly, in fact - and so I think you really do need two buffers, because you are fading out the start at the same time you are fading in the beginning
- otherwise you get clicks. Or am I missing something in your
explanation?
Actually I was assuming that you have good loop points indeed. From my (short) tracker days I remember that tuning the loop points in a sample was an important step to get it right. Fading in and out or cross has the disadvantage that you may get artifacts from the amplitude modulation.
this leads me to question, that is coming up to my mind again and again, but i still didn't come to a satisfying conclusion. there is another method of getting clickfree loops, that hasn't been discussed yet: detect zerocrosses and loop only from zero-cross to a zero-cross. but how are such things implemented in pd? the only way i can imagine to detect zero-crosses is to convert each audio-block to list of floats using [pack~] from zexy. this approach actually means, doing all the detection stuff in the 'message-domain', which is very cpu-consuming. how does one overcome this problem? this problem arises always, when an event (message) should be triggered on certain conditions in an audio-stream. i know a lot of such cases and it's always difficult, when not impossible to do it in pd. it can be quite frustrating to know the solution for certain problem, but at the same time being unable to implement it. i have the feeling, that these kinds of tasks are often delegated to externals, which is a pitty, since pd is an AUDIO-programming language.
did i miss something very fundamental in pd, that would answer all these questions?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
this leads me to question, that is coming up to my mind again and again, but i still didn't come to a satisfying conclusion. there is another method of getting clickfree loops, that hasn't been discussed yet: detect zerocrosses and loop only from zero-cross to a zero-cross. but how are such things implemented in pd? the only way i can imagine to detect zero-crosses is to convert each audio-block to list of floats using [pack~] from zexy. this approach actually means, doing all the detection stuff in the 'message-domain', which is very cpu-consuming. how does one overcome this problem? this problem arises always, when an event (message) should be triggered on certain conditions in an audio-stream. i know a lot of such cases and it's always difficult, when not impossible to do it in pd. it can be quite frustrating to know the solution for certain problem, but at the same time being unable to implement it. i have the feeling, that these kinds of tasks are often delegated to externals, which is a pitty, since pd is an AUDIO-programming language.
There is an external that detects zero-crossings. ;)
Now seriously: I think, one building block that is missing is Pd is the opposite of [vline~], that is and object that could schedule a message with sample-accuracy according to incoming samples, and not only with the accuracy of a block.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On Thu, 2007-02-15 at 14:08 +0100, Frank Barknecht wrote:
Hallo, Roman Haefeli hat gesagt: // Roman Haefeli wrote:
this leads me to question, that is coming up to my mind again and again, but i still didn't come to a satisfying conclusion. there is another method of getting clickfree loops, that hasn't been discussed yet: detect zerocrosses and loop only from zero-cross to a zero-cross. but how are such things implemented in pd? the only way i can imagine to detect zero-crosses is to convert each audio-block to list of floats using [pack~] from zexy. this approach actually means, doing all the detection stuff in the 'message-domain', which is very cpu-consuming. how does one overcome this problem? this problem arises always, when an event (message) should be triggered on certain conditions in an audio-stream. i know a lot of such cases and it's always difficult, when not impossible to do it in pd. it can be quite frustrating to know the solution for certain problem, but at the same time being unable to implement it. i have the feeling, that these kinds of tasks are often delegated to externals, which is a pitty, since pd is an AUDIO-programming language.
There is an external that detects zero-crossings. ;)
Now seriously: I think, one building block that is missing is Pd is the opposite of [vline~], that is and object that could schedule a message with sample-accuracy according to incoming samples, and not only with the accuracy of a block.
ah, thank you for translating my possibly cryptic post into a few clear words. that is exactly what i am looking for.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
-
Dafydd Hughes -
David Powers -
Frank Barknecht -
Roman Haefeli