MIDI pitch bend granularity?

[jimbo1qaz]

I'm writing a program which generates smooth volume/pitch/pan bends in a MIDI file. I'm using a fixed rate of 48 ticks per second.

MIDI doesn't natively support smooth bends, so I'm going to quantize them as a series of control change events.

What tick spacing should I use between adjacent events?

[Les Cargill]

Post by jimbo1qaz
I'm writing a program which generates smooth volume/pitch/pan bends in a MIDI file. I'm using a fixed rate of 48 ticks per second.
MIDI doesn't natively support smooth bends, so I'm going to quantize them as a series of control change events.
What tick spacing should I use between adjacent events?

It sounds like you want to "slew-rate limit" pitch bends. You want an
upper limit on the rate of change of pitch.

I would think evaluation of that would be arbitrary. The metaphor
I would think of is the knob on a Mini Moog which set the
portamento speed. It was variable.

[Pete]

Post by jimbo1qaz
I'm writing a program which generates smooth volume/pitch/pan bends in a
MIDI file. I'm using a fixed rate of 48 ticks per second.
MIDI doesn't natively support smooth bends, so I'm going to quantize
them as a series of control change events.
What tick spacing should I use between adjacent events?

My first comment would be that 48 tps seems a strangely low rate.
About the lowest rate I can find on a quick scan through my collection
is 240 ticks/quarter note, which at a standard 120 BPM (2 beats/sec)
is 480 ticks/sec.

Or maybe you don't mean midifile ticks, but the max rate that you want
to generate events?

In any case, what you obviously want is to avoid audible 'steps' in
the sweep, and that is going to depend on the actual rate of the sweep.
At any fixed event rate, a fast sweep is going to have bigger steps
that might be detectable, whereas a slower one would probably be heard
as smooth.

For many audio qualities, such as latency, 1/50 sec is often considered
the longest delay that will be tolerated, so I'd be inclined to emit
an event on each of your 1/48 sec ticks. Why not just experiment,
though?

-- Pete --

[jimbo1qaz]

Post by jimbo1qaz
I'm writing a program which generates smooth volume/pitch/pan bends in a MIDI file. I'm using a fixed rate of 48 ticks per second.
MIDI doesn't natively support smooth bends, so I'm going to quantize them as a series of control change events.
What tick spacing should I use between adjacent events?

Woops, I meant 48 ticks per beat/quarternote. I'm working on SNES/DS ripped MIDIs. The source material is 48 ticks per beat, and I don't want to needlessly complicate things with tick rate conversion.

But it seems like it's a good idea to emit events based on slew rate, not tick rate.

Would 48 control change events per beat significantly bloat the file?

[Pete]

Post by jimbo1qaz

Post by jimbo1qaz
What tick spacing should I use between adjacent events?

Woops, I meant 48 ticks per beat/quarternote. I'm working on SNES/DS
ripped MIDIs. The source material is 48 ticks per beat, and I don't want
to needlessly complicate things with tick rate conversion.

A quick google says that's Nintendo (?) Still seems rather low, but
I guess a game machine can be more tolerant.

Post by jimbo1qaz
But it seems like it's a good idea to emit events based on slew rate, not tick rate.

Think so...

Post by jimbo1qaz
Would 48 control change events per beat significantly bloat the file?

Gonna depend on how many of them you want to add. At full 48/beat and
120BPM, that's 96 events/sec, each 3 bytes long, so each second of each
control adds 282 bytes.

Whether you actually need full rate may depend on the control as well
as the slew rate. I'd guess the ear is less sensitive to pan position,
for instance, so quite a low event rate might be ample for that.

-- Pete --

[Pete]

Post by Pete

Post by jimbo1qaz
Would 48 control change events per beat significantly bloat the file?

Gonna depend on how many of them you want to add. At full 48/beat and
120BPM, that's 96 events/sec, each 3 bytes long, so each second of each
control adds 282 bytes.

^^^ 288!
Correcting my slightly sloppy thinking [and terrible mental arithmetic!!]...
I forgot the events will be going into a midifile, so each is preceded by
a delta-time. But at 48 tpqn that won't ever have to be more than a byte,
so the cost should be at the most 384 bytes/sec of control. In most cases
you can probably use running status, which trims the first (status) byte
off the event, so you might get back down to ~3 bytes/event.

I took a look at some files that use pitchbend, and the intervals they use
range from about 2 to 120 msec. Often they're quite dynamic, adjusting
each interval according to the slew rate at that point. The average
seems to be around 20 msec, though, which is one or two of your ticks.

-- Pete --

[Clifton Davis]

Post by jimbo1qaz
I'm writing a program which generates smooth volume/pitch/pan bends in a MIDI file. I'm using a fixed rate of 48 ticks per second.
MIDI doesn't natively support smooth bends, so I'm going to quantize them as a series of control change events.
What tick spacing should I use between adjacent events?

I'd say start by doing it once per tick and then halve your spacing and listen - and keep doing it until you can't hear a difference. Depends on your ear, the steepness of the bend and what you are using to play midi.