PhaseMod

BlueStar is a phase modulation synthesiser with two 6-operator instruments, like Yamaha's DX5. It is easy to use when creating new sounds, and is also a MIDI System Exclusive patch editor aimed at fast transcription from old paper records. It is fully compatible with the Yamaha DX7.

It works with Yamaha's DX7, TX7, DX5, DX1, TF1 (TX816 module), DX7 II S, D and FD, TX802, and FS1R. It works with Native Instruments FM7 and anything else that uses standard DX7 MIDI SysEx data. Its data can be converted for the Yamaha SY77, SY99 and TG77 if you have a way to do it.

This program needs audio and MIDI hardware with good driver support. It also needs a CPU with SSE instructions, but there is no need for anything more exotic. It runs on all 32 bit Windows, and probably on WINE in Linux. It has been tested and seen working well on 64-bit Windows 10.

Unzip BlueStar.exe (and the DLL file) to wherever you want it, and run it. If it is missing some other needed file, it will make one with default data. More than one copy of BlueStar can be run at the same time if each has its own base directory and data files.

This HTML page is the manual. After using BlueStar a few times, you'll need this manual only to help you understand why stuff was done. Read the long bits at the end when you're ready for them. You won't regret it.

Start with the defaults in the Config file that is created when the program first runs, 16-bit audio at 44.1 KHz, and 16-note polyphony for each of the two instruments. Use the program's Config panel to set audio and MIDI ports. Results will depend on the quality of the hardware and the driver code supplied for it. The efficiency of BlueStar is so high that on a 4-core 1.8 GHz 64-bit CPU you can set the highest polyphony, 64 for a total of 128, and still be using only about 20% of CPU time.

As with any audio software, latency reduction should be tried for the fastest clean response to your action. Clean output can be had with latency down to around 1 ms. If you're running a 64-bit OS and hear a few glitches in the audio, try running BlueStar with the program properties settings made for W98/WME compatibility. This will probably make them go away.

ASIO Driver Interface Technology by Steinberg Media Technologies GmbH.    (See the section "Performance notes" below, for how and why to use ASIO.)

With Steinberg's ASIO, excellent performance is possible with USB2 audio hardware. Specific devices were tested and found ideal: Focusrite 2i4, Steinberg UR22 MkII, M-Audio M-Track Quad, and M-Audio M-Track Duo (but you'll need to get MIDI connections some other way if you use that last one). The first two are so good that it's hard to recommend anything else at any price. Not many cheaper devices exist, and few of those have good ASIO drivers. The M-Track Quad is useful on Windows XP, its ASIO driver is fairly good, and it might be the only way to get USB audio at 96KHz and 24 bits, with MIDI built in, to a high standard on that operating system.

BlueStar is easy and fast, closely following the structure of the SysEx data while grouping things on pages for visual navigation. There are few buttons, but they do a lot. There is tooltip and status bar help for each of these, so after a few minutes of use you'll know what everything does. There are keyboard shortcuts for most operations, to help people who like speed in repeated tasks.

A parameter has a variable control, selected by clicking its buttons or its display, or by keyboard shortcuts. Its value is changed by using its buttons, the up/down arrow keys, a scroll wheel, or by double-clicking text for keyboard entry followed by the Tab or Enter key. Unlike the standard Windows controls which they resemble, BlueStar's controls can be adjusted by clicking and holding in the edit field or the buttons, and sweeping the mouse forward or backward. This isn't 'paint by poking numbers', it's like flying. It's luxurious, like the controls found in high quality workstation software. You can aim for a number on a scale of 100 as easily as you can glance at a spot on the wall.

When a parameter is selected, the Tab key will move to the next control in a loop that follows the order of parameters in a DX7 SysEx patch, moving to a new control page if it needs to. It will also select the text. Press the ESC key if you want to cancel an edit in mid-entry. To initialise a single parameter, double-click either of its buttons. Entering '*' or '-' will set the value to the upper or lower extreme of its range. Additional keyboard shortcuts are described on the inbuilt help pages, and are especially useful if you prefer keyboard access for speed instead of a using a mouse. These methods allow very fast data entry.

Some controls convert numbers to a more complex form as the DX7 does. For those controls, a direct text entry must be its numeric value. It is not always obvious what that is, but a bit of trial and error is harmless. This is useful when entering scaling break points from a paper data sheet, for example... Remember that text entry must be followed by pressing either the Enter or Tab key. All other data entry methods directly update the stored value. Note! The Oscillator Tuning display is different, compounded from three controls, Tuning Mode, Tuning Coarse, and Tuning Fine, and although the Tuning Mode control is fully accessible, the other two are only reached through buttons or Tab order, the display between them is read-only. In a selected control, including the hidden tuning inputs, Ctrl+A will select all content to allow clean text entry.

Another way to help with paper data sheets is to re-arrange the envelope generator controls.

DX7 envelopes can be arranged in two ways. One is to think of temporal progression of each rate to its associated level. This is useful when thinking about how they work, and is ideal for making sounds, but it's not the only way. Patch sheets usually follow the SysEx data structure, putting rates together, then levels. This is awkward for programming from scratch, but ideal when entering existing data by hand, so you can choose which way you need to see them. Another quirk, not adequately covered in any texts, is that rates are not times. It takes less time for a fixed rate to go between closer levels. If levels are equal, the rate is often left at the default of 99, but that causes audible glitches in older instruments. To remove them, set the intervening rate to 72 instead of 99. This cleans the sound up a lot on slow envelopes. BlueStar does not have this problem, but it is wise to set rates between equal levels to 72 for best compatibility with original Yamaha hardware.

It's easier to load existing data than to edit from scratch. The toolbar's Load button will do this for a single patch file, but holding Shift while clicking it, or double-clicking it, opens the bank's Load panel. A single click, or pressing Esc, will go back to the editor, but repeating the last action will open a file dialog to find a bank file. If you select a patch file instead, it will tell you, but not load it. Both files have the extension '.syx' but a DX7 bank file has 4104 bytes, and a single patch file has 163 bytes. BlueStar has several ways to be sure it gets the right file type, and that the data is valid.

BlueStar protects other files as well as its own. When saving, a file must be absent, empty, or the right format. Overwriting inappropriate files will be denied. This prevents very nasty accidents!

Yamaha 6-operator DX patches or banks in other programs, saved as files with extension '.syx', will probably work with BlueStar. If not, transfer their data by MIDI as described later.

Each '.syx' file is saved with a second file with extension '.xdx', meaning Extended DX. This data is what Yamaha called 'Performance data', and the DX7 only had one store for all patches, and a TX7 was needed to store them for individual patches. It was NOT convenient, but it worked. The Controls page in BlueStar holds these parameters. The DX7 standard patch and bank does not hold these settings, nor was there ever a standard method to hold all the settings in one SysEx message! The XDX files are BlueStar's method of solving this problem.

Each of the two editors in BlueStar is intended to control half of a stereo instrument, but two mono instruments can be used. Each half can be independently panned. Each has its own bank, patch selection, and edit state. Each editor is protected. Yamaha default to protecting bank data when starting, and BlueStar is the same. To change data in a bank, the 'Protect' setting on the Controls page must be switched off. The original DX7 cartridge 1, bank A, is shown here. Instrument 2 could hold bank B, but that's best for stereo sounds, one bank for each audio channel.

The 'Bass 1' patch is very good (and famous). Clicking on it selects it, and the patch number LED's light up. If MIDI is set up on the Config panel, it can be played. Clicking Load or pressing Esc will restore the existing edit state. To copy the bass patch to the editor, press the Enter key, or double-click the patch selection area. The Edit button will be disabled, but the first edit will enable it again for Compare mode, and an 'E' appears on the first digit of the instrument LED's. Clicking the Edit button or pressing Ctrl+E will switch to Compare mode, indicated by a 'C'. This makes it easy to listen for changes caused by multiple edits at once. Repeat the action to go back to Edit mode.

If enough edits are done, comparisons may be needed between the current state and some new minor edits. In this case, open the bank's Load panel and close it. The existing edit will be copied for Compare mode. New edits can be compared with it. To compare with another patch, select it on the bank's Load panel with a single click, then return to the existing edit. The DX7 would allow this trick, but only by using the Recall buffer after loading a saved patch.

The first edit blanks the patch number LED because the data is not the same as the original. Even if it becomes so, the link is broken. The patch number indicates that the data IS the same, and has not been touched, by you, by MIDI, or anything else. If the bank itself has been changed by storing a patch, a small LED to the right of the patch number will stay lit until the bank is saved manually to an external file. The bank is saved as local data, but the LED warns that backup is wise, and you won't be able to load another bank file until you do, unless bypassing a prompt, and MIDI reception of a bank will not be possible at all until the current bank has been saved.

The 'Ref's Whistle' was particularly feeble... Best replace it with a bass! This lights that bank edit LED and shows the change in patch 29, but the selection of patch 15 remains to show you the origin. Single clicks on the Save panel will audition patches as on the Load panel, but double-clicking commits to saving data. There is no 'Undo' here! This is why backup is wise. It always is! The different colours help to warn that this is where dangerous work may be done. Editing the Config file can change the colours, but they exist for good reason. Back it up, then explore at will.

The Save panel, unlike the Load panel, does not modify Compare mode data. Complex edit sessions may need multiple saved patch variants for tests. All Save methods protect the editor, and they all preserve the current patch number for the selected instrument..

One last detail on Bank mode panels... Selecting patches may be done without clicking. Arrow keys will scan rows or columns, or scan the entire bank if Ctrl is held while using the Left/Right arrow keys. MIDI Program Change messages will also select patches, but only the lowest five bits of the number are used. Rather than use larger banks, it is easier to manage patches in different instruments, or load new banks. This is another good reason to get into the habit of saving them.

Changes to the config are always saved, so what you see is what you get, there is no 'save' or 'cancel' here. Close the Config panel (or any panel) by pressing Esc, clicking its toolbar button, or clicking the Close (X) button at top right on the title bar, or by using Alt+F4.

Each setting is explained by text in its own control, but a summary of purpose is as follows:

Bank panels group patches in rows or columns. Envelope pages group controls by stage or type. MIDI status is indicated by LED at the top right corner, MIDI monitor on the status bar, or both. Auto-send mode reduces delays by selecting how to send data according to hardware ability. MIDI Src and Dst are source and destination ports. MIDI input channels are one of sixteen, also accepting all (as 00). SysEx channels direct data to instruments at the far end of a MIDI output connection. Data Entry sets the 'control change' number for MIDI editing. Wave destination is one pair of outputs, as defined by the system and any wave drivers installed. Wave stream allows latency reduction, by selecting the length of each buffer (in samples) for a double-buffering relay of data to the audio driver. Set this as low as you can get it, without resulting in broken sound. Voice mode can be set for programming, where any edit must be heard immediately whenever possible, or for performance, where sound must be sustained while you change a control or call a new patch.

Some detail is explained elsewhere, but this section covers the purposes for all buttons. Most programs can't use double-clicks on tool buttons. This one can, for three standard buttons for New (Initialise), Load and Save, and also for the two with antenna symbols. The purpose of double-clicks, or single-clicks while holding the Shift button, is to act on a bank instead of a single patch.

If at any time a button is useless or confusing, it is inactive to prevent harm to data.

New will load initialised patch data from 'INIT.syx' in the Data directory. BlueStar generates this file with Yamaha DX7 data, but you can make your own initialised data and save it in this file.

Load will import a patch file, or load a patch from the bank. If the Load panel is open, a second bank load call will open a new bank file after warning if the current bank has been changed.

Save exports the editor's data to a patch file, or saves it in the bank. If the Save panel is open, a second bank save action will save the bank to a file, and the bank edit LED, if lit, goes out.

Recall restores the last edit session. A DX7 saves to the recall buffer if you load a new patch. BlueStar allows editing of the new patch, recall is still possible if the new edit is not yet replaced.

Transmit sends a whole patch, or bank, on demand. Auto-send may be slow, especially if hardware can't use individual parameter SysEx. If Auto-send fails to work as expected, this won't.

Receive will request a patch or bank. Requested data always comes to the instrument that asks for it if it arrives promptly, even if the remote instrument is set to send it on a different channel.

Edit will indicate Edit mode when it becomes active, then it will alternate with Compare mode. Compare mode is always protected from direct input, and both modes are protected from MIDI.

Algorithm displays a selector of DX7 algorithms which define the routing of signals in the synthesizer core and have more effect on sound than anything else, so these small maps are useful.

Config opens a panel of program settings which are self-explained in its controls, but colours can be edited if you close the program and edit the 'BlueStar.cfg' file (carefully) in a text editor.

Help opens a reference system. It is minimal, with tables of vital information like control label meanings and details of keyboard actions aimed at fast editing or bypassing a broken mouse.

The toolbar row also holds the instrument selector. This is not a standard method for a toolbar, but it's a very good place to put it. At any time while the edit control deck is visible, this will select the current instrument for display or editing. It has three digits to allow for future plans, but the one to watch is the first. It is either blank, or will be an 'E' or a 'C' during an edit to indicate Edit or Compare mode.

There are six numbered Operator buttons arrayed on the left side of three of the editor's pages.

Each 'operator' in a DX7 is a sinewave oscillator with its own tuning, envelope generator, level scaling, etc. There are six, linked in ways much more complex than most earlier synthesizers which rarely went beyond something called 'cross modulation'. The DX7 starts with such complexity as a minimum for most sounds. Problems that big are best considered in modules. This is why BlueStar has no standard Undo/Redo controls. They make little sense if you need to mute whole structures or move and copy them between parts of one or more instruments!

The DX7 can mute operators so we can hear what's left and edit it without distraction. Mutes are reset when power is switched off and on again. BlueStar is the same, but is much more useful...

The DX7 is too complex for its own one-line editor to manage. A good editor makes it much easier to use if it does not make things appear more complex than they are already. Eye candy for envelope and level scaling display rarely helps more than ears and sounds and fingers. It actually maintains the illusion that DX7 editing is complex, instead of helping to simplify it. Clear, compact groups of controls help to guide thought better than graphs. As with a real musical instrument, BlueStar allows motor memory (muscles, nerves, etc) and good practise to make the most of them. The one exception is FM algorithm selection, because algorithms are hard to remember and because forcing changes of algorithm is a neat way to come up with new sounds.

A stack of operators in one algorithm will usually make the same sound in another but it will often use different numbered operators. Manoeuvring a stack that makes up one element of a sound, importing it to another algorithm that allows a better way to do other things, is extremely useful. A major obstacle in a DX7 was that it could not use its muting for accurate comparison, nor could it copy data between operators, which made the problem extremely awkward to solve.

BlueStar was specifically designed to solve this problem. These are the ways to do it:

Double-click the operator button to toggle the mute state. A DX7 mutes in Edit mode, not Compare mode. BlueStar does both. Different mutings can be set in each mode.

Left-click the operator button to copy the operator's data. The copy is available while the text persists on the status bar. It survives a change between Edit and Compare, or between instruments.

Right-click moves copied data for the current page to the selected operator, or all three pages if Shift is held. Copies can move from Compare mode but not to it. Compare mode can't be edited.

If an operator is muted while receiving new data, it will automatically be unmuted on the basis that it is important to hear what changed. When replacing Compare mode data with the existing edit (by open/close of the bank Load panel), its mute state will also be copied. If a patch had been selected for the replacement, the Compare mutes will be cancelled because the patch has no mutes.

BlueStar doesn't only protect files, it protects an editor from MIDI. SysEx bulk data never changes an edit session unless it arrives without delay after a direct MIDI request for it. SysEx data normally arrives at the instrument whose number matches the data's SysEx channel, but an answer to a request comes to the instrument that asked for it unless it arrives too late to be redirected.

Standard MIDI data messages are relayed from input to output to allow musical control. Some of these can be intercepted to edit specific parameters under direct user control.

A way to mimic the DX7 data entry slider is to click on a control with one hand, then use the arrow keys with the other, but a real data entry slider, or any MIDI controller from 0 to 95 (set by Config panel), can edit any selected control. If its parameter specifies a note value, it can take direct input from a MIDI keyboard. Hold the Ctrl key while playing the note you want it to use.

Some DX7-compatible instruments may not use single parameter messages. BlueStar sends all specific control data as individual 7-byte SysEx messages if Auto-send mode is set to 'Fast', but 'Slow' mode sends only a standard DX7 patch, and no performance control data (the parameters on the 'Controls' page). When set to 'None', auto send is off, and a standard patch is sent only when asked by the toolbar's 'Send' button. (In 'Fast' mode, the 'Send' button sends extended performance control data as single parameter messages, but the patch data is sent as a bulk message to save time.)

Two BlueStar programs can even control each other. This looks cool, if a tad pointless on the same machine, but as BlueStar is ideally hosted on a dedicated machine, it really does help because it may be linked only by MIDI, like any dedicated hardware synthesiser. The bank's Protect switch will work for a remote instrument on the selected MIDI output channel.

When an instrument is not in Edit mode it will take any MIDI SysEx messages addressed to it by MIDI channel, as expected of any instrument capable of remote configuration by patch data. This is one way to overcome bank size limits for those who insist on large sources of patch data.

The status bar can display a MIDI monitor, enabled by Config. This may hide other status text but the monitor takes precedence on the assumption that if you want to see it, you probably need it. It shows standard MIDI messages and 7-byte SysEx data. What you make of it depends on how well you know MIDI. This is a diagnostic tool for raw data, best switched off if your greatest need is low CPU usage and clear sighting of ordinary status messages.

Muting sends a message that a Yamaha DX synthesiser should understand if it is enabled for System Exclusive reception. It will do this even if Auto-send has disabled parameter messages.

ASIO allows much lower latency (delay) between input and output than with most Wave API systems. It's vital for good musical performance. The sound is much less likely to glitch with ASIO. To enable ASIO output, you need to edit the config file manually. Once it's set, you'll probably want to leave it that way, so adding a control interface for it is unnecessary. Set "Use_ASIO=1", save the file, then run BlueStar. If there is more than one ASIO driver available it will find and use the first one, so if you know there's another, close BlueStar, and raise whatever number you see "Use_ASIO" set to, by 1, and retry. In practise this apparently fiddly arrangement is as easy as it gets, because if you use various ASIO-driven hardware, but only one at a time in any system, BlueStar will find it. Just make sure the hardware is connected and ready before running BlueStar, because if it finds no ASIO-based hardware it will revert to standard Wave API output until you can restore ASIO capability in your system and reset the config to use it. The same applies to the ASIOport.dll file. There is no ASIO code in BlueStar! It's all in that DLL so don't lose it...

Audio port selection and ASIO driver identification are easy, as the image above shows. The config panel will tell you if ASIO is being used, even though it won't let you enable or disable ASIO.

Even without ASIO, some PCI-based hardware with a WDM driver (on Windows XP or later), will get glitch-free performance with latency down to 1 millisecond. This was found to be true using WXP running on a 1.2 GHz Mini-ITX machine with the original 20-bit Echo Layla PCI-based hardware, using its WDM driver and the 'PureWave' driver setting enabled. This performance uses standard Wave Out API calls, and is better than DirectSound, and anything that uses 'DirectKS' kernel streaming may work well too, but ASIO can get extremely low latency and is much more widely used. Do not rely on "ASIO4ALL" or other methods that claim to get good results by emulation. Go with good hardware, good drivers, because the foundation must be solid. If you get that right, the system will do the right thing when using ASIO, or even standard API calls on a PCI-based system, because that's its job. You just need to stay with hardware that does it well. If you do this, BlueStar will work as well as any hardware synthesiser, and at a much lower cost!

If you want to run it on W98 SE, that will work too, but it may restrict hardware and driver quality unless you can use ASIO. Even so, you might get clean action with latency as low as 40ms with WaveOut through a VXD driver, which is acceptable for many sounds, especially those with long attacks, and you can reduce the sample rate by directly editing the config file, to maximise polyphony for an older and slower machine. Just make sure it has SSE instructions, and it will work. If you can tweak the system for dedicated audio and MIDI purposes, W98 SE may get clean latency as low as 24ms if the hardware drivers are good. W98 SE is a very good choice of OS if you have good audio hardware with a PCI connector and a good ASIO driver. This was how professional studios used to do it. It's worth it if you can get hardware for a few tens of pounds that used to cost a grand.

BlueStar is designed to emulate hardware oscillators which are free-running for as long as they have power, which is critical for correct sound when gating closely detuned oscillators, especially in monophonic mode with key sync switched off. There will be a steady load on the CPU, whether all notes are played, or none, even in monophonic mode. This may sound stupid, but Yamaha's envelope methods can end with output set high, in which case modulations, phase accumulator stepping, all have to happen. Trying to 'save' CPU time by careful decisions about EG staging and operator output based on highly dynamic events led to code that cost nearly as much time as the code it prevented from running, and some patches use methods that are compromised by those decisions. At worst case, the CPU demand is even higher than it would otherwise be. It's better to keep it simple, and keep it steady. This is ideal because if it sounds good, you can play as many notes as it is set to use, as hard as you want, and know it will give you what you ask for. If performance is critical, run it on a dedicated machine that has no other demands, especially any that vary enough to cause glitching.

The config file can be edited directly while the program is shut down, to alter the 'NotePoly' setting, changing the polyphony to as many notes as the computer can handle, or as few as you need to save a lot of CPU time if you know you're only going to use a monophonic sound, or one like a flute that may work best with just two or three voices in use, enough to avoid problems with the overlap timing between notes. Both instruments will have the same setting, because it's designed to work with stereo sounds. You can also enable 24-bit audio by setting 'Audio_24' to 1, which gives a huge improvement in the quality of long fading sounds, even with very high polyphony, because the dynamic range will be 256 times greater than with 16 bit audio. The sample rate can be set by altering 'Sample/s', either for finest quality, or to reduce it to get higher polyphony for the same demand on CPU time. If you are using 'pad' sounds with huge chords and sustain with slow release rates, this is likely to help.

Another detail related to high polyphony and long fading sounds with sustain is the available dynamic range. A patch is set to a volume of 7 by default, and any value up to and including 7 is guaranteed to avoid clipping distortions, whatever sound and playing conditions are used. That includes setting unusually low or high numbers for polyphony in the config file (within reason, 128 or more per instrument is impossible to test on any computer anyone could easily buy). This can sometimes mean that the structure of a patch results in a very quiet sound, and the volume can be set to 8 or 9 in this case, each extra rise doubling the previous sound level. Take care when doing this, because clipping is possible, and only trial and error will find out if this will happen. The odds are that if a patch sounds too quiet with carrier output level controls as high as they can go without making the patch sound wrong, this adjustment will work. If in doubt, use the sustain pedal with strong key actions to see what happens if all the polyphony is used. Clipping will affect the entire output of the synthesiser, so if any patch has a volume greater than 7, this must be tested carefully. This adjustment beyond 7 is strictly intended to fix very quiet patches without loss of sonic detail. It should never be used to make things sound louder in general. Use external amplification to do that.

In a live performance, it may be critical that notes will start and end with whatever patch was set at the time they were played, even if you call a new patch or edit a control before releasing notes. Using a sustain pedal can leave both hands free to set patches or controls with no change in the sound till you start to play new notes. Changing the voice mode setting on the config panel will change between immediate and deferred response to changes of patch settings.

Data is saved and verified during every edit. Like Yamaha's hardware, the program will shut down and re-start with the current patch or edit state. This includes its on-screen location. If you want it re-centred after moving it, put its top left corner beyond the top left corner of the screen before closing it. It will be centred next time it's used.

If a control has focus, usually obvious by its text being visibly selected, any use of the toolbar will try to preserve this selection on return. The one exception is when loading data (or initialising it), or when changing the algorithm via the selection panel, or when requesting a patch by MIDI, or receiving one. All these moves almost certainly make the previous selection meaningless in the new context, so they don't allow return to it. Bank operations, either by MIDI or by bank file load, will allow a return, because these moves will not change the internal patch data, whether in edit mode or not. This control focus detail was carefully arranged, because it helps to focus the mind during any move that is not directly related to the edit.

Anyone familiar with a DX7's edit, init and recall buffers for copy and compare techniques will find those working as expected here, with extensions to mute, compare and copy sub-structures between different instruments, patches and algorithms. BlueStar can copy operator data from the compare buffer too, and select a different patch to compare with the current edit. Double-clicking any parameter control will restore it to its initialised value, and the INIT data file can be overwritten with your own choices for default values for initialising any or all parameters at will. These details make it extremely easy and powerful to do complex editing based on your own starting conditions, and to manage the detail needed to make good stereo patches.

BlueStar is accurate wherever possible, but exact emulation of the DX7 or DX5 is impossible without precise copying of every data type and instruction in the instrument, so exact copies of the ROM, OPS, EGS and DAC IC's would be needed.

The original had plenty of flaws that are not desirable, like strong levels of HF noise from digital artifacts, mainly because of the low bit depths. The DX7 can sound very bright because its sample rate is higher than standard digital systems, at 49096 Hz, but the resolution is only 12 bits. Many more flaws exist, like discontinuities in the look-up tables and scaling that creates rising envelope curves, and LFO speeds and modulation onset delays, and audible glitches when moving from one EG stage to the next. BlueStar does these things more gracefully because a 32-bit system allows the precision needed to calculate them very accurately.

The pitch EG is especially weird, and the strangest thing of all is some very low-level random behaviour that affects long slow rates between very close low levels. The Yamaha patch called "WATER GDN " on ROM cartridge 4B is an example of this. It's one of the very few patches that will show any real weakness in BlueStar, but it's a very marginal case, few sounds ever used that technique, and the majority will sound identical to the original hardware, unless you do a strict 'ABX' comparison, i.e. a 'blind' test where the aim is to prove you can hear a meaningful difference when you don't know which source you're hearing. Most development was done with a Yamaha TX7 tone generator feeding one stereo channel, and BlueStar feeding the other, controlled by the same MIDI signals, so that any aberration was explored and reduced whenever possible. Swapping the audio between each side of a pair of Sennheiser HD-25 headphones makes sure that illusions are quickly cured, especially when the tests are tiring!

One quirk of the original hardware is that with envelopes appearing to offer 100 different levels, there are usually identical results between two sequential values, so only 50 effective levels exist. In BlueStar, there really are a full 100 distinct levels. This matters because with sounds that use a very high modulation index, it is easier to detect differences between BlueStar and original hardware, for a specific level. Having a real shift in level, to about twice the resolution offered by original hardware, over the same range, you can fine-tune level settings in rare cases where the sonic precision isn't perfect.

A more noticeable flaw in the original hardware is the behaviour of closely detuned operators, where the detuning can suddenly collapse to nothing! It just stops happening at some point on the keyboard scale, and it's very annoying. BlueStar has four times the tuning resolution of the original hardware, mostly so things like this can be prevented, and while settings are carefully arranged to get very close to the character of the original for any given detuning value, the result is likely to play better, by far. One particularly egregious flaw in the original hardware is the failure of full-depth squarewave pitch modulation to reach a full octave up and down! You won't be hearing any of that nonsense from BlueStar...

Similar care was taken with the exponential level scaling, where high modulation indexes really showed up flaws in the original. This matters in sounds like pianos and clavichords, and it matters in principle because the DX7 was intended as a dramatic step toward better emulation of real musical qualities. Despite all its flaws, it's a masterpiece of programming. Its use of nonlinear curves based on its inbuilt conversion of logarithms to linear output, allows emulations of analog electronic behaviour as well as physical systems like strings and pipes. It's how the DX7 was so good at these sounds. It affects all aspects of the engine, LFO's, envelopes, scaling, tuning, it's fundamental to how and why the DX7 did it better than the rest, and influenced everything that came afterwards.

Another detail in BlueStar that improves on most MIDI instruments, not just the DX7, is an internal interpolator that prevents 'zipper noise' and other glitches in pitch bends and EG bias control by MIDI. The result is as smooth as a clean analog potentiometer, but there is no restriction on speed of response, unlike many systems, even Yamaha's own, as those with an SY77 or SY99 may be aware. Unlike systems based on a desire to replace MIDI, BlueStar was designed to make the best of it. A good master keyboard will let you know the difference. You can play with BlueStar, and it is free, so why not? It's the fastest way to understand that it is also a tool that a musician can depend on when they need to earn a living using it.

Like the original hardware, BlueStar does not use any floating point arithmetic. It does not need to, because fixed point arithmetic methods are more than accurate enough when you have up to 32 bits available! This also means that so long as the CPU has SSE instructions available, the program will always work, and on a slower or older machine, it will almost certainly work faster than one that uses 64-bit integers on a 32-bit CPU, or uses floating point. BlueStar will probably allow a lot more polyphony than 16 notes for each of its two instruments, even on older machines.

This a degree of detail that goes far beyond merely 'persnickety', but some people care about this stuff, even though many others will never notice! While it is said that there is no point trying to please all people, all of the time, BlueStar, unlike many other instruments, honoured Yamaha's original intent and action. Like the DX7, it was researched and built during more than TEN YEARS before making it available, so it might please anyone who ever learned enough of the DX7 to respect its methods, in sound creation, and in its use of edit, recall and init buffers as an editing system. There will probably never be an update now that the internal control system has been entirely overhauled, and ASIO has been added for best performance, but the amount of care taken was to make it unlikely there will ever need to be one. Its version number is based on the matching DX7-Edit program that led to BlueStar's development. (See the extra files at the end, if you want that one).

The standard DX7 patch is a form of sonic currency that will never be eliminated now, any more than MIDI itself, no matter how many idiots write new obituaries! It was worth taking ten years to support something like that. Yamaha thought so. Martin Russ thought so, when he wrote the best articles on audio synthesis and MIDI that I have ever seen, in Sound On Sound magazine during the late 1980's and early 1990's, and I hope many other people do.

I am working on a much larger scale of synthesiser, a true hybrid of phase modulation, wavetable synthesis, and analog simulation, with over 700 parameters per patch, that remains compatible with the standard DX7 patch as well as extending to several techniques I have never seen done anywhere, and some very old ones, like the extremely versatile LFO's, the likes of which mostly vanished with the giant Roland A100 analog modular synthesiser, and a modulation system that makes the Native Instruments FM7 look less than half-baked. This beast may never be ready to release, but it is possible that if I discover that BlueStar makes its way in the world without me having to push, I may be motivated to finish the task. It's a lot more complete than I make it sound, but Covid, and some other unpleasant changes in the world, have caused me to lose the time and opportunity for an early finish. Right now, the project hasn't even got a name because I just decided to use its name for this one! :)

These are editors with no synthesis engine. DX7-EDIT is smaller, and has no SSE requirement, so will run on very old machines with low power demands, which may be useful to edit banks of hardware and act as a centralised editor and library system. The third file is a set of original Yamaha data for the DX7. This is important for testing any synthesiser which emulates original hardware. DX7-Edit also uses the old colour scheme, instead of the new one used for BlueStar. Comparing their config files will give you a head start if you want to explore making your own colour scheme...

There are no more words. Unless you really don't understand, in which case you need this.