about Bristol

(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).