wevans@elec.gla.ac.uk

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).

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

how-to-find-sample-zero-points-in-real-time

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.

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). 

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


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

> 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...

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 Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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.

> 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.

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

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.

> 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...

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

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.

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.


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

> 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 

> 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 

Tap.Tools - Objects for Max, MSP, and Jitter

>> 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/


> 1) Even 20ms was sometimes not enough to avoid a click.

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 

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...

Quote: Stefan Tiedje wrote on Mon, 05 May 2008 17:09

----------------------------------------------------

> > 1) Even 20ms was sometimes not enough to avoid a click.

> 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.

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.

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.

Here is Edge Objection Approach (hopefully as suggested):

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

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.)

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

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

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.)

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.

> 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 

Use "Copy compressed" in the Edit menu (with 5.01 or higher). It's a 

>> 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.

How to Find Sample Zero-Points in Real Time