RE: Glissando: smoothing touch drags
RE: Glissando: smoothing touch drags
- Subject: RE: Glissando: smoothing touch drags
- From: Hari Karam Singh <email@hidden>
- Date: Wed, 15 Feb 2012 11:16:51 +0000
- Expiry-date: Sat, 14 Apr 2012 23:00:00 +0000
- Keywords: iOS
- Organization: AncientBohemia Ltd.
Sorry, I assumed you were pitch bending by an octave or so, not across the whole frequency spectrum! Please excuse the following, if I'm misunderstanding the details of what you are suggesting...
Yes, at 100 pixels or less, you might want some oversampling (of the UI, NOT the audio) with interpolation but that's separate from filtering. Glissando in midi is for spreading over time (ie "smoothing") instantaneous jumps from consecutive keyboard notes, not for the control knobs.
Still, the 20Hz audio update rate sounds too slow to me for perfect smoothness with fast motion no matter what you do with the UI sampling - that is unless you are interpolating pitch within the render function itself (ie on a per-frame basis). If so then I'd suggest that that's a major processing overkill, unless you are bound to the 20Hz refresh rate.
Native Instruments "Reaktor" synth creation environment, has a "Control Rate", separate from the sample rate, which is used for modules which generate pitch and volume information (VCA's and VCO's). 100Hz is an acceptable value in its drop down. 50Hz is the lowest I think. 200Hz is pretty average. I give this as evidence to support that you needn't invest CPU overhead in updating these values at any higher rate (like on a per-frame basis, which would be 44,100Hz!).
Basically, as you say it boils down to the resolution of the sampled UISlider values - specifically that they have the precision that 100Hz+ sampling will generate unique values, not steps. But if the pitch is then only updated at 20Hz intervals, it doesn't really matter what you do with interpolating the UISlider values at any rate >40Hz.
Also, the size of the jump in the frequency spectrum is not what creates the zipper sound. Large jumps at 200Hz will just sound like rapid pitch bending to the ear. It's this *combined* with a low audio control rate which creates the stepped zipper effect.
Again, my apologies if I'm missing the subtlety of your point!
Gratefully,
Hari Karam Singh
-----Original Message-----
From: coreaudio-api-bounces+harikaramsingh=email@hidden [mailto:coreaudio-api-bounces+harikaramsingh=email@hidden] On Behalf Of Richard Dobson
Sent: 15 February 2012 10:32
To: email@hidden
Subject: Re: Glissando: smoothing touch drags
On 15/02/2012 09:09, Hari Karam Singh 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.
>
Perhaps it is clearly to describe it as controlled interpolation
(whether as a line or a curve) - adding in the extra steps you would
otherwise get from your faster GUI update rate. It will always go from
the old value to the hnew value, over time, so as already mentioned
there is an aspect of latency to consider. We can't avoid very rapid
changes having some sort of quantising or modulating effect, if only for
psychoacoustic reasons. The primary job is to create smooth glitch-free
changes under "normal" use. We don't generally perform vibrato (AM or
FM) by wiggling a slider or knob very fast (well we can try, but it
probably won't sound too good) - we create a modulator oscillator to do
it for us. So if the design depends on extreme motions, perhaps it needs
a rethink.
> 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?
Yes, you do need a decent update speed, purely for user comfort and
naturalness. But update speed is not the only issue. You are also
limited by the number of widget control steps available. To describe it
most simply - if a slider control only has a range of 100 pixels, you
can't get a full MIDI precision of 128 steps however fast you update the
GUI. Some sliders may use 80 steps or fewer. If the slider is meant to
control frequency over the full audio range, there is no way it can
produce a smoothly continuous traverse without interpolation between the
available control positions. You may well need to arrange the result to
follow a log law (semitones/octaves rather than frequency; dB rather
than raw amplitude) in which case there is significant computation to
be done anyway; and running a fast GUI update will likely cost a lot
more CPU overhead than passing the plain control stream through a simple
filter.
In the end, this is an established an well-tested method, and easy
enough to implement - why limit yourself to guessing?
Richard Dobson
_______________________________________________
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