How to Find Sample Zero-Points in Real Time

May 1, 2008 at 1:42am

How to Find Sample Zero-Points in Real Time

Hi,

I have a monophonic sampler, and switching to new notes has been a challenge. (When switching to a new sample, the old will stop anywhere, usually resulting in a click.)

Using envelope release (ADSR and LINE) and cross-fading (POLY,others) doesn’t work, because the tiny amplitude variations are very audible. I have to go full amplitude from one sample to another.

The only solution I can think of is to record when a new note comes in, and wait until the currently playing sample hits the zero point, which takes a tiny amount of time (which is good).

Any ideas on how to do this?

Bill

PS: MAX/MSP 5 is fantastic – thank you Cycling 74!

#37427
May 1, 2008 at 5:09am

have you tried the edge~ object?
It outputs a bang when a signal makes a transition from zero to non-zero or the other way around. Because you are trying to switch samples in such a small time frame it may still pop a little (i do not know how the object is programmed, that is, if the bang is synchronized with the zero point or if it is sent after it has left zero).

Obviously, you still need to make sure the sample you are switching to is well-edited, has no dc offset, and starts at zero as well. If you are using sfplay, make sure it is preloaded. I don’t know, try edge~ and store the trigger for the new note in “int” and use the bang from edge to release it at the correct time. If there is still a tiny pop make tiny adjustments by delaying the bang a certain amount of samples, maybe [that probably won't work so well, actually].

If that works, I would be glad to hear about it.

#129342
May 1, 2008 at 1:34pm

Thank you very much for your reply. I’ll try it and post my results.

Bill

#129343
May 2, 2008 at 8:16am

Bill Evans schrieb:
> Using envelope release (ADSR and LINE) and cross-fading (POLY,others)
> doesn’t work, because the tiny amplitude variations are very audible.
> I have to go full amplitude from one sample to another.

But going full amplitude from one sample to another is more audible than
an envelope, even if you do it on a zero crossing! From one sample to
another will create a click. loud if its non zero a bit less when its
zero crossing. A fade of 10 or 20 ms is inaudible for me…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#129344
May 3, 2008 at 4:30pm

> have you tried the edge~ object?

I have, but I may not understand it. A 440Hz signal should cause edge~ to fire 880 times a second. It’s firing about once a second. The edge~ object also isn’t firing with regular a regular period. Therefore, note change-overs tale up to a second.

Even then, I’m still getting clicking. I’m thinking that this may be an issue of speed: the entire patch must fire within the duration of one sample (1/44,100 of a second).

I would tremendously appreciate any ideas.

Thank you,

Bill

#129345
May 3, 2008 at 4:35pm

> But going full amplitude from one sample to another is
> more audible than an envelope, even if you do it on a zero
> crossing! From one sample to another will create a click.
> loud if its non zero a bit less when its zero crossing. A
> fade of 10 or 20 ms is inaudible for me…

I thought it would be, as well. But I’m sampling an instrument (bagpipes) that has no attack and no decay.

I found two things:

1) Even 20ms was sometimes not enough to avoid a click.
2) Even 10ms was enough to hear.

There is a commercial company that has created a hardware device with samples of the same instrument. Their samples are very short and looped. They said they switch over samples at full velocity by waiting until the previous note’s amplitude goes to zero (before triggering the next sample). This is what I (thought I) set up with edge~, but it’s not working for me. I may not understand what edge~ does.

Thank you for any time thinking about this.

Bill

#129346
May 3, 2008 at 5:03pm

i would record the sound as a short “note” which contains the natural starting and stopping envelope.
then load it in two buffers controlled by two play~’s or groove~’s or whatever you use. set looppoints on the sound where you want it to loop (say 100 ms from the beginning and 100 ms from the end), and perform a very short crossfade (20 ms) between the two samples every time it loops. when the sound starts, use the natural fadein envelope from the sample, and when it ends use the the natural fadeout envelope. cue the next sound as the fadeout is playing.

but maybe you’re already trying all this. wouldn’t really know without seeing a patch.

#129347
May 5, 2008 at 11:44am

On 2008 May 3, at 11:30 AM, Bill Evans wrote:

>> have you tried the edge~ object?
>
> I have, but I may not understand it. A 440Hz signal should cause
> edge~ to fire 880 times a second. It’s firing about once a second.
> The edge~ object also isn’t firing with regular a regular period.
> Therefore, note change-overs tale up to a second.
>
> Even then, I’m still getting clicking. I’m thinking that this may be
> an issue of speed: the entire patch must fire within the duration of
> one sample (1/44,100 of a second).
>
> I would tremendously appreciate any ideas.

It might or not help, but tap.buffer.snap~ in Tap.Tools provides the
nearest zero crossing in the buffer, updated every sample. These
problems can sometimes be a bit more tricky than that, but sometimes
this is all that is needed.

best,
Tim
____________________________________
Tap.Tools – Objects for Max, MSP, and Jitter

http://electrotap.com/taptoolsmax/

#129348
May 5, 2008 at 3:09pm

Bill Evans schrieb:
> 1) Even 20ms was sometimes not enough to avoid a click.
> 2) Even 10ms was enough to hear.

This sounds like a bug in your patch, which is likely, as your last post
also showed some lack of knowledge in general.
If you post the patch which causes the click, we could have a look at it.

You have to understand the difference between audio rate an scheduler to
get any further btw…

Stefan


Stefan Tiedje————x——-
–_____———–|————–
–(_|_ —-|—–|—–()——-
– _|_)—-|—–()————–
———-()——–www.ccmix.com

#129349
May 5, 2008 at 6:51pm

Quote: Stefan Tiedje wrote on Mon, 05 May 2008 17:09
—————————————————-
> Bill Evans schrieb:
> > 1) Even 20ms was sometimes not enough to avoid a click.
> > 2) Even 10ms was enough to hear.
>
> This sounds like a bug in your patch, which is likely, as your last post
> also showed some lack of knowledge in general.
> If you post the patch which causes the click, we could have a look at it.

I also feel you are most probably doing something wrong.
Since one millisecond is still 44.1 samples at a 44.1kHz SR, 10 milliseconds should be a large enough window of time to avoid clicks. But yes, you should be working at signal rate.

post it already ;)

regards,
kjg

#129350
May 6, 2008 at 5:19pm

Hi,

Thank you so much for all your responses, and constructive criticism. I really appreciate it.

I bought Tap.Tools and am very pleased with it.

I have created patches based on everyone’s suggestions. They are below, with photos.

Bill

#129351
May 6, 2008 at 5:54pm

Here is Edge Objection Approach (hopefully as suggested):

#129352
May 6, 2008 at 6:08pm

Here are the support file (~66 MBs):

http://billevansmedia.com/distribution/download/support_files-b_evans.zip

All files are copyright 2008 by Keir Murdo

#129353
May 6, 2008 at 6:16pm

Here’s the line object approach (10-20ms fade at the end of the note; implemented hopefully as suggested):

(I should mention that each patch I am posting functions as I intended; the results don’t sound good, though.)

#129354
May 6, 2008 at 6:22pm

Basically the LINE object approach, but with a full ADSR envelope:

#129355
May 6, 2008 at 6:30pm

Last but not least, the double buffer with double ADSR approach (hopefully, as implied/suggested):

#129356
May 6, 2008 at 6:32pm

There may be a few (very) minor errors in the patches; may have been lost in translation. (Should be obvious if there are, though.)

Again, thanks for all your help so far. I hope I am not flooding the board, but I wanted to give you guys the results of all your feedback. (I’ve still got two to do with Tap.Tools; I’ll post them tomorrow.)

Bill

#129357
May 6, 2008 at 9:13pm

Bill – please “copy compressed”.

-A

#129358
May 7, 2008 at 9:29am

> Bill – please “copy compressed”.

I’m not sure what that means; can you please explain?

I was going to make all the patches a download, but saw that other people posted the text elsewhere on the forum. Sorry if I’ve made a mistake in that.

Bill

#129359
May 7, 2008 at 1:35pm

On 7 mai 08, at 11:29, Bill Evans wrote:

>> Bill – please “copy compressed”.
>
> I’m not sure what that means; can you please explain?
>
> I was going to make all the patches a download, but saw that other
> people posted the text elsewhere on the forum. Sorry if I’ve made a
> mistake in that.

Use “Copy compressed” in the Edit menu (with 5.01 or higher). It’s a
encoded format which takes less space.

ej

#129360

You must be logged in to reply to this topic.