• Visual Editing Systems
  • Visual Editing Systems
  • Visual Editing Systems
  • Visual Editing Systems

Magazine Archive

Home -> Magazines -> Issues -> Articles in this issue -> View

Visual Editing Systems

Most editing software is more user-friendly than digital parameter access, and more suited to the demands of editing complex digital synthesizers than traditional analogue controls. Greg Truckell investigates.

The use of personal computers in music has made possible the proliferation of editing software that is both more user-friendly than digital parameter access, and more suited to the demands of editing complex digital synthesizers than traditional analogue controls. Greg Truckell looks at the joys and pains of the world of Visual Editing Systems.

Let's face it: for all but the slightest tweak of a filter, envelope or modulator, the front panel of an average piece of modern audio equipment is about as much use as a chocolate fireplace. So, in these days of digital parameter access, how do you programme your equipment? Most serious programmers use a computer-based visual editing system (VES) - an editor program if you prefer - to edit their synthesizers, samplers, digital multi-effects processors, and programmable audio and MIDI patchbays, and with good reason - without such help, the process of programming contemporary equipment can be painful indeed. Some credit is due to certain manufacturers for cottoning on to the fact that the average musician, programmer or engineer does not have a brain the size of a planet - consequently, the size of the display on your latest purchase is probably larger than that on a similar item that you bought last year. Nevertheless, three or four lines of abbreviated pidgin jargon and a bare handful of multifunction and increment/decrement buttons falls far short of what is required to fully exploit the potential of today's studio equipment. From the Mirage to the S1000, it still just ain't enough.

The solution to the problem of effectively controlling and accessing the hundreds of parameters that shape today's sounds is not a return to traditional knobs and switches. Call me conservative if you like, I just don't believe that all the Prophet 5 and MemoryMoog owners out there really do have the best of all things. There is now a generation of synthesizer programmers for whom digital parameter access is the accepted norm; they just don't know any different, and knobs won't really suit them or the equipment they're programming.

There was a time when two or three dozen knobs, faders and switches were used to control a synthesizer's sound, but contemporary instruments have too many parameters to make this old system of one parameter, one control, really practical. Furthermore, digital parameter access cuts down on the cost of equipment: the manufacture of any of today's major instruments with individual controls for each parameter would be prohibitively expensive. Consider how much the cost of a Roland D110 or Kawai K1R would increase if the front panel were to include a knob for every parameter. Then consider how much use these knobs might actually be when it comes down to providing a visual representation of the current sound. Unless you have some pretty intelligent knobs, either motorised or with integral displays, a knob, switch or slider tells you nothing about the value of its associated parameter until you adjust it - not much use for making comparisons between sounds. There is also the problem of how to represent a parameter such as Waveform on an old-style front panel: on many instruments this is a parameter with hundreds of possible values, so what sort of display or control would be suitable here? Nope; more knobs ain't the answer.


Let us therefore turn our attention to the possibilities of Visual Editing Systems - for the purposes of this article I shall only discuss using a VES with an instrument (eg. a synthesizer or a sampler), although much of what will be said applies equally well to other programmable studio hardware.

Visual Editing Systems are superior to knobs and switches in a number of respects, the most important of which is the amount of information that can be conveyed at any one time. Of course, simply having a screenful of numbers corresponding to the instrument's every parameter is not enough: the information has to be conveyed in such a manner as to better enable an overall picture of the sound to be gained. Parameter names must appear on the screen, of course. Parameters should be grouped in a logical manner that reflects the programming architecture of the instrument, to avoid the need to switch from page to page on a display the size of a box of matches, as you would when programming from a front panel. Also, if a parameter corresponds to the selection of a waveform from a choice of over 200, then the parameter 'value' should of course be displayed as the waveform name, not as a bank and number which tells you nothing about how it sounds.

The graphic display of information is another obvious area where a VES scores over knobs, and until you have seen or used these features, you simply don't know what you're missing. With a VES it is a simple matter to intuitively drag your envelopes into the right shapes without even worrying about what the numerical values of the actual rates and levels happen to be. The same principle applies to keyboard scaling.

Don't be tempted to dismiss this point of design as being rather obvious; it really is far more important than you might at first think. Envelopes shape a sound - in terms of pitch, amplitude or timbre - over time. Graphic editing allows you to deal directly with these shapes, rather than indirectly via systems of numerical values. An envelope's graphic display should follow the convention of showing time along the horizontal (X) axis, and pitch, amplitude, or the timbre modulator along the vertical (Y) axis.

The same principles apply where the graphic display of key scaling is featured. With the key number (pitch) along the X axis, and the parameter being modulated by key scaling along the Y axis, our intrepid programmer can see at a glance precisely how any element of his sound should be behaving at any position on the keyboard. With graphic envelope displays, the usual editing technique is to use the mouse to click on and 'grab' the point where an envelope stage reaches its final level (a 'breakpoint'), then to drag it to a different location - simultaneously changing both the time and level parameters. With graphic key scaling, click-and-drag editing is not the norm, but the graphic display will update itself as parameter values are altered, so the only difference is that you have to go to the trouble of finding the parameters on the screen.


What all of this means is that you can, to some extent, forget the programming conventions particular to the manufacturer of the instrument that you are editing, because the VES can employ familiar ways of displaying parameters. There is no need to bear in mind whether you are dealing with envelope times or rates, or whether a high value for 'T1' creates a percussive or gradual attack transient. Your entire rackful of expanders can be approached as if they all adopted the same programming architecture (and after all, if they use envelopes, then they do use the same programming architecture). Wouldn't it be wonderful to know that you could buy a new MIDI instrument and be able to programme it with confidence less than half an hour after you had finished hooting with laughter at the preset names? Be sure to collect your VES at the same time as your new instrument, and this dream will come true - or will it?

Some software developers seem to have missed the point when it comes to a VES's ease of use. I can think of a couple of instances where the VES employs almost as many screens as the instrument itself. Unfortunately, certain compromises have to be made in satisfying the requirements of: a) getting all the parameters on screen in order to achieve an overall picture of a sound; and b) displaying parameters graphically and clearly.

"Unless you have some pretty intelligent knobs, either motorised or with integral displays, a knob, switch or slider tells you nothing about the value of its associated parameter until you adjust it - not much use for making comparisons between sounds."

Figures 1. Dr.T's D110 Editor: four screens each cater for a Partial.

Figures 2. Dr.T's D110 Editor: the Copy/Swap screen allows quick and easy copying of data groups between Partials.

Many instruments have a programming architecture which is based on two, three or four basic building blocks: Casio CZ synths have two Lines, each containing a DCO, DCW and DCA with envelopes; Roland's LA synths use up to four Partials in a sound, each with a TVA, TVF, Pitch Envelope and LFO. When it is not possible to fit all the parameters for all blocks onto a single screen, as is most often the case, it makes sense to dedicate one screen to each block, and display the parameters as clearly as possible on the various screens. Provided that the VES allows for quick and easy copying of data groups from one block to another, the sacrifice shouldn't be too great. (See Figures 1 and 2.)

Figure 3. Dr.T's DX Heaven: a separate screen is used for graphic envelope editing. It is a simple task for the user to alter the time shown in the window, and to alter the percentage of the window which corresponds to note-on time (the broken vertical line represents note-off).

With some instruments, it may not be possible to split the programming architecture into blocks such as these. Ensoniq's ESQ has three oscillators, three DCAs, three LFOs, four envelopes, and a more or less open architecture whereby any source (envelope, LFO, or whatever) can modulate any destination. Since any envelope could be central to understanding any other block(s) - because of this modulation routing - it makes no sense to divide the display into a block of envelopes, another block of oscillators, and so on. There may well be as many best solutions to this problem as there are instruments with the problem, but one solution which seems to work in many cases is to have two separate screens - one for graphic editing, and another for numeric editing. In cases like the ESQ and DX7, this allows the VES to employ a screen in which all the parameter values are displayed alongside their parameter names, with enough space left over for a small graphic representation of the envelopes, while another screen contains larger and graphically editable envelopes (see Figure 3).


If guidelines such as the above are followed by the programmers of editing software, then picking up a new VES shouldn't be too problematic. There is, however, more to getting the best from your VES than simple elegance and clarity of design. Let's suppose that you buy a new instrument and a VES to go with it; you are already in uncharted territory if the instrument uses a programming architecture that you are unfamiliar with, be it LA, FM, PD or whatever. Wouldn't it be comforting to know that at least your VES will provide a familiar interface with the new instrument? Well this can be the case, but not always - brand loyalty ain't what it used to be. Some software brand names are stuck onto packages written by any of a number of different programmers, each of whom have different ideas about what makes a good VES. It therefore makes sense to ask for a demo of any piece of software you intend to purchase, even if you already own other packages marketed under the same name. Personally, I won't buy a MIDI instrument until I can buy a VES for it written by my favourite programmer, a certain Robert J. Melvin (aka The Caged Artist). If a programmer uses the same conventions with every synth, then the learning process involved in getting the best out of a new instrument will be much smoother.

Properly used, a good VES will enable the adventurous programmer to extract a good deal more out of his instrument than would the front panel alone. A more thorough understanding of scaling and enveloping is quickly developed, to the extent that drawing the envelopes for a new brass patch comes almost without thinking. Imitative synthesis techniques can be improved by comparing the envelopes of other synthesizer patches, or perhaps even by examining the amplitude envelopes from samples.


The graphic editing techniques described so far are extremely useful, but there's one possible type of display that I feel has been sadly neglected by programmers so far - one that gives a graphic depiction of how an envelope's shape is modulated, for example, by key scaling or velocity. It's all very well to show what an unmodulated envelope looks like, and to show the bias curves over a range of so many octaves, but what about showing how an envelope behaves over the full MIDI velocity range? Or how about showing how an envelope is modulated by MIDI note number? I have only come across features like this once before - on Steinberg's Mirage Soundworks, which allows you to select between soft, medium and hard keystrikes, and will show the envelope shape for each of these rather vague values.

Figure 4. Graphic envelope display of amplitude, time, and velocity.

This is a start, but what I would like to see requires a three dimensional display. As usual, the X axis shows time and the Y axis shows amplitude; the Z axis could be switched to show either velocity or note number. The display would resemble a simplified sample FFT display, like the familiar Fairlight 'sound mountain'. Figure 4 shows a possible example, where velocity is shown on the Z axis. Although as few as nine envelope shapes are shown here, it is clear that as velocity increases so do both the peak and sustain levels, and the attack time decreases. Just think: with such a display you might actually start to exploit the modulation potential of five-stage envelopes, and controlling velocity crossfading between oscillators would become a simple matter, rather than sheer guesswork. Of course, it would be too much to ask that every stage of every envelope on a three dimensional display should be receptive to click-and-drag editing, but as long as the display updates itself as the envelope and modulation parameters are altered, editing will still be made a much more comprehensible procedure.

The variable on the Z axis should be switchable between velocity and MIDI note number, and it should also be possible to view the velocity display at any chosen note number, and the note number display at any chosen velocity. It will be interesting to see which software house will be the first to implement this type of display.

"Three or four lines of abbreviated pidgin jargon and a bare handful of multifunction and increment/decrement buttons falls far short of what is required to fully exploit the potential of today's studio equipment."


Computers aren't generally regarded as being very good at actually creating in their own right, but careful use of the randomisation facilities on a VES can allow the user to generate original sounds that they might never have thought of otherwise. The key to success here is to use randomisation intelligently, not artificially, because only a small percentage of sounds generated by blind randomisation will be even usable. The software has no way of telling what sounds good or bad, so this is where you come in. In the bad old days of Hybrid Arts' DX Android, a randomisation procedure was just that - all the patch parameters were changed by a random amount, and if you didn't like the results, well, you could always try again. And again...

The contemporary randomiser, on the other hand, allows the creation and use of 'masks' which will protect parameters of your choice from the randomisation process. You can therefore ensure that parts of the sound that you like will remain unaffected. Consider the following example of how careful randomisation can be used creatively. You have already programmed an acoustic guitar sound of which you are particularly proud. However, in the context of a mix it doesn't stand out as the lively patch you had in mind. The usual approaches, tweaking the detuning and LFO settings, don't improve matters. With a sound like an acoustic guitar, the most critical elements (ie. those that give the sound its important guitar-like quality) will probably be the attack transient and the actual waveforms used, so these parameters should be excluded from any randomisation. Remember, analysis and synthesis go together.

Your guitar part is polyphonic, probably playing four to six notes at a time or so. Assuming that your instrument is multitimbral, and that you are working with a computer-based sequencer, the first step towards livening up the sound is to split the guitar part across three or four different sequencer tracks, and assign these tracks to separate MIDI channels. Now set up a randomisation mask to protect the attack transient and the waveform parameters, which will allow the other parameters (including decay time, sustain level, release time, LFO and other modulators) to be randomised (Figure 5).

Figure 5. Dr.T's Four-Op Deluxe: a previously saved randomisation mask has been loaded from disk, and modified to suit the task in hand.

Next, set a randomisation percentage that isn't too high - 15% to 25% is probably OK for starters. Any parameter which is a candidate for randomisation will be varied by up to the percentage value selected. Create a few randomised versions of your original, and keep those which sound best. Also, save the randomisation mask to disk if this is possible - it certainly should be. Now modify the randomisation mask such that some of the parameters governing the waveform (including such things as detuning, FM ratios, pulse width, key following, etc) are no longer protected, but reduce the randomisation percentage to 10% or so, and randomise all but the best of the previously generated patches. The three or four best results from your new collection of sounds should now be set to play on the MIDI channels of the tracks occupied by the split guitar track.

The overall effect, created by playing these second and third generation randomised patches across the split tracks, will be that of more depth and variety, and less of the predictable and electronic feel associated with synthesizers. Every note will be that little bit different - just like a real instrument. The use of several slightly different timbres playing individual lines rather than one instrument playing polyphonically brings to mind the idea of a return to traditional orchestral polyphony - and indeed the methods described work well with strings and brass sounds, without involving the composer in traditional approaches to orchestration. Remember to save the randomisation mask to disk - this will enable you to use the same methods in similar situations. Your best randomisation masks can become as valuable an asset as your sounds. Experiment with randomisation masks as a means of discovering which parameters are crucial to different sorts of sound.


It is already clear that a VES can be vital to getting the most out of your music gear, but are there more cost-effective alternatives to purchasing a VES from your favourite software house to accompany every new equipment purchase you make? Perhaps: the first of a new generation of generic editing programs are now becoming available, offering the promise of being able to edit any piece of equipment that has a MIDI socket on the back using the same piece of software. The few that I know of include the Hollis Research MIDIman, Dr.T's X-Or, Keynote's forthcoming Chameleon, and Hybrid Arts' GenEdit. So, with this much power and versatility in a single program, is it curtains for the single instrument VES family?

Of course not - and the creators of the generic editors would be the first to admit this. A little explanation is in order...

"Computers aren't generally regarded as being very good at actually creating in their own right, but careful use of randomisation facilities can allow the user to generate original sounds that they might never have thought of otherwise."

Imagine an ideal MIDI studio: the software sequencer is running happily, and everything is going well, except that the bass needs to be more resonant and the strings need less detuning. The bass and strings are, of course, coming from two different multitimbral rackmounted units, and nobody has ever actually tweaked them from the front panel. Somewhere in the computer, be it a desk accessory or within a multi-program environment, there is a generic editor waiting to be called on, and in the twinkling of a SysEx message, the necessary tweaks can be carried out. Wouldn't it be nice to think that musicians might actually do this: change a sound, in fine detail, just to suit a piece of music. (That's what used to happen.) The problems with generic editing systems, and the reasons why at present they may not be able to entirely replace single instrument editors, relate to how you turn them into editors for particular pieces of gear. MIDIman, GenEdit and Chameleon all allow the user to create their own editing screens, but this is not a procedure to be taken too lightly. 95% of users will spend ten minutes trying to unravel the process, give up, and telephone the suppliers. And this is where the crunch comes. Either the user gets a friendly and sympathetic ear - and a free disk containing the profile that they've just attempted to set up - or they are told that the whole point of the software is that it is user-definable, at which point they hang up and buy another manufacturer's single instrument VES. Let's just hope that there are no such horror stories waiting to be told.

The real problem for the generic systems is simply that they try to cover every possibility. They can edit all of the parameters on some of the synths, and some of the parameters on all of the synths, but they can't edit all of the parameters on all of the synths. The chances are also pretty high that, compared with a good VES written expressly for a particular instrument, the user interface (the screen or screens used for visual editing) will be neither as elegant nor as economical in terms of the use of screen space. Nevertheless, the advantages of a generic editor may still outweigh the compromises, depending on how you work. It is more than likely that, in the midst of working on a piece of music, you will not be programming new sounds entirely from scratch: on the other hand, you can't always get by with just a tweak.


Figure 6. Hybrid Arts' CZ Android: the main screen offers two independent work banks, a single patch workspace, and a bank corresponding to the CZ's internal memories.

It is worth noting that the librarian features offered by present day single instrument VES software easily blow the socks off the run-of-the-mill bulk dump programs and SysEx files in your sequencer. At the very least, a VES will have access to two banks of patches on screen at any time, and patches can be easily moved from bank to bank or from one location to another within a bank. Patches can be swapped or copied, and easily sorted into the order you need them. This affords more or less immediate access to your entire library, in such a way that multitimbral instruments should not be underexploited simply because the three sounds you want to use happen to be stored in three different files (see Figure 6).

Looking ahead, the coming generation of librarians will offer database-like features, enabling you to locate and use whatever patch you have in mind from a library of thousands of sounds - a case in point being Keynote's forthcoming Chameleon. A wide range of user-definable descriptive terms such as 'bright', 'noisy', 'breathy', 'plucked', 'percussive', and even 'favourite', can be assigned to each patch, so that a range of sounds from a huge library can be quickly auditioned. You no longer have to remember whether BRSPAD means 'brass pad' or 'bright spade', or just what sort of piano EPNO12 is. Figure it out as you put the patch into your library, give it a few labels, and the next time you are looking for it, all you have to remember is what it sounds like, not what you called it (Figure 7). (Similar features are also available on Steinberg's current crop of Synthworks editors; Steinberg refer to it as 'semantic tagging'.)

Figure 7. Keynote's Chameleon : a librarian that thinks like a musician, not like a librarian.

Of course, even a really good generic editor/librarian won't solve every problem. There may be an instrument or, as so often happens these days, a whole family of instruments, which are released after the generic systems hit the streets, and it is quite conceivable that such an instrument may require editing software which existing generic systems are simply not equipped to provide - but which a single instrument VES could cater for. There is also the problem of where to put such a piece of generic software. Sequencers like Virtuoso and Dr.T's KCSII don't use GEM, and some Steinberg software is notorious for crashing when used with desk accessories. Perhaps the answer is a MIDI merger and a second computer - that suits me fine, but what about my bank manager?

In the meantime the possibilities are limited: either you hope that your switcher program works, or you use a multitasking computer such as the Amiga (for which less music software is currently available). Alternatively, you can use Dr.T's Multi Program Environment (MPE), which allows that company's Caged Artist VES/Librarians (including X-Or) to run co-resident with their KCS sequencer. [Steinberg's MROS and C-Lab's Softlink multitasking operating systems will also allow sequencers and editors to be run simultaneously on one computer -Asst. Ed.] Both Virtuoso and Music X promise to supply VES modules which will run within their sequencers. Promising, indeed.


So where does this look at the world of Visual Editing Systems leave us? The ultimate in editing software is not yet with us, and nor is it likely to appear with the current wave of generic editors, but one thing is absolutely clear: if you are presently unable to run your sequencer and visually edit everything in your rack as and when you choose during a session, then you are not exploiting half the potential of your computer or your instruments. Figure out what half of your MIDI studio might be worth, then ask yourself if you can afford some serious VES software.

Previous Article in this issue

New Reality

Next article in this issue

Yamaha AVS10

Sound On Sound - Copyright: SOS Publications Ltd.
The contents of this magazine are re-published here with the kind permission of SOS Publications Ltd.


Sound On Sound - Nov 1989

Donated & scanned by: Mike Gorman


Should be left alone:

You can send us a note about this article, or let us know of a problem - select the type from the menu above.

(Please include your email address if you want to be contacted regarding your note.)



Feature by Greg Truckell

Previous article in this issue:

> New Reality

Next article in this issue:

> Yamaha AVS10

Help Support The Things You Love

mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.

If you value this resource, you can support this project - it really helps!

Please Contribute to mu:zines by supplying magazines, scanning or donating funds. Thanks!

We currently are running with a balance of £100+, with total outgoings so far of £844.00. More details...

Small Print

Terms of usePrivacy