| Age | Commit message (Collapse) | Author |
|---|
|
regression from previous commits; better handling
|
|
|
|
|
|
|
|
akai mpk mini 2 and similar midi pianos: this is a nice
way to select opl3 banks 0-127 using a knob, while the
pads are mapped to percussions on channel 9
|
|
|
|
if tempo changes while older events are in flight at different
timings in a multitrack file, and since there's no compensation
for it, tracks desyncronise, the order of events get jumbled up
and everything just falls apart.
rather than doing dances with the old code to figure out what
corrective factor to apply and where, just use the simplest and
most robust way, advance one tic at a time.
also add a tracing mode and don't always print useless and
annoying warnings.
|
|
fixes streaming, doesn't really affect performance elsewhere
|
|
games/dmid uses the same sample rate as the chip for music, but other
applications do not. opl3 and its older version opl2 (not in 9front)
read an input stream of commands in basically IMF format, something
used in other id Software games and some others, which assumes a
given input sampling rate: 700 Hz for Wolfenstein 3D music, 560 Hz
for Commander Keen, 60 Hz for Ultima 6, etc.
The opl3 emulation on the other hand is not really intended to run at
a sampling rate different that the chip's 49.716 kHz sampling rate.
Previously, we assumed it runs at 44.1 kHz and just used the input
rate as a divisor to get the number of samples per delay tic.
From what I understand, the correct way to use it for accurate
emulation is to run the opl chip emulator at its intended sampling
frequency, then downsample to 44.1 kHz. This means better output
but more code. The alternative is to basically do the same as
before rev 8433, except with no buffering, but at accuracy/quality
loss. This change implements the former and just forks pcmconv to
deal with resampling.
|
|
tested with a usb midi keyboard and a midi->usb adaptor
|
|
|
|
|
