Re: Glissando: smoothing touch drags
Re: Glissando: smoothing touch drags
- Subject: Re: Glissando: smoothing touch drags
- From: Admiral Quality <email@hidden>
- Date: Wed, 15 Feb 2012 04:47:48 -0500
We use these techniques to eliminate "zipper noise" in plug-in
instruments all the time. It's common for MIDI pitch bend messages,
despite their 14 bit depth, to be sent infrequently enough to still
require smoothing. A one pole IIR filter is the best way to smooth
these signals.
The amount of filtering needed to smooth out the quantization error
isn't enough to severely limit the rate or extents. Tweak to taste.
- AQ
On Wed, Feb 15, 2012 at 4:09 AM, Hari Karam Singh
<email@hidden> wrote:
> I'm inclined to guess that filtering isn't the right solution. If you have velocity V, motions below which sound smooth to the listener and above which sound disjoint then all that filtering is going to do is effective slow velocities greater than V down to less than V. If the motion involves rapid direction changes then filtering will effectively limit the pitch bend range as well, the faster the motion.
>
> I would think the problem is purely that the UI and/or audio update rates are too slow. Why is your audio callback only running at 20Hz? Can you make it faster, ie lower ioBufferDuration? Also in IB there is an option for UI elements labelled "updates frequently". Perhaps that will help. >=100hz will sound pretty smooth. 20hz definitely will not.
>
> There's no point running a timer faster than your audio render callback. Also atomic properties use locks so be careful. Their "atomicity" is invoked whenever you access them via their accessors (eg myobj.myatomicproperty) but not if you reference them directly (myobj->myatomicproperty).
>
> Hari Karam Singh
>
> Sent from my iPhone
>
> On 14 Feb 2012, at 21:51, Jean-François Brouillet <email@hidden> wrote:
>
>> Think of a glissando or portamento effect as the user moves a finger along some key.
>>
>> At 44.1 K, my 16 bits/mono AU generator kicks in every 43ms or so on an iPad 1. Let's make it 50ms to simplify the discussion, or 20Hz.
>>
>> As the sound is being produced, the user moves a finger over some key. I keep track of where the touch down started and where the finger is to deliver a number between 0 and 1. This applies to both horizontal and vertical movements, but lets pick one direction.
>>
>> The AU gen runs in some "AU thread", the touches detection in the main "UI" thread. Let's set aside the thread communication issues right now (I don't use locks, and pray that my ObjC side "atomic" property is seen as atomic too by the C++ side AU thread, but that's a discussion for another topic)
>>
>> Right now, if I move the finger "slowly" enough, I hear a nice continuous shift of the sound as the finger moves up and down.
>>
>> But if I move the finger "fast enough", I hear discontinuities, and I guess I understand why. When the finger moves "slowly" over, say 200 pixels/points my [0..1] range is divided into about 20ish steps resulting in
>>
>> 0.00, 0.05, 0.10 ... 0.90, 0.95, 1.00 for my parameter.
>>
>> When the finger moves "fast enough" the 200 or so pixels are spanned much faster resulting in many less values for my parameter, ie
>>
>> 0.00, 0.25, 0.50, 0.75, 1.00
>>
>> And at that point I can hear the discontinuity.
>>
>> What I am thinking of is "smoothing" those values (which will introduce some latency of course) as follows: start an NSTimer to kick in at about twice the rate of the AU callback, and whenever the parameter changes, the NSTimer would have a "time budget" of, say 100ms, to "glide" from the current value to the target value. A bit like CoreAnimation, but for sounds! :-)
>>
>> My expectation is that this would transform the series
>>
>> 0, 0.25, 0.50, 0.75, 1.0
>>
>> into, say:
>>
>> 0, 0.12, 0.25, 0.37, 0.50, 0.62, 0.75, ... 0.87, 1.00
>>
>> Intuitively, I'd run that timer at twice the AU callback rate (Shanon/Nyquist)?
>>
>> Any experience? Ideas or comments on the validity of that approach?
>>
>> Many Thanks
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Coreaudio-api mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Coreaudio-api mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden