Hi,
I'm working on a granular sampler borrowing parts of the patch on pd-tutorial (http://www.pd-tutorial.com/english/ch03s07.html).
Everything works smoothly except for one little annoying problem. If I fire the sample before the last one is through, sometimes I get a click at the beggining of the playback.
This is happening on a percussive sound (rapid envelope attack) so I'm guessing it's got something to do with [tabread4~] failing to interpolate between whatever the last amplitude value was and the first wavetable value.
This http://crca.ucsd.edu/~msp/techniques/latest/book-html/node63.html can probably be used to solve my problem, but I can't figure out how (or where in the patch) I should implement it.
Any clues would be greatly appreciated.
Thanks a lot, and have a good one.
ps. I tried to comment the patch to make it understandable. It is still, however a work in progress. Let me know of any questions.
Hi Federico -
tabread4~ doesn't interpolate between values of the input signal, or to put it another way, whast it does as a result of any input sample has no effect on what it will do on the next one. (It interpolates across the values of the table instead.)
One pretty good way to deal with discontinuities when moving discontinuously between samples is described here:
http://msp.ucsd.edu/techniques/latest/book-html/node63.html
cheers Miller
On Tue, Apr 22, 2014 at 01:00:49PM -0300, Federico Galland wrote:
Hi,
I'm working on a granular sampler borrowing parts of the patch on pd-tutorial (http://www.pd-tutorial.com/english/ch03s07.html).
Everything works smoothly except for one little annoying problem. If I fire the sample before the last one is through, sometimes I get a click at the beggining of the playback.
This is happening on a percussive sound (rapid envelope attack) so I'm guessing it's got something to do with [tabread4~] failing to interpolate between whatever the last amplitude value was and the first wavetable value.
This http://crca.ucsd.edu/~msp/techniques/latest/book-html/node63.html can probably be used to solve my problem, but I can't figure out how (or where in the patch) I should implement it.
Any clues would be greatly appreciated.
Thanks a lot, and have a good one.
ps. I tried to comment the patch to make it understandable. It is still, however a work in progress. Let me know of any questions.
-- Federico Galland federicogalland@gmail.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
An alternative method is to delay the audio by 5ms at all times. Then, when a transition occurs, do a very fast fade out/fade in with vline:
[tabread4~] | [delwrite~ $0-thisbuffer 5]
[delread~ $0-thisbuffer 5] | | [r changeChunk] | |
| [0 5, 1 3.5 6.5(
| |
| [vline~]
| /
[*~]
The reasoning behind the value of 3.5 for the fade in and 6.5 for the delay: A block of samples is 64 samples, or just over 1.41ms at 44.1KHz sample rate. Changing the sample or position of tabread4~ probably involves some non-signal rate processing, and that could happen any time between 0 and 1.41etc ms after the position or sample is changed. So if we wait an extra 1.5ms plus the 5ms delay before fading back in, we definitely will not get the click.
Works for me! The next Ninja Jamm update will contain this fix.
Cheers, Ed
Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/%C2%A0 On Tuesday, 22 April 2014, 17:08, Miller Puckette msp@ucsd.edu wrote:
Hi Federico -
tabread4~ doesn't interpolate between values of the input signal, or to put it another way, whast it does as a result of any input sample has no effect on what it will do on the next one. (It interpolates across the values of the table instead.)
One pretty good way to deal with discontinuities when moving discontinuously between samples is described here:
http://msp.ucsd.edu/techniques/latest/book-html/node63.html
cheers Miller
On Tue, Apr 22, 2014 at 01:00:49PM -0300, Federico Galland wrote:
Hi,
I'm working on a granular sampler borrowing parts of the patch on pd-tutorial (http://www.pd-tutorial.com/english/ch03s07.html).
Everything works smoothly except for one little annoying problem. If I fire the sample before the last one is through, sometimes I get a click at the beggining of the playback.
This is happening on a percussive sound (rapid envelope attack) so I'm guessing it's got something to do with [tabread4~] failing to interpolate between whatever the last amplitude value was and the first wavetable value.
This http://crca.ucsd.edu/~msp/techniques/latest/book-html/node63.html can probably be used to solve my problem, but I can't figure out how (or where in the patch) I should implement it.
Any clues would be greatly appreciated.
Thanks a lot, and have a good one.
ps. I tried to comment the patch to make it understandable. It is still, however a work in progress. Let me know of any questions.
-- Federico Galland federicogalland@gmail.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Thanks for your solution!
I actually ended implementing the switch and ramp technique described on Miller's book to quite good results. Anyway, I'll keep your suggestion in mind just in case!
Have a good one!
On Thu, May 15, 2014 at 3:48 PM, Ed Kelly morph_2016@yahoo.co.uk wrote:
An alternative method is to delay the audio by 5ms at all times. Then, when a transition occurs, do a very fast fade out/fade in with vline:
[tabread4~] | [delwrite~ $0-thisbuffer 5]
[delread~ $0-thisbuffer 5] | | [r changeChunk] | |
| [0 5, 1 3.5 6.5(
| |
| [vline~]
| /
[*~]
The reasoning behind the value of 3.5 for the fade in and 6.5 for the delay: A block of samples is 64 samples, or just over 1.41ms at 44.1KHz sample rate. Changing the sample or position of tabread4~ probably involves some non-signal rate processing, and that could happen any time between 0 and 1.41etc ms after the position or sample is changed. So if we wait an extra 1.5ms plus the 5ms delay before fading back in, we definitely will not get the click.
Works for me! The next Ninja Jamm update will contain this fix.
Cheers, Ed
Ninja Jamm - a revolutionary new music remix app from Ninja Tune and Seeper, for iPhone and iPad http://www.ninjajamm.com/
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ On Tuesday, 22 April 2014, 17:08, Miller Puckette msp@ucsd.edu wrote:
Hi Federico -
tabread4~ doesn't interpolate between values of the input signal, or to
put
it another way, whast it does as a result of any input sample has no
effect
on what it will do on the next one. (It interpolates across the values of the table instead.)
One pretty good way to deal with discontinuities when moving
discontinuously
between samples is described here:
http://msp.ucsd.edu/techniques/latest/book-html/node63.html
cheers Miller
On Tue, Apr 22, 2014 at 01:00:49PM -0300, Federico Galland wrote:
Hi,
I'm working on a granular sampler borrowing parts of the patch on
pd-tutorial (http://www.pd-tutorial.com/english/ch03s07.html).
Everything works smoothly except for one little annoying problem. If I
fire the sample before the last one is through, sometimes I get a click at the beggining of the playback.
This is happening on a percussive sound (rapid envelope attack) so I'm
guessing it's got something to do with [tabread4~] failing to interpolate between whatever the last amplitude value was and the first wavetable value.
This http://crca.ucsd.edu/~msp/techniques/latest/book-html/node63.htmlcan probably be used to solve my problem, but I can't figure out how (or
where in the patch) I should implement it.
Any clues would be greatly appreciated.
Thanks a lot, and have a good one.
ps. I tried to comment the patch to make it understandable. It is
still, however a work in progress. Let me know of any questions.
-- Federico Galland federicogalland@gmail.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
I remember some time ago complaining about the jitter in Pd's output timing and someone, maybe Miller, indicated a change I could do to the source to improve the timing, I'm guessing it wasn't something that ever got merged into the source. I forget what it was though.
Hi, you can reduce the jitter editing s_midi.c, changing:
if (midi_outqueue[midi_outtail].q_time <= midirealtime)
to
if (1)
and
if (midi_inqueue[midi_intail].q_time <= logicaltime)
to
if (1)
it works for midi note and ctl, so I think it will works even with MTC
-
Ed Kelly -
F Tux -
Federico Galland
-
Miller Puckette -
Nicola Pandini