posted 23 May 2009 04:16            

I'm using the (amazing) CrossFilter_Long module, with !KeyDown as a Capture trigger. I find that sometimes, on the onset of a note, there is a blip as the previously captured response is still active and audible. The documentation for the sound says:

"If you trigger the Capture while the Input is playing, you will hear the effects of the old filter on the CaptureDuration seconds of input that came in before the trigger occurred; this is mixed in with the effects of the new filter on the input that comes in after the trigger. If you silence the input for ResponseDuration seconds before triggering the Capture, then you will hear the effects of the new filter only."

I have taken care to silence the input for a good long period before each new note on event, but even so I still get these blips in which the previously captured response is still audible.

Any suggestions or insight? Anyone else noticed this behavior?

Thanks,

posted 24 May 2009 04:27            

Is this on capy or paca?

There are a few possible things going on here.

When you are triggering the new response it will happen at the next 1ms tick, if the sound that has just come from silence is not triggered in the same way then up to 1 ms of the new incoming signal could be processed by the out going response.

Also if the start and end are not at 0 and 1 then all the rules don't apply.

Also when you trigger the response the new incoming response over writes the out going response but if a second trigger comes in before the overwriting is completed old response is left there un erased. This will of course be erased eventually as triggered responses will flush all the way to the end so long as you done keep triggering new ones in.

So if you don't allowed your new incoming response to complete its write cycle because you are retriggering yet another response, you will get some of the end of the old response processing the new incoming sound.

If you are going to trigger early then you may have to pull the end time down to stop processing of un flushed responces.

A safer way to start a fresh, is to mute the response input and then trigger it and leave it for the duration of the response. This way you know you have a virgin silent crossfilter ready for you to put new stuff in.

I can only guess what is happening at this point as I'm not sure exactly how you are using it, but now with the new Paca you can have responces that are so long that sticking to the rule (keep the time between trigger longer than the duration of the response) is harder to do and easily forgotten.

hope it helps

Pete

posted 24 May 2009 06:58            

This is on a Capybara, and the responses in question are very short -- less than 100ms. Of all the possible explanations for the blip, I think that back-to-back triggers within the capture duration is the least likely on account of the short response durations involved.

(I've noticed that there seems to be some kind of minimum threshold on the response time below which the response seems not to be captured, or captured as all zeroes; it's somewhere around 20ms. Not too important to me, but I noticed it while playing around.)

Yeah, I've thought about arranging to open up the capture for a full response duration with the response input silenced, to clear out the buffer, but I was going to try to understand why exactly this is happening before going that route.

I'll look into the various possibilities you suggest and see if I can pin it down. Thanks again,

posted 24 May 2009 07:58            

Is it possible to post a copy of the sound and a few files showing the problem?

There is a 20 ms latency in the long which can be filled in with the short (with a bit of fiddling) and the capture duration goes up in 20ms steps in the long (not so in the short) but if between steps were really needed you could would window the response input.

If you are triggering a sample and the trigger the crossfilter capture from the same source you should get the whole sample from the beginning except that the samples players play the very first sample as silent even with the attack set to 0 s.

As a test if you delayed the signal (not response) going into the crossfilter by 20 ms does the blip disappear?

posted 24 May 2009 09:32            

Sorry, I see what's wrong now.

It's my original statement is misleading and I even mislead my self.

"If you trigger the Capture while the Input is playing, you will hear the effects of the old filter on the CaptureDuration seconds of input that came in before the trigger occurred; this is mixed in with the effects of the new filter on the input that comes in after the trigger. If you silence the input for ResponseDuration seconds before triggering the Capture, then you will hear the effects of the new filter only."

What I was trying to say hear is that when a new response comes in there will be a clean switch, such that input sample will be wholly processed by the the old response and at some point the input samples will then switch and will be wholly processed by the new response.
no input samples will be missed and none of them will be part processed by both or cut short, even though their outputs will be overlapping in time. What I didn't point out was that the point of switch over could be anything up to 10 ms after the capture gate had been triggered.

So the last part of my statement is in fact totally wrong. So to be sure to have the new response only processing your sound, you would in fact need to silence the input for a further 10 ms after triggering the capture.

The statement would be more true for the short crossfilter though.

Sorry for sending you up the garden path and hope you find a simple get round.

posted 24 May 2009 16:35            

OK, good, that corresponds to what I am hearing.

Thanks for helping me out with this!