(Copied from the included README file)
Bristol Emulations
------------------
This is a write-up of each of the emulated synthesisers. The algorithms
employed were 'gleaned' from a variety of sources including the original
owners manuals, so they may be a better source of information. The author
has owned and used a selection but far from all of the originals. Some of them
were built just from descriptions of their operation, or from understanding
how synths work - most of them were based on the Mini Moog anyway. Many of
the synths share components: the filter covers most of them, the Prophets and
Oberheims share a common oscillator and the same LFO is used in many of them.
Having said that each one differs considerably in the resulting sound that is
generated, more so than initially expected. Each release refines each of the
components and the result is that all emulations benefit from the improvements.
All the emulations have distinctive sounds, not least due to that the original
instruments used different modulations and mod routing.
The filter, which is a large defining factor in the tonal qualities of any
synth, is common to all the emulations. The filter implements a few different
algorithms and these do separate each of the synths: the Explorer layering
two low pass filters on top of each other: the OB-Xa using different types
depending on 'Pole' selection. Since release 0.20.8 the emulator has had a
Houvillainen non-linear ladder filter integrated which massively improves
the quality at considerable expense to the CPU.
There is one further filter algorithm used solely for the Leslie rotary
emulator crossover, this is a butterworth type filter.
Bristol is in no way related to any of the original manufacturers whose
products are emulated by the engine and represented by the user interface,
bristol does not suggest that the emulation is a like representation of the
original instrument, and the author maintains that if you want the original
sound then you are advised to seek out the original product. Alternatively a
number of the original manufacturers now provide their own vintage collections
which are anticipated to be more authentic. All names and trademarks used by
Bristol are ownership of the respective companies and it is not inteded to
misappropriate their use here. If you have concerns you are kindly requested
to contact the author.
The write-up includes the parameter operations, modulations, a description of
the original instrument and a brief list of the kind of sounds you can expect
by describing a few of the well known users of the synth.
Several emulations have not been written up. Since the APR 2600 was implemented
it became a rather large job to actually describe what was going on. If you
really want to know about the synths that are not in this document then you
might want to search for their owners manuals.
All emulations are available from the same engine, just launch multiple GUIs
and adjust the midi channels for multi timbrality and layering.
It is noted here that the engine is relatively 'dumb'. Ok, it generates a very
broad range of sounds, currently about 25 different synthesisers and organs,
but it is not really intelligent. Memories are a part of the GUI specification
- it tells the engine which algorithm to use on which MIDI channel, then it
calls a memory routine that configures all the GUI controllers and a side effect
of setting the controllers is that their values are sent to the engine. This is
arguably the correct model but it can affect the use of MIDI master keyboards.
The reason is that the GUI is really just a master keyboard for the engine and
drives it with MIDI SYSEX messages over TCP sessions. If you were to alter the
keyboard transpose, for example, this would result in the GUI sending different
'key' numbers to the engine when you press a note. If you were already driving
the synth from a master keyboard then the transpose button in the Brighton GUI
would have no effect - the master keyboard would have to be transposed instead.
This apparent anomaly is exacerbated by the fact that some parameters still are
in the engine, for example master tuning is in the engine for the pure fact that
MIDI does not have a very good concept of master tuning (only autotuning).
Irrespective of this, bristol is a synthesiser so it needs to be played,
tweaked, driven. If you think that any of the behaviour is anomalous then let
me know. One known issue in this area is that if you press a key, transpose
the GUI, then release the key - it will not go off in the engine since the GUI
sends a different key code for the note off event - the transposed key. This
cannot be related to the original keypress. This could be fixed with a MIDI all
notes off event on 'transpose', but I don't like them. Also, since the 0.20
stream the problem only affects a few of the emulations, the rest now sending
a transpose message to the engine and letting it do the work.
Since release 0.30.6 the engine correctly implements monophonic note logic.
Prior to this the whole engine was polyphonic and playing with one voice only
gave last note preference which dramatically affects playing styles - none of
the cool legato effects of the early monophonics. The quoted release fix this
limitation where the engine will keep a keymap of all played keys (one per
emulation) when started with a single voice and uses this map to provide
consistent note precedence, high note logic, low note logic or just using the
previously implemented last note logic. In this release the keymap was only
maintained with monophonic emulations, this is a potential extension as even
in polyphonic mode it would be useful for arpeggiation (which is currently
implemented using a FIFO rather than an ordered keymap).