BRISTOL(1)

📦 version 0.60.11, in debian bookworm, debian trixie, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

🌈 BRISTOL(1) 🌈 — General Commands Manual

okay bestie, sit down, hydrate, because we're about to talk about bristol 💖

✨ NAME ✨

bristol — a synthesiser emulation package. that's it, that's the whole vibe. 💅

🎀 SYNOPSIS 🎀

startBristol -mini -jack -midi seq [options]

🦋 DESCRIPTION 🦋

bristol is a vintage synthesiser software emulator suite, no cap. the whole thing is two pieces working as a duo: an engine literally called bristol, and a graphical user interface called brighton. the GUI is a bitmap manipulation library that draws all the cute synth devices — potentiometers, buttons, sliders, patch cables — and it's the thing that generates the messages which configure the synth emulator. meanwhile the engine is the infrastructure hosting the emulator code, coupling together the different audio operators you need to actually generate audio. 👑

the engine and the GUI get started together by the startBristol script, which sets up the required environment so the two can connect to each other. it is not generally envisaged that bristol and brighton get started outside of the script — but there are options on the script to start only one or the other, so you do you. bristol also has a command line interface that you can use instead of the GUI. 💫

currently the following synthesizers are emulated:

🌸 Emulations 🌸

  • moog mini
  • moog explorer (voyager)
  • moog voyager electric blue
  • moog memory
  • moog sonic 6
  • moog/realistic mg-1 concertmate
  • hammond module (deprecated, use -b3)
  • hammond B3 (default)$
  • sequential circuits prophet-5
  • sequential circuits prophet-5/fx
  • sequential circuits prophet-10
  • sequential circuits pro-one
  • fender rhodes mark-I stage 73
  • fender rhodes bass piano
  • crumar roadrunner electric piano
  • crumar bit 01
  • crumar bit 99
  • crumar bit + mods
  • crumar stratus synth/organ combo
  • crumar trilogy synth/organ/string combo
  • oberheim OB-X
  • oberheim OB-Xa
  • arp axxe
  • arp odyssey
  • arp 2600
  • arp/solina string ensemble
  • korg polysix
  • korg poly-800
  • korg mono/poly
  • korg ms20 (unfinished: -libtest only)
  • vox continental
  • vox continental super/300/II
  • roland juno-60
  • roland jupiter-8
  • baumann bme-700
  • bristol bassmaker sequencer
  • yamaha dx-7
  • yamaha cs-80 (unfinished)
  • commodore-64 SID chip synth
  • commodore-64 SID polyphonic synth (unfinished)
  • granular synthesiser (unfinished)
  • ems synthi-a (unfinished)
  • 16 track mixer (unfinished: -libtest only)

so like, how do the engine and the GUI actually talk to each other? the default connection is a TCP socket using a SYSEX format message taken from MIDI. optionally the code will use a unix domain socket for improved security. 🔐 and here's the iconic part: the GUI and engine do not need to be resident on the same system if you give suitable parameters — but that feature requires the TCP domain sockets be used. iykyk.

the engine can also accept requests from multiple brighton interfaces and run all the emulators at the same time, multitimbraly, sharing voices between them and pre-empting where necessary. 🎛️

if an emulator is started in monophonic mode then it is preallocated a voice that will never be pre-empted and which runs continuously — ie, by default it will continue to run even when no piano keys are pressed. the polyphonic code, by contrast, will only run the voice algorithms whilst the key gate is open, the gate being derived from the voice envelope state.

the engine supports minimally 32 voices per default. if an emulator requests less then its emulation is configured with a soft limit. if more are requested then more voices are created — however the upper limit is imposed at 128 voices. a voice is an engine structure that allows for allocation and executing, and the actual code run by a voice can be any of the emulator algorithms, which is literally how multitimbral operation is supported. 💀 the voice allocation process is 'last note precedence' and whilst others are available for the monophonic instruments, this is the only polyphonic assignment algorithm.

this package should be started with the startBristol script. the script will start up the bristol synthesiser binaries, evaluating the correct library paths and executable paths. there are emulation, synthesiser and operational parameters: 🌟

💅 OPTIONS 💅

🎹 Emulation:

  • -mini — moog mini
  • -explorer — moog voyager
  • -voyager — moog voyager electric blue
  • -memory — moog memory
  • -sonic6 — moog sonic 6
  • -mg1 — moog/realistic mg-1 concertmate
  • -hammond — hammond module (deprecated, use -b3)
  • -b3 — hammond B3 (default)
  • -prophet — sequential circuits prophet-5
  • -pro52 — sequential circuits prophet-5/fx
  • -pro10 — sequential circuits prophet-10
  • -pro1 — sequential circuits pro-one
  • -rhodes — fender rhodes mark-I stage 73
  • -rhodesbass — fender rhodes bass piano
  • -roadrunner — crumar roadrunner electric piano
  • -bitone — crumar bit 01
  • -bit99 — crumar bit 99
  • -bit100 — crumar bit + mods
  • -stratus — crumar stratus synth/organ combo
  • -trilogy — crumar trilogy synth/organ/string combo
  • -obx — oberheim OB-X
  • -obxa — oberheim OB-Xa
  • -axxe — arp axxe
  • -odyssey — arp odyssey
  • -arp2600 — arp 2600
  • -solina — arp/solina string ensemble
  • -polysix — korg polysix
  • -poly800 — korg poly-800
  • -monopoly — korg mono/poly
  • -ms20 — korg ms20 (unfinished: -libtest only)
  • -vox — vox continental
  • -voxM2 — vox continental super/300/II
  • -juno — roland juno-60
  • -jupiter — roland jupiter-8
  • -bme700 — baumann bme-700
  • -bm — bristol bassmaker sequencer
  • -dx — yamaha dx-7
  • -cs80 — yamaha cs-80 (unfinished)
  • -sidney — commodore-64 SID chip synth
  • -melbourne — commodore-64 SID polysynth (unfinished)
  • -granular — granular synthesiser (unfinished)
  • -aks — ems synthi-a (unfinished)
  • -mixer — 16 track mixer (unfinished: -libtest only)

🧚 Synthesiser:

  • -voices <n> — the selected emulator will start with this number of voices. the engine will always create 32 voices but only allocate this subset to the emulator. if the selected value is greater than 32 then the greater number of voices is allocated. ✨
  • -mono — run the emulator in monophonic mode. this is not really an alias for -voices 1 — because it additionally configures parameters such as -retrig -lvel -wwf -hnp. those additional options can be overridden if desired. 🫶
  • -lnp — select low note precedence logic. this only applies to monophonic synthesisers and all of the note precedence affect the legato playing style.
  • -hnp — select high note precedence logic. this only applies to monophonic synthesisers.
  • -nnp — select no note precedence, this is the default and operates as a last note precedence selection.
  • -retrig — request a trigger event for each note that is played AND notes that are released. the trigger will cause the envelopes to cycle. they will not return to zero by default however some of the emulations have that as a GUI control. without this flag, triggers are only sent for the first pressed note of a sequence. 🔥
  • -lvel — configure velocity inheritance for all legato notes: the first note of a sequence will have a velocity value that is applied to all subsequent notes. this option is a toggle: applying twice will disable the feature. this is important with regards to the emulators as many of the mono synths with set lvel per default. the following options may not work as expected:
startBristol -mini -lvel

the issue is that -mini enables legato velocity so the -lvel switch will toggle it off again. the same applies to -retrig. 😭

  • -channel <c> — start the emulator to respond on this MIDI channel, default 1.
  • -lowkey <n> — configure the lowest note for which the emulator should respond. this defaults to '0' but can be used to define key splits and ranges for different synths.
  • -highkey <n> — configure the highest note for which the emulator should respond. this defaults to '127' but can be used to define key splits and ranges for different synths.
  • -detune <%> — request the emulator run with a level of temperature sensitivity. the default value is defined by the emulator, typically 100 or 200. the detune is applied to a voice at note on only, and is a random value within the range defined here. 🌡️
  • -gain <gn> — output signal gain level for the emulator. these can be used to normalise the signal levels from different synths when played together. the default value is defined by the synth itself, this is an override.
  • -pwd <s> — pitch wheel depth in semitones, default 2.
  • -velocity <v> — velocity curve for the emulator. default is 520, an exponential curve for a hard playing style. value '0' is flat (no touch sensitivity). values up to 100 are linear scaled maps. the velocity map is a table of points that is interpolated linearly: you may only have to define the inflexion points, however if you want smooth curves you will have to define each of the 128 velocity values that are used in noteon/noteoff events. the emulation only has a single table of gain levels for each key.velocity index, the engine by contrast has two tables, one for each on/off event — however that is an integer map, not a gain map. 👑

there are several default tables if you do not want to specify your own interpolated curve. each table is the gain for the Midi velocity value given in the note event, it has 128 entries. the following are implmented:

  • 100-199 — Convex curves for a soft touch keyboard player
  • 200-499 — Concave curves for a hard touch, linear up to quadratic function.

okay so the next set, all the way up to 525, is literally the same thing as above but with way less granularity. In that range the value 200 is linear, and so is 510 further down:

  500-509 Convex curves for a soft touch keyboard player
  510 linear
  511-25 Concave curves for a hard touched player.

Then there's a couple of specific curves, bestie:

  550 logarithmic
  560 parabolic

And then the values up to 100? Those are two-digit numbers, and the digits are doing work. The first digit = how late the line starts (it's linear) ramping up. The second digit = how late it hits 1.0. So 09 is basically the linear mapping from above — starts at 0, ends almost at the end. A 49 is for a heavy player: it's zero for a big chunk of the velocity table and then ramps up to max gain (1.0) right near the end. Note that these tables could also have been defined with velocityMap definitions, because they're linear interpolations. A present release will include curves to smooth things out a little.

Option 520 is a squared powercurve and honestly feels quite natural, though that's very subjective. Maybe it's natural for a hard player, and maybe it's a better default than the linear curve. 👀

The value 1000 inverts the mapping, so:

  1510 - linear from 1.0 down to 0.0 as velocity increases
  1520 - exponential, from 1.0 down to 0.0 as velocity increases

The engine mapping gets applied before the emulation mapping given here. There are reasonable arguments to make this table logarithmic — you're welcome to do so, no one's stopping you. There are no limits on the values here other than that negative values are not mapped, so this table can also be used to compensate for volume levels. 💅

  • -glide <s> — duration of nogte glide in seconds, default 5.
  • -emulate <name> — search for the named emulator and invoke it, otherwise exit. Invoking an emulation this way is currently the default, and it implies extra parameters for voicecount, gain, glide, pitchwheel depth, detune, etc. Default is hammondB3. The -emulate option also implies -register to the emulator name.
  • -register <name> — use a specific name when registering with Jack and ALSA. By default the engine uses the name 'bristol', but that can get confusing when multiple engines are running, so this is your override.
  • -lwf — select lightweight filters for the emulator.
  • -nwf — select normalweight filters, the default. These cost about twice as much as the lightweight ones.
  • -wwf — select welterweight filters, which are again about double the CPU load of the normal filters.
  • -hwf — select heavyweight filters. Roughly twice the welterweight filter. ngl while there's a noticeable audible difference between -lwf and -nwf, it's debatable whether the difference between -nwf, -wwf and -hwf is anything other than visible in the CPU load. The default filter for any -mono synth is -wwf, which you can override with something like '-mini -mono -nwf'.
  • -blo <h> — number of bandwidth limited harmonics to map. A value of zero selects infintite bandwidth. Default is 31.
  • -blofraction <f> — the engine uses precomputed tables for all frequencies where the maximum harmonic doesn't exceed this fraction of the samplerate. The default, 0.8, is already above nyquist as a tradeoff between content and distortion. Values tending towards 1.0 are heavily aliased at the higher frequencies naturally. you've been warned bestie
  • -scala <file> — the engine will read the given scala file and map it into its frequency tables.

🎀 User Interface 🎀

  • -quality <n> — the color cache depth affects rendering speed. Lower values start showing loss of clarity, higher values start using thousands of colors, which is where performance takes the hit. Value is in bpp, default is 6.
  • -scale <s> — each emulator has a default window size, and this lets you scale it up or downwards if you want.
  • -width <n> — the pixel width defines the smaller of two sizes that can be configured. It works together with the -scale and -autozoom options for flipping between different sizes on mouse Enter/Leave of the window.
  • -autozoom — minimise window on exit, maximise on enter. ✨
  • -raise — automatically raise the window on Enter.
  • -lower — automatically lower the window on Leave. heads up: it's noted here that the use of autozoom, raise and lower may have undesirable effects with some window managers.
  • -rud — constrain the rotary controller tracking to mouse up/down motion, not to actually track the mouse position. The value will be a fraction of the current window size.
  • -antialias <%> — for some window sizes there'll be pixelation of the rendered imagas unless some antialias is applied. With large zoom values this is automatically set up. Value is a percentage, default is 30.
  • -aliastype <pre/texture/all> — there are three antialiasing options: pre applies it to the text silkscreens, texture applies it to the surface bitmaps, and all applies it everywhere including devices rendered. The default is pre, however this parameter is only applied if -antialias has a value other than zero.
  • -opacity <%> — Brighton uses a transparency layer for some features such as the ARP 2600 patch cables. This is the default transparency. It can be adjusted later with the ^o/^O/^t control codes in the GUI. Default is 50 percent.
  • -pixmap — use the X11 pixmap interface rather than the default XImage interface to the server.
  • -dct <ms> — double click timeout for button events, etc, 250 ms.
  • -tracking — prevent the GUI piano keyboard image from tracking MIDI events. Small reduction in CPU overhead.
  • -keytoggle — the default GUI behaviour for tuning keys on with the mouse is to latch them, which lets you play chords on the polyphonics. This option disables the latch so keys are played only whilst held with the mousebutton.
  • -neutral — initial the emulator with a null patch; all parameters get the value of zero so you can build a patch from the bottom up, completely from scratch. This is equivalent to '-load -1', and negative memory locations will not be saved, ie, you cannot save to the null patch. 🫶
  • -load <m> — initial memory number to load at startup. Default is 0 for most emulators.
  • -import <pathname> — import a memory from a disk file to the active patch at start time. This patch can then be saved to another location, which allows for interexchange of memories.
  • -mbi <m> — the master bank index allows for access to extra memory ID. This value times 1000 is added to the memory ID saved/loaded by the GUI, so the GUI can access, for example, 8 banks of 8 memories — but using -mbi you can actually save multiple sets of 64 memories. iconic tbh
  • -activesense <ms> — the rate at which hello messages are sent from GUI to engine to make sure it's still active. If the transmission fails then the GUI will exit, and if the engine doesn't receive updates it will also exit. Zero disables active sense.
  • -ast <m> — the engine timeout period on active sense messages.
  • -mct <m> — the MIDI cycle timeout is a busy waiting GUI timer for MIDI events, used when the GUI takes a MIDI interface for direct event tracking.
  • -ar | -aspect — all of the emulators will attempt to maintain an aspect ratio for their windows so they look 'normal'. This conflicts with some tiling window managers so it can be disabled. It may also cause some excessive remapping of windows when they're resized.
  • -iconify — open the window in the iconified state.
  • -window — do not map any window.
  • -cli — enable the text based command line interface to the engine. This can be used in connjuction with -window, however if compiled without support for any windowing system the -window option is implied.
  • -libtest — do not start the engine, nor attempt to connect to it, just post the GUI for testing.

⌨️ GUI Shortcuts ⌨️

the group chat cheat sheet, memorise it bestie

  <Ctrl> 's'     - save settings to current memory
  <Ctrl> 'l'     - (re)load current memory
  <Ctrl> 'x'     - exchange current with previous memory
  <Ctrl> '+'     - load next memory
  <Ctrl> '-'     - load previous memory
  <Ctrl> '?'     - show emulator help information
  <Ctrl> 'h'     - show emulator help information
  <Ctrl> 'r'     - show application readme information
  <Ctrl> 'k'     - show keyboard shortcuts
  <Ctrl> 'p'     - screendump to /tmp/<synth>.xpm
  <Ctrl> 't'     - toggle opacity
  <Ctrl> 'o'     - decrease opacity of patch layer
  <Ctrl> 'O'     - increase opacity of patch layer
  <Ctrl> 'w'     - display warranty
  <Ctrl> 'g'     - display GPL (copying conditions)
  <Shift> '+'    - increase window size
  <Shift> '-'    - decrease window size
  <Shift> 'Enter'- toggle window between full screen size
  UpArrow        - controller motion up (shift key accelerator)
  DownArrow      - controller motion down (shift key accelerator)
  RightArrow     - more control motion up (shift accelerator)
  LeftArrow      - more control motion down (shift accelerator)

🔥 Operational options 🔥

General:

  • -engine — do not start a new engine. The GUI will attempt to connect to an existing engine on the host and port configuration (cq). If the connection is built then the engine will operate both emulators and voice allocations will be shared amongst them. All of the emulator outputs are folded back onto the same stereo output, excepting where extra Jack control inputs are used.
  • -gui — do not start the GUI, only the engine. The GUI will attempt to connect to the engine on the configured host and port values. If it doesn't respond then the GUI will exit with some rather terse messaging. 💀
  • -server — start the engine as a permanant server that does not exit with the last emulator.
  • -daemon — runs the engine as a daemon with a disconnected controlling terminal. heads up though: this does not imply -server, and it doesn't imply -log (the file-system logging one) either, and it doesn't imply -syslog — both of which might also apply to a daemon. They're separate things, bestie, you gotta ask for them 💅
  • -watchdog <s> — the timeout for audio thread initialisation. If the thread doesn't wake up and activate within this period, the engine will gracefully exit instead of sitting there waiting around for connections forever like an idiot. Default period is 30 seconds. This is not active in -server or -daemon mode. In normal operation the audio thread launches within a couple of seconds, but if you start the engine and the GUI separately, then this timeout is basically demanding that a GUI gets started before the timer runs out. ⏰
  • -log — redirects logging output to a file. The default files are /var/log/bristol.log and /var/log/brighton.log, and if those aren't available then the $HOME/.bristol/log directory gets used instead. The whole reason /var/log is picked is to stop logging to root in the event that the engine gets invoked by that user. 🗂️
  • -syslog — redirects logging output to syslog.
  • -console — keeps the controlling terminal as the output for logging messages, and strips the timestamps for readability. You can also set this up with the environment variable BRISTOL_LOG_CONSOLE=true. 🖥️
  • -rc — do not load any bristolrc parameter file.
  • -exec — the final process requested by the startBristol script will be called as an exec, so that it maintains, among other things, the PID of the parent. This option will override the exec and leave the script waiting for the processes to exit. The implications of not using this parameter: some of the cleanup code lives inside the wrapping shellscript, and per default that isn't called because of the exec request. This flag is the default, but should only really be needed for LADI compatibility.
  • -stop — stops all the running bristol engines. This indirectly results in termination of any GUI too, thanks to active sensing — although that can be disabled. The use case is stopping any -server -daemon engines running in the background. The back end to this option is pkill. 💀
  • -exit — stops all the running bristol engines and GUI.
  • -kill <-emulator> — stops all the running bristol engines and GUI that have been associated with the given emulator. So if bristol was started with -mini, it can now be killed with -mini so that your other emulators don't get terminated. If there are multiple mini running, they'll naturally die too. And if the engine is running a multitimbral GUI, then the other associated GUI will exit as well, in addition to the mini. 🎯
  • -cache <pathname> — the default location for new memories and emulator profiles. Default is ~/.bristol, and it gets searched before the system/factory default directory /usr/local/share/bristol whenever emulators are started and memories are loaded. If the pathname doesn't exist then it gets created, if possible.
  • -memdump <pathname> [-emulate <synth>] — creates the target directory <pathname>/memory/<synth> and copies the factory default memories for the synth first, then the user private memories. This can be used with session management to make a copy of all synth memories in a session. If the target directory already exists then no copy operation happens, but the directory does replace the -cache default, making this the new location for saved memories for that session. The -emulate option is required — if you don't provide it, the default hammondB3 gets taken. 🎹
  • -debug <1-16> — debug level. Values above 12 can be very verbose, and only the value 0 is arguably realtime safe, since it avoids printf() in the engine compute thread. 😭
  • -readme [-<e>] — displays the program readme information. You can show the readme for just a single emulator if you want.
  • -glwf — only allows the use of '-lwf' for all emulators. No overrides. 🙅
  • -host <hostname> — connects to the engine on the hostname; default is localhost. This is used together with -engine to distribute the GUI. The hostname accepts syntax like hostname:port to fix both the host and the port for a remote connection to the engine. If the host portion is the token 'unix' then a local named socket gets created instead of a TCP connection. In that case you can give a specific port number to create the named socket /tmp/br.<port>, and if the port isn't specified then a random numeric index is chosen. 🌐
  • -port <p> — connects to the given TCP port for GUI/engine messaging, default 5028. If the port is already in use then the startup will fail. If you're starting multiple bristols with GUI, then this option should be discarded and the script will go looking for a free port number for each invocation. It is incorrect to mix this option with -host parameters that take a value like host:port or unix:port, because the results will be indeterminate depending on the order the parameters are submitted. 🚫
  • -quiet — redirects debug and diagnostic output to /dev/null. 🤫
  • -gmc — opens a MIDI interface in the GUI. Per default, the engine owns the only MIDI interface for bristol and redistributes events to the GUI. It's possible to disable that forwarding and attach both GUI and engine to MIDI devices if you need to.
  • -forward — disables MIDI event forwarding globally. Per default the engine opens a MIDI interface and is connected to the physical keyboards, control surfaces and/or sequencers, and it forwards MIDI events to the GUI for tracking. This option kills that feature. When it's disabled, the GUI will not reflect the piano keyboard state, nor will it track CC motion — unless the '-gmc' option is given to open a MIDI connection in the GUI, and the user connects the same control surfaces to the GUI through this alternative channel. This option is logically identical to -localforward -remoteforward. 🎛️
  • -localforward — this prevents the GUI from forwarding MIDI messages to the engine. It's not about preventing MIDI message loops, because forwarding only ever occurs from MIDI interfaces to TCP connections between GUI and engine. This option just stops messages from any surfaces that are connected to the GUI from forwarding on to the engine.
  • -remoteforward — this prevents the engine from forwarding to the GUI, but still allows the GUI to forward to the engine. If the GUI is given a MIDI connection with the -gmc option, and control surfaces are applied to both processes, then the -forward option should be used to globally prevent event redistribution. Not doing so won't cause loops — just one-for-one duplication of events. It is possible to connect the control surfaces just to the GUI when -gmc is used, which opens up the possibility of having a local keyboard and GUI while driving an engine on a remote system. There's admittedly additional latency involved with handling the MIDI messages from the GUI to the remote engine over TCP. 🐢
  • -oss — configures OSS defaults for audio and MIDI interfaces.
  • -alsa — configures ALSA defaults for audio and MIDI interfaces. The MIDI interface is an ALSA SEQ port.
  • -jack — configures Jack defaults for audio and MIDI interfaces. At the time of writing this option causes some issues, since it selects Jack MIDI, which currently requires a bridging daemon to operate. The options '-jack -midi seq' would be a more typical configuration. ⚠️
  • -jackstats — do not request audio parameters from the jack server; take the bristol system defaults or the configured parameters instead. The bristol defaults will invariably fail, however the call to bristoljackstats is sometimes superfluous and this can speed up the initial startup times. Using this parameter will typically require that the options -rate and -count are also provided.
  • -jsmuuid <UUID> — this is for sole use of the Jack Session Manager.
  • -jsmfile <path> — this is for sole use of the Jack Session Manager.
  • -jsmd <ms> — Jack session manager delay before session events are distributed internally. Event execution is delayed in the GUI by a default of 5000ms.
  • -session — disables all session management, including JSM and LADI.
  • -sleep <n> — stalls the initialisation process for 'n' seconds. This is to work around what appears to be a race condition when using a session manager to initialise multiple bristol clients, since they all end up vying for the same TCP port identifier. 😴
  • -jdo — Jack Dual Open: lets the audio and MIDI threads register as independent clients with Jack. Per default the audio thread opens as a jack client, and the MIDI connection is piggybacked as another port rather than as another client. 👯
  • -o <filename> — generates a raw audio output of the final stage samples to a file. The format will be 16bit stereo interleaved.
  • -nrp — enables support for NRP events in both GUI and engine. Use this with care, because NRP in the engine can have unexpected results. 😬
  • -enrp — enables NRP support in the engine only.
  • -gnrp — enables NRP events in the GUI. This is required to allow the GUI (and therefore the engine) to be driven from some MIDI control surfaces.
  • -nrpcc <n> — maximum number of NRP to map. The default is 128, which is seen as sufficient for any of the current emulators — but the mixer will require more if it is ever released. 👑

🎧 Audio driver 💖

  • -audio [oss|alsa|jack] — audio driver overrides. Depending on the order of the switches, it's possible to set a group of global defaults (-jack/-oss/-alsa) and then have specific re-selection of components. 🔀
  • -audiodev <dev> — audio device name. For Jack, this will be the name registered with the Jack daemon.
  • -count <samples> — number of samples/frames in the processing period.
  • -outgain <gn> — output signal normalisation level, per emulator default 4.
  • -ingain <gn> — input signal normalisation level, per emulator default 4.
  • -preload <periods> — number of audio buffers to prewrite to the audio output on start. This is not active with the Jack drivers.
  • -rate <hz> — the sampling rate, bestie. Defaults to 44100.
  • -priority <p> — the realtime priority the engine audio thread asks for, default 75. Set it to zero and RT processing is fully disabled.
  • -autoconn — automatically connects the engine input and output to the first Jack IO ports it finds. You can also pull this off with the environment variable BRISTOL_AUTOCONN=true.
  • -multi <c> — multiple IO port requests. Only works with Jack, and rn only the ARP 2600 actually gives you access to these ports.
  • -migc <f> — input signal normalisation level for the multi IO ports.
  • -mogc <f> — output signal normalisation level for the multi IO ports.

🎹 Midi driver 🎹

  • -midi [oss|[raw]alsa|jack] — audio driver overrides. Depending on the order of the switches you can set a group of global defaults (-jack/-oss/-alsa) and then re-select specific components, like in -jack -midi seq. The default MIDI driver is -midi seq, but that can be overriden with compile time options such as --enable-jack-default-midi to ./configure.
  • -mididev <dev> — MIDI device namee to be opened (OSS/ALSA).
  • -mididbg — request MIDI level 1 debuging.
  • -mididbg2 — request MIDI level 2 debuging. You can select both for level 3, iconic.
  • -sysid <0xXXXXXXXX> — configure an alternative SYSEX identifier for the engine. The default is the value 0x534C6162 for historical reasons. Heads up bestie: this is not a free development ID, but it is not assigned either, so it should not cause conflict.

🧚 LADI driver (level 1 compliant) 🧚

  • -ladi brighton — execute LADI messages in the GUI only.
  • -ladi bristol — execute LADI messages in the engine only.
  • -ladi <memory> — the LADI state memory for save operations. This should be unique for each LADI session.

✨ EXAMPLES ✨

okay bestie, this is the part where it all clicks, watch:

startBristol -mini

Run a minimoog using ALSA interface for audio and midi (seq). The emulator will default to monophonic, high note precedence with retrigger and legato velocity. chef's kiss

startBristol -alsa

Run a hammondB3 using ALSA interface for audio and midi. This is equivalent to all the following options: -b3 -audio alsa -audiodev plughw:0,0 -midi seq -mididev plughw:0 -count 256 -preload 4 -port 5028 -voices 32 -channel 1 -rate 44100

startBristol -explorer -voices 1

Run a moog explorer as a monophonic instrument, using ALSA interface for audio and midi.

startBristol -prophet -alsa -channel 3

Run a prophet-5 using ALSA for audio and midi (on channel 3).

startBristol -b3 -count 512 -preload 2

Run a hammond b3 with a 512 samples in a period, and preload two such buffers before going active. Some Live! cards need this larger buffer size with ALSA drivers.

startBristol -oss -audiodev /dev/dsp1 -vox -voices 8

Run a vox continental using OSS device 1, and default midi device /dev/midi0. Operate with just 8 voices out of the 32 available.

startBristol -b3 -audio alsa -audiodev plughw:0,0 -seq -mididev 128.0

Run a B3 emulation over the ALSA PCM plug interface, using the ALSA sequencer over client 128, port 0.

startBristol -juno &

(yes bestie, just the one line, she's off in the background being mysterious 💅)

startBristol -prophet -channel 2 -engine

Start two synthesisers, a juno and a prophet. Both synthesisers will will be executed on one engine (multitimbral) with 32 voices between them. The juno will be on default midi channel (1), and the prophet on channel 2. Output over the same default ALSA audio device. The 32 voices will never all get used as these emulators will run per default with a lower soft limit. They can be run with more voices however that would require suitable values to the -voices option.

startBristol -juno -jack -register juno -voices 32 &
startBristol -prophet -jack -register prophet -channel 2 -voices 32

Start two synthesisers, a juno and a prophet5. Each synth is totally independent with its own GUI and own engine. Each engine will register separately with the jack daemon. They will respectively register the names 'juno' and 'prophet' with Jack and ALSA so that they can be differentiated in the respective control programmes such as aconnect and qjackctl. The outputs will be visible separately in these control programs and can thus be routed independently. Each synth can use up to 32 voices and there will only be CPU contention - these are separate engine process with 32 voices each.

🌸 FILES 🌸

The bristolrc file can be created in the BRISTOL_CACHE directory (default value ${HOME}/.bristol/bristolrc) and the users prefered options placed as the content. The file will be read as a single line and incorporated onto the command lines for both bristol and brighton. There is an additional variable BRISTOL_RC which can point to another location if necessary. This can be used to simply the command line for all parameters that a user provides with each invocation. The parameters can be all on a single line of the file or one per line. The parameters from this file will preceed the user specified ones such that the RC defaults may be overridden on the comand line.

tl;dr: your fave flags can live in a file so you don't have to type them every single time. set it and forget it, periodt.

🦋 ENVIRONMENT VARIABLES 🦋

  • BRISTOL — this indicates the location of the bristol installation for the binaries, bitmaps and related data reside. The default depends on the prefix used for the system build, /usr/local/share/bristol and /usr/share/bristol are typical.
  • BRISTOL_CACHE — the cache is where memories and emulator profiles (keyboard maps and MIDI Continuous Controller maps) are saved. The default is ${HOME}/.bristol
  • BRISTOL_RC — location of the bristol runcom file.
  • BRISTOL_LOG_CONSOLE — force debuging output to be sent to console without timestamping, log file or syslog.
  • BRISTOL_AUTOCONN — attempt to automatically connect the bristol audio inputs and outputs when using Jack.
  • BRISTOL_AUTO_LEFT — if BRISTOL_AUTOCON is set to anything other than '0' this will be the default Jack port for the bristol left channel output. There is no default, if AUTOCONN has been requested this will be the first jack playback channel.
  • BRISTOL_AUTO_RIGHT — if BRISTOL_AUTOCON is set to anything other than '0' this will be the default Jack port for the bristol right channel output. There is no default, if AUTOCONN has been requested this will be the second jack playback channel.
  • BRISTOL_AUTO_IN — if BRISTOL_AUTOCON is set to anything other than '0' this will be the default Jack port for the bristol (mono) input channel. There is no default, if AUTOCONN is set this will be the first jack capture channel.

👑 AUTHOR 👑

Written by Nicholas Copeland <nickycopeland@hotmail.com> — an absolute legend, no cap 🫶

🐛 REPORTING BUGS 🐛

Bugs and enhancement requests can be submitted to the bristol project page on SourceForge:

<http://sourceforge.net/tracker/?group_id=157415>

found a bug? don't be shy bestie, go tell the tracker. she wants to know 💜

Copyright © 1996,2011 Nick Copeland. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

NO WARRANTY, bestie — read that twice. she's free and open, but she's not gonna hold your hand if something explodes 💀

and that's the whole page, bestie!! 🎀 this edition dropped Oct 29, 2011, and the page is BRISTOL(1) — go make some iconic noise, you've got this 🦋✨

📦 where this page comes from