http://bluehell.electro-music.com/iaf/
[/Notes]
2003-01-11, added bit count field for parameters. Based upon data files version 12
2001-06-21, Urs had some things to nag about :again -) Some minor adjustments for thecable dump section. Modiule type 74 (WaveWrap) added, module type 68 (ClkGen) did not have it's input listed. Thanks Urs.
2001-01-12, some minor modifications (some material was still describing the 301 and 302 editor versions instead of 303) Urs' had some data updates as well, expect some more fine tuning on resource usage in the near future (types 1-14 are double checked now).
2001-01-06, Thanks to Urs Liska again for supplying a lot of more detailed data. Most resource usage percentages are much more accurate now (within 1/32 or about 0.3 % of their individual values). Some modules could not be measured that precisely, this holds for all the module types for which only one is allowed in each patch. Such nodules are marked in the remarks section as only 1.
2001-01-03, some bug fixes and additions, thanks to Urs Liska for reporting these.
2001-01-02, thanks to Nicolas the whole thing is complete now, with module heights as well (new). Thanks to the text to html translator updates are efficient now :-). Can't believe it to be finished - please find some errors for me ?
2001-01-01, rearranged things a bit, the module definitions are placed into a separate file now, generated from the text definition files patch303.txt and s303.txt. Some errors & typos fixed as well.
2000-12-31, on the treshold of the 3rd millenium. A hell of a job it has been, but thanks to Nicolas Fournel (who supplied module info for the types 50 to 124) a big step forward was made - all modules are present now ! Finally finished now !
2000-11-15 - included some additional knob map dump info supplied by Urs Liska
2000-03-05 : modules 115 to 118 added (thanks to Christer Lindström), module details added upto module 49. Modifications made to the CurrentNoteDump section (thanks to Wout Blommers for the research)
| Module table | header | module dump | current note dump | cable dump | parameter dump | custom dump | keyboard assignment | knob map dump | morph map dump | control map dump | notes |
A patch file is built from sections. Sections are marked by a section header that look like [Header], they end with a section trailer that looks like [/Header]. The section header and trailer state the section's name. Between header and trailer section specific parameters are listed.
The next part shows the general layout for a v3.01 patch, click the links for detailed information.
[Header]
Version=Nord Modular patch 3.0
0 127 0 127 2 0 0 8 151 2 1 1 1 1 1 1 1 1 1 1 1 1 1
[/Header]
[ModuleDump]
1
1 17 0 3
4 45 1 2
[/ModuleDump]
[ModuleDump]
0
1 127 0 0
2 4 2 2
[/ModuleDump]
[CurrentNoteDump]
64 64 64 64 0 0
[/CurrentNoteDump]
[CableDump]
1
0 6 0 0 4 0 1
0 5 2 0 4 0 1
[/CableDump]
[CableDump]
0
0 5 2 0 3 0 1
0 9 0 0 3 0 1
[/CableDump]
[ParameterDump]
1
1 17 36 15 1 1 1 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 1 0 1 0 1 0 0 0 1 0 0 1
1
[/ParameterDump]
[ParameterDump]
0
1 127 1 0
[/ParameterDump]
[CustomDump]
1
7 1 0
[/CustomDump]
[CustomDump]
0
7 1 0
[/CustomDump]
[MorphMapDump]
10 2 0 0
0 2 0 0 -73
[/MorphMapDump]
[KeyboardAssignment]
2 0 0 0
[/KeyboardAssignment]
[KnobMapDump]
2 1 0 0
[/KnobMapDump]
[CtrlMapDump]
1 3 0 14
[/CtrlMapDump]
[NameDump]
1
1 EventSeq1
[/NameDump]
[NameDump]
0
1 PolyAreaIn1
[/NameDump]
[Notes]
Insert patch notes here.
[/Notes]
The header section contains the version number and a list of patch related parameters.
There seems to be a bug in the editor, the patch settings dialog has a pedal mode selection, the value of this parameter does not seem to be saved in the patch.
Numbered left to right from 1 to 23 we have :
| # | name | value | bit count | remarks |
| 1 | keyboard range, min value | 0..maxvalue | 7 | |
| 2 | keyboard range, max value | minvalue..127 | 7 | |
| 3 | velocity range, min value | 0..maxvalue | 7 | |
| 4 | velocity range. max value | minvalue..127 | 7 | |
| 5 | bend range | 0..24 | 5 | semitones |
| 6 | portamento time | 0..127 | 7 | |
| 7 | portamento | 0..1 | 1 | 0 ~ normal, 1 ~ auto |
| 8 | requested voices | 1..32 | 5 | |
| 9 | section separator position | 0..4000 | 0 ~ topmost, 4000 ~ bottommost | |
| 10 | Octave shift | 0..4 | 3 | 0 ~ -2, .., 4 ~ +2 octaves |
| 11 | Voice retrigger poly section | 0..1 | 1 | 0 ~ inactive, 1 ~ active |
| 12 | voice retrigger common section | 0..1 | 1 | 0 ~ inactive, 1 ~ active |
| 13 | [1] ? | I see no way to change these values, for routing ?? | ||
| 14 | [1] ? | I see no way to change these values, for routing ?? | ||
| 15 | [1] ? | I see no way to change these values, for routing ?? | ||
| 16 | [1] ? | I see no way to change these values, for routing ?? | ||
| 17 | cable visibility red | 0..1 | 1 | 0 ~ not visible, 1 ~ visible |
| 18 | cable visibility blue | 0..1 | 1 | 0 ~ not visible, 1 ~ visible |
| 19 | cable visibility yellow | 0..1 | 1 | 0 ~ not visible, 1 ~ visible |
| 20 | cable visibility gray | 0..1 | 1 | 0 ~ not visible, 1 ~ visible |
| 21 | cable visibility green | 0..1 | 1 | 0 ~ not visible, 1 ~ visible |
| 22 | cable visibility purple | 0..1 | 1 | 0 ~ not visible, 1 ~ visible |
| 23 | cable visibility white | 0..1 | 1 | 0 ~ not visible, 1 ~ visible |
The ModuleDump section lists all modules used in a certain section.
For the first line : the poly section starts with a 1 - the common section starts with a 0.
For all following lines : numbering left to right, from 1 to 4, the parameters have the following meaning:
| # | name | value | bit count | remarks |
| 1 | Module index number | 1.. | 7 | module index number, also see NameDump and ParameterDump sections |
| 2 | Module type number | 1..127 | 7 | see the Module table |
| 3 | X position (column) on the editor screen | 0.. | 0 ~ leftmost | |
| 4 | Y position (row) on the editor screen | 0.. | 0 ~ topmost |
See moduleDump - poly section. The difference is that the common section starts with a leading 0.
This section contains information on the keys that were pressed when the save current notes function was applied from the editor. The section has n entries of 3 items; in each entry the the first item is the note number, the 2nd item is the attack velocity and the 3d item is the release velocity.
| # | name | value | bit count | remarks |
| 1 | note | 0..127 | 7 | midi note number: 64 ~ middle E |
| 2 | attack velocity | 0..127 | 7 | |
| 3 | release velocity | 0..127 | 7 |
There seems to be bug, there is always one set of 3 elements more than expected from the number of requested voices. When 1 voice is requested this section will have 6 numbers in it. So which note is the one that is not played, the last one ?
The CableDump section lists all connections used in a certain section.
For the first line : the poly section starts with a 1 - the common section starts with a 0.
For following lines : numbering left to right, from 1 to 7, the parameters have the following meaning:
| # | name | value | bit count | remarks |
| 1 | cable color | 0..6 | 3 | 0 ~red/audio, 1 ~ blue/control, 2 ~yellow/logic, 3 ~ gray/slave, 4 ~ green/user1, 5 ~ purple/user2, 6 ~ white/loose wire |
| 2 | destination module index number | 1.. | 7 | module index number, also see NameDump and
ParameterDump sections For pre 3.03 patches this can be a source module index number as well, see NOTE 1. |
| 3 | input index number | 0.. | indexes into the input list of the destination
module For pre 3.03 patches this can be an output index number as well. |
|
| 4 | ? Pre 3.03 : connector type |
? | seems to be 0 always, and this might indicate that only input connectors
can appear here Pre 3.03 file formats can have a 1 here, indicating this can be an output connector specification as well. |
|
| 5 | source module index number | 1.. | 7 | module index number, also see NameDump and ParameterDump sections |
| 6 | connector index number | 0.. | inexes into the input list or the output list of the source module, this depends upon the value of field 7 | |
| 7 | connector type | 0, 1 | 1 | 0 ~ input, 1 ~ output |
NOTE 1: see the data as (cable-color)(connector1-spec)(connector2-spec), where a connector-spec = (module-index,connector-index,connector-type)) Some of the original Clavia factory presets for version 3.0x use the first connector descriptor for output connectors as well, the version 3.03 editor will save such patches according to a stricter format where the first tripplet will always describe an input connector.
See CableDump - poly section. The difference is that the common section starts with a 0.
The ParameterDump section lists most parameters for all modules used.
For the first line : the poly section starts with a 1 - the common section starts with a 0.
Each line (but the first) in the parameter dump represents a list of control (knobs etc) values for a certain module. For every module type the list of control values is different, but the first entry in the line always is the module index number, the second entry is the module type number and the third entry is the number of parameters that will follow. So there is some redundancy here.
| # | name | value | bit count | remarks |
| 1 | Module index number | 1.. | 7 | see ModuleDump and NameDump sections |
| 2 | Module type number | 1..127 | 7 | see the Module table |
| 3 | Parameter count | 1.. | The number of parameter values that will follw | |
| x | parameter | any | a module dependent list of parameters, see the Module table |
See ParameterDump - poly section, the difference is that the common section starts with a 0.
The CustomDump section lists some customization parameters for about half of the module types.
For the first line : the poly section starts with a 1 - the common section starts with a 0.
The other lines list the parameter values, as these depend upon the module type they will be listed with the other module specifications (see Module table)
| # | name | value | bit count | remarks |
| 1 | module index number | 1..127 | 7 | see ModuleDump and NameDump sections |
| 2 | parameter count | 1.. | ||
| 3.. | parameter 1.. | any | depends upon module type |
See CustomDump - poly section, the difference is that the common section starts with a 0.
The MorphMap dump gives settings for the morph knobs. When no morphs are assigned in a patch this section is not present.
The first line shows the settings for the four knobs
| # | name | value | bit count |
| 1 | morph 1 | 0..127 | 7 |
| 2 | morph 2 | 0..127 | 7 |
| 3 | morph 3 | 0..127 | 7 |
| 4 | morp 4 | 0..127 | 7 |
The other line describes the coupling between the morph and the knobs it affects.The line must be considered to be a repeated set of five parameters, where every set describes the morph settings for one knob.
| # | name | value | bit count | remarks |
| 1 | section index | 0..1 | 1 | 0 ~ common section, 1~ poly section |
| 2 | module index | 1.. | 7 | module index number, also see ModuleDump and NameDump sections |
| 3 | parameter index | 0.. | depends upon the module index, see Module table | |
| 4 | morph index | 0..3 | 2 | 0 ~ morph 1, 1 ~ morph 2, 2 ~ morph 3, 3 ~ morph 4 |
| 5 | morph range | -127..127 | a morph setting is described by it's start value and it's range. The start value is the current knob position and the range is given here. |
Please note that for certain knobs it is not possible to assign a morph to it without also assigning the same morph to another knob. I've seen this only with frequency control knobs for oscillators, where the morph that is assigned to the coarse control is also automaticly assigned to to the fine control.
Also for some other knobs it's not possible to assigne a morph at all.
The layout for the MorphMapDump section does not show these anomalies however, and I did no experiments as to see what happens when I go and fuzz it a bit.
The KeyboardAssigment section describes the assignments from keyboard related parameters to morphs. This section contains a single line with four parameters.
Keyboard assigments are possible only for morphs, and the only possible assignments are none, note or velocity.
| # | name | value | bit count | remarks |
| 1 | morph 1 | 0..2 | 2 | 0 ~ none, 1 ~ velocity, 2 ~ note |
| 2 | morph 2 | 0..2 | 2 | 0 ~ none, 1 ~ velocity, 2 ~ note |
| 3 | morph 3 | 0..2 | 2 | 0 ~ none, 1 ~ velocity, 2 ~ note |
| 4 | morph 4 | 0..2 | 2 | 0 ~ none, 1 ~ velocity, 2 ~ note |
The KnobMapDump section describes the assignments from knobs to parameters. This section contains a single line for each knob assignment, each line lists four parameters.
| # | name | value | bit count | remarks |
| 1 | section index | 0..2 | 0 ~ common section, 1 ~ poly section, 2 ~ morph section (the morph has module index 1, section index 2) | |
| 2 | module index | 1.. | 7 | module index number, also see ModuleDump and NameDump sections |
| 3 | parameter index | 1.. | depends upon the module index, see Module table | |
| 4 | knob index | 0..17, 19, 20, 22 | 0 ~ knob 1, ..., 17 ~ knob 18, 19 ~ Pedal, 20 ~ Aftertouch, 22 ~ On/Off switch |
The CtrlMapDump section describes MIDI continues controller (CC) assignments to module parameters. This section contains a single line for each controller assignment, each line list four parameters.
| # | name | value | bit count | remarks |
| 1 | section index | 0..2 | 0 ~ common section, 1 ~ poly section, 2 ~ morph section (the morph has module index 1, section index 2) | |
| 2 | module index | 1.. | 7 | module index number, also see ModuleDump and NameDump sections |
| 3 | parameter index | 1.. | depends upon the module index, see Module table | |
| 4 | CC number | 0..31, 33..120 | 7 | controller 32 is reserved for bank selection <would like to refer to a cc list here> |
The first line indicates that this is a poly section. The other lines tie a module index to a module name. The module name is the name that can be changed by the user, it is not the module type. Modules are typed through their module type number (see ParameterDump and ModuleDump)
| # | name | value | bit count | remarks |
| 1 | module index number | 1.. | 7 | module index number, also see ModuleDump and ParameterDump sections |
| 2 | module name | string[16] | a string of up to 16 characters |
See Name - poly section, the difference is that the common section starts with a 0.
The notes section seems to be a free format text - although very large text's seem to be a problem. When the word [/notes] is included the patch will be saved with this, upon reload of the patch however it will be stripped out and the text that was typed after [/notes] will not be lost.
The 302 beta had a bug, it deleted empty lines from the notes section, 301 did not have this bug. Version 303 still has this bug.
Version 301 (302 ?) used a slightly different patch format, certain dumps existing for both the Poly and the Common section started with a line containing the section index directly followed by the first value set on the same line. Version 303 uses a separate line for the section index.