vl1proto

max/msp, Intel/PPC, simon2008-, current vers. 0.3)

The Yamaha VL1-m is a legendary and a superb synth, uses physical modelling and programming it is quite complex. You may program it from its console, which is tiresome, or the use the (nearly complete) Yamaha Expert-Editor (which is said to have been used by the Yamaha programmers to program the factory-voices). There also existed a PC-version (also incomplete, afaik) and a few very basic Yamaha programs. Nowerdays these OS9-programs are more or less obsolete, if you dont keep the hardware, as i do (i use a PB1400 just for the expertEditor and an Emagic Amt8 which has serial connection). Actually, there is also a (not complete) VL1m-adaption for the program Sounddiver (which runs on Intel-Mac, but is also more or less obsolete, since you need an old LogicPro7-dongle for tha last version3.1.0 Public Beta 2).

Some years ago i started to write MaxMSP-programs that allowed me to control some of the parameters of the VL1m from the computer in performance-situations. These developments lead to the ombOS system. On the other hand I was thinking also about writing a complete programming-editor for the VL1m, just for the case my PB1400 passes away, or whatever... So one option was to just replicate as close as possible the legacy Yamaha ExpertEditor (consists of nearly ten screens full of sliders and selectors). It is organized in a way, but every time i use it i always wonder, if this could not be done differently:

Develp a new synth-programming paradigm...?

But the situation with the VL1-m is complex:

The VL1m is based on algorithms developed by the Stanford University (Smith) and the patents have been bought by Yamaha. In these days a dedicated hardware was the way to go. Today i think the VL1m should actually be ported to a Softsynth. Although it is dated, it is still worth it. So instead of duplicating an editor that controls an outdated harware-synth, one shouldactually put energy and time in porting the algorithms to software. Yamaha does not seem to be interrested though. And for a single person its too big a project.

On the other hand i am interrested in developing a new synth-programming paradigm, so why not use the VL1m, since its complexity is good to proove the concept.

... look at the problem from the users perspective!

The original editor (and actually most of the editors around) just tries to find some order for the thousands of parameters and gives the user a few diagrams and parameter-descriptions to find his way through the jungle. But the complexity of the VL1m works against it: the interaction of several parameters, which means that when you change one parameter then often other parameters are affected and have to be changed also. Put differently: very seldom a desired change in the behavior of a sound comes from the tweeking of one parameter, but a concerted tweeking of several. But you have to know which. This makes programming a tidious trial and error process. And you never know how close you came to an ideal parameter-constellation.

So my idea is to focus less on the representation of these thousends of parameters, but onto the workflow of the programmer.

This workflow with the original editor is a sequence of parameter-changes. Maybe you have adapted a kind of editor-based systematic, that lets you go from parameter to parameter and look if it changes the voice in the direction you desire. If you are a bit more advanced you might jump all over the places in the editor, because you got something like a mental map of where parameters are in this particular editor and which could be involved in certain effects. The problem with both methods is, that the process is so complex that you cant really keep all the details of effects and relationships of parameters in memory. You might remember some relationship, but forgot that it applies to a certain kind of voices (say pipe-type, but not string-type voices), so the memory is not helpful.

So i thought your editor should provide an environment where you deal with networks of parameters - instead of a representation of ALL the parameters. That is.: you can think of several ways parameters relate to each other: alphabetically (name), legacy order, functionally, procedurally, associative, whatever. Some of these relationships can be hardcoded (e.g. the alphabetical access), other relationship-networks develop in the process of programming. E.g. say you want a more metallic sound and you try different parameters and give them a + or - if they are helpful in the task. The editor turns these ratings into maps of coordinated parameters and may even factor in the values or trend of value-changes. So the editor is connected with a protocoller that 1. automatically logs all the changes you do and 2. allows you to comment these changes in natural language (for the programmer) and in ratings (for the analysis and netbuilding).

This would improve the typical voice-programming process, because it is difficult to keep track of the interrelated effects of parameter-changes. Secondarily to build a database from these protocolls, that can be used to map certain parameter-constellations to descriptions. Thirdly, to allow all sorts of processing with accumulated data.

So, part of the project is to experiment with and develop a new editor-paradigm. Therefore - to compare the feel of the old and the new approach - it is possible to combine the original Yamaha-Editor with the protocoller, in that the protocoller intercepts the communication with the synth.

VL1PROTO FEATURE DESCRIPTION v.0.3. (090210)

The vl1proto interface consists of a

• voice-related section
• parameter-related section
• protocoller-section

and has connections to other moduls, most notable:

• in@out (where the midi-device selector menu or the initialize button can be found)

Every interface-elemtent shows its name at mouse-over.

• ff-out1 - - - vl1m-in
• vl1m-out - - - ff-in2
• vl1m-thru - - - vl70m-in
• vl70m-out - - - ff-in1
• in&out: midiOUT - port1, midiIN - port2

... allows to see the wax-parameters and load voices from vl1 at the same time.

Voice Section

Two slots for voices (to be compared), each featuring:

• load voice list button - retrieves names of all voices stored on vl1 and populates the voice-menu with the voice-names
• select voice from voice-list menu - to change voice on synth and read the parameter-space into the parameter-array
• select voice-folder button - displays a dialog to choose a voice-folder and populates the voice-file-menu with the voice-filenames (voices in a file-folder on computer)
• select voice-file from voice-file-menu and read the parameter-space into the parameter-array and into the vl1 as current voice
• load current voice from the synth into the parameter-array
• voice-name display/editor - to see/edit name of current voice (10char)
• save current voice button reads out parameter-array of current voice, opens a file-dialog and saves as file

Parameter Inspector

Interface-section to check individual parameters of the loaded voice in each voice-slot.

• address-selectors - numberbox for each slot (top/middle)
• up/down-stepper (middle) - steps through both voices at the same time to compare values at a chosen address
• adress-value (numberbox, outside) the value that is actually stored in the voice (which is not always the same as the parameter-value, below)
• parameter-name textbox
• parameter-value slider (with min/max-value of range, below)
• parameter-value numberbox
• parameter-value textbox (some values are not numbers but names, e.g. midicontroller)

Protocoller Section

Interface options:

• protocoll function menu - open win, close win , read file, write file, clear content
• filename - read/write-box
• comment edit text box - enter-key clears the box and transfers comment to the log-file
• evaluation (e.g: +-= with 4 arrowkeys).
• description-selector menu - selects pre/user-defined keywords and insert them in the current protocol
• compare button - compares the parameter-values of the voices currently loaded in the two slots and list all parameters with differing values: par-name value-voice1 calue-voice2
• Protocoll Window
• search functions to be implemented...

Automatisms:

When a new voice is loaded from file or from vl1 the protocoller automatically logs it in the protocoller-window/file:

date time voicename

Every parameter-change (intercepted from ExpertEditor, or initiated from the parameter-section) is logged automatically in the form:

date time par-name (adress) par-value comment evaluation

...

Programming Notes

A VL1-voice consists of 3102 bytes, most of which hold values for parameters of the physical-modelling algorithm. A parameter has an address (number in the 3102-sequence), a parameter-name and a value. The value is often a number in the range of 0 and 127 (or below), but can also consist of two adresses, to allow larger value-ranges. For the user-level the internal values are (specifically for every parameter ) converted into other ranges (e.g. -64...63).

There are different types of midi-messages that have to be intercepted and recognized: bulk-dump, parameter-change, program-change, dump request. For my special working-setup vl1proto has to support different configurations, devices and routings at the same time, particularly the program has to handle all kinds of in/output of voice-data to file and to the VL1-synth.

A voice has about 1200 relevant parameters, or 2400 if it is a dual-voice, so already writing the parameter-names takes time. Parameters have different value-ranges (0 - 127, 0 - 1023, -64 - 63, -7 - 7, -16 - 16, -127 - 127, and others), some have to be assembled from several parameter-adresses, or are conditionally dependent from the value of switching parameters. Some values are integers, some %, some oct, others are menu-items. Different amounts of consecutive parameters form envelope-generators with different numbers of breakpoints. All these different parameter types make it a hassle to accomodate all individual cases. Different conversions have to be performed between adress-value, parameter-value, slider-value (e.g negative parameter-values in the range (-64 - 63) are mapped to adress-values 64 - 127). Max-MSP is not an ideal environment to build this conditional diversity.

Rewriting the entire Yamaha expert-editor would be nice (because it exists only as a Mac-OS9 program and needs a computer with serial-out), but it would be a major programming-job. Especially since there are undocumented, complex functions (e.g. in the tune-module), which might be difficult/impossible to re-engineer. An even better thing would be to emulate the hardware of VL1 in software.

For now I integrate the expert-editor in the set-up: vl1proto intercepts its communication with the synth and rebuilds a file-based parameter-space. vl1proto is a useful complement to the expert-editor, in that it improves or introduces non-existing functions: loading/saving and comparing voices; fast-access/display and commenting parameters;

There may exist serious objections against this project:

• why invest work in an outdated synth (VL1)
• why re-write an existing software (expertEditor)
• wouldn't it be better to develop new synthesis-approaches

Yes this synth is dated. Not out-dated. I think it is unsurpassed in the soundness of its approach (physical modelling) and the richness of its capabilities. At the moment I do not think of re-writing the Yamaha-ExpertEditor Program (Mac-OS9), but at some point in the development of VL1proto it may be a relatively small step to implement most of the features of the ExperEditor. And yes, new instrumental synthesis is of interrest, but that is no reason to abandon interrest in the vl1. It is the most advanced synth i came across sofar. From what i can find in the web I dont think that it has been thoroughly researched and understood. And the factory- and third-party-voices I have tested are far from what this synth is capable of. Even my own best voice may certainly be improved.

There are reasons for this project of more general nature:

Physical Modelling (PM) of the complexity as implemented in the VL1 opens a practically infinite, potential space of defining, or actually finding instruments, close to building physical instruments. It is contrary to other synthesis-approaches, which appear much more deterministic and straight forward. As computing-power increases there will be software-implementations of PM which then need layers above the elementary value-level that make the approach comprehensible and dataprocessing manageable. We have to find ways to program such a synthesis-engine. So general questions would be:

• how do we currently program such a beast? What are the steps, decisions and goals?
• can we optimize voice-programming?
• is it possible to improve the descriptive approach to characterize a "good instrument"?

This project does not aim at directly improving the voices themselves, in the sense of automatically producing perfect PM-instruments. It first wants to understand and improve the process of voice-programming. It is similar to the difference between setting up an industry-style assembly-line that mass-produces stradivaries, versus researching the open-ended knowledge and continuous considerations a violin-maker employes when building an individual instrument. Another aspect is that an instrument is nothing by itselves. It needs the player. A beginner and an advanced player need different instruments. Certain music may need a special instrument. So there is not one ideal instrument. But there is also no direct relation between what we need and what we get, as typical synthesis suggests. An instrument-player-system is dynamic and mutually change each other.

Let me sketch several possible features/moduls of vl1proto to exempify directions of the concept:

Basically that is: this vl1proto-modul proposes a random parameter-change and the human evaluates the voice. The evaluation determines the modul's next step. The purpose of randomizing is to escape traps we tend to induce into the process, to escape running in cycles, when we found a local maximum in the parameterspace. The human judges each version of an instrument and thereby influences direction and intensity of randomization. Gradually rules will be introduced. So random is only a start, or a restart when stuck and a method to make rigid rules more fuzzy.

We may consider different approaches:

1. start with a good-sounding and playable voice. At each step one parameter (of the core parameters) is randomized (i.e. randomly chosen and assigned a random value), tested and evaluated by the player and some messures taken by the system as a consequence of the particular evaluation and knowledge from former evaluations. Changes will be minimal (prone to overlook when it is geting worse)
2. the system prandomizes several parameters (say 5) and goes back if it has become worse.
3. the system randomizes all parameters. If a playable and interresting voice is found it is stored (e.g. to be fine-tuned by approach 1 or 2)

How do we procede in voice-programming: we tend to make hypthesis and tend to follow them. We tend to proceed from the known as long as we can, even if it is wrong or doubtful. Actually we overestimate some changes we made and underestimate alternatives. Decisions are based on a mix of seemingly-physical (messurements) and psychological impressions. We have an image of what a "good instrument" is, which is actually prone to deception more than we think (e.g. there has been a test of specialists to find out a Stradivary from three violins beeing played by three vialinists behind a curtain. Most specialists missed the Stradivari, although they were absolutlely sure, that they would recognize it). I can tell that voice-programming actually defines the image of what a good instrument is. It is a learning process establishing the image and it importantly includes learning to play it. And that is, not when the instrument is finished but during the voice-programming process, because it has to influence this process.

With this background in mind we can formulate some initial definitions:

• All parameters form the "parameter-space" (a VL1-voice consists of 3102 adresses, up to 2500 of these parameters may be involved in the behavior of the instrument, most of these parameters have a range of 128 values, thus the parameter-space opens a combinatorial capacity of say 1000^1000^100 more or less different voices.)
• Some parameters, though, can justifiably be thought of as belonging to a higher level (level, reverb, panning, EQ, etc.) and will be excluded from the following (although some can produce artifacts that significantly determine the character of a voice)
• Other parameters can be thought of as modifiers, which we may deal with at a later time to first focus on the parameters involved in the core of a voice.
• There is structure in the parameter-space that we do not need to make subject to randomization (e.g. key-scales)

These meassures aim at reducing complexity. They are based on hypothesis that may be false, though. So at some point they have to be challenged. But for the moment it is desirable, to operate on a small as possible sub-set, say 200 parameters, to be able to check what effect certain manouvers have.

From previous voice-programming i can subsume:

• A PM-voice is actually an instrument, because if programmed well, it has a rich behavior, similar to a physical instrument. Therefore editing a voice is actually a programming task in the best sense, because mostly there is no on/off, or more/less of behavior, rather it requires to set up a multitude of interacting conditions from which a behavior emerges.
• These conditions result from parameter-constallations, seldom from single parameters.
• A parameter thus has a context of other parameters, which it influences/it is influenced by (although we dont know exactly the extent of a context)
• A parameter references a value within a certain range. Changing the value may or may not have some audible effect or change playability.
• The change of behavior can be linear (e.g. volume-parameter), of some curve, or chaotic. The behavior and the change of behavior of a parameter may be different in another context (i.e. when other parameters change and thereby influence it)

Lets define a basic rule-set:

• Let randomization concern parameter-nr and the corresponding values and allow degrees of randomness
• Jumping all over the parameterspace and choosing single values for a parameter would be higher randomness compared to consecutively testing several values of a parameter and switching back and forth between one parameter and others.
• Dont let us entrap ourselves in sophisticated analysis, but modestly define three simple grades for evaluation, e.g.:worse, equal, better (-1, 0, 1)
• there is the special case that a constellation is unplayable. It will be remebered and excluded.
• As reaction to a evaluation there can be more rigerous or more inquiring rules
• -1 may undo the last step and choose another parameter, or check if other values of the same parameter result in the same evaluation (the former value was a local max)
• 0 undos or keeps the value of this parameter, may test if the parameter is insignificant for the context at hand.
• 1: keeps the new value, may test if it can be improved further
• More randomness can provide an overview of the potential and show that and where local maxima can be found, more systematic rules make sense in the process of refining a voice, or can even establish an investigative strategy to aquire general knowledge of certain aspects of voice-programming
• Strategies could be e.g. to verify if the effect of a paramater is linear or nonlinear along the value-range, or how much it is influenced by other parameters

(reed more on voice-programming in: electronic instrument building)

to be continued....

(1) this program can be used for the Yamaha VL1 and VL1-m. With restrictions/optional conversion it could also be used with VL7, VL70-m and the VL-expansion/pluggin-card which is compatible with a line of Yamaha synths like the MU100, EX7, EX7R, EX11. It is written in Max-MSP and is compiled for Mac OS10 (Intel) and could be compiled also for PC. Its main purpose is research, so there is no immediate intention to publish or commercialize it.

(2)

uea-io.de/wax