pch2csd: an application for converting Nord Modular G2 patches into Csound code
ppch2csd: an application for converting Nord Modular G2 patchesinto Csound code
Gleb Rogozinsky
The Bonch-BruevichSaint-Petersburg StateUniversity of Telecommunications,St. Petersburg, Russia [email protected]
Mihail Chesnokov
JSC SEC “Nuclear Physics Research”St. Peterburg, Russia [email protected]
Eugene Cherny ˚Abo Akademi University, Turku, FinlandITMO University,St. Peterburg, Russia [email protected]
ABSTRACT
The paper presents the pch2csd project, focused on con-verting patches of popular Clavia Nord Modular G2 syn-thesizer into code of Csound language. Now discontinued,Nord Modular G2 left a lot of interesting patches for soundsynthesis and algorithmic composition. To give this her-itage a new life, we created our project with the hope forbeing able to simulate the original sound and behavior ofNord Modular.
1. INTRODUCTION
Clavia Nord Modular was one of most remarkable hard-ware synthesizers of the late 90s. It inspired a whole newgeneration of modular synthesizer fans by combining theimmediacy of dedicated hardware with the power and flex-ibility of computer-based programming. The suite of com-ponents comprising the NM project included an extensivelist of modules (from oscillators to effects), an attractivesoftware graphical interface and on the hardware side, key-board and rack options. This synthesizer has been used ex-tensively by many artists such as Astral Projection, Autechre,The Chemical Brothers, Somatic Responses, Junkie XL,Mouse on Mars, Nine Inch Nails and Covenant among oth-ers.What really makes Nord Modular unique and sustains itsrelevance is the active community, which created a richarchive of patches. Alongside their inherent use to mu-sicians, these patches can also incorporate a valuable edu-cational aspect, inspiring people to develop their own cre-ative signal processing and sequencing skills.Unfortunately, Clavia ceased the Nord Modular produc-tion in 2009, and at present time it could be hard to buythe synth from the second-hand market to explore the vastcollection of creative patches that were made by the com-munity since the late 90s.To facilitate the liberation of the NM patches from theclosed source software and provide it with a continuingexistence, we started a project called pch2csd in 2015 to(re)implement the Clavia Nord Modular G2 sound engine
Copyright: c ⃝ in Csound, a well-known sound and music computing sys-tem. Csound is one of the oldest computer music systems,it carries the sounds (and patches) from the past, whichwere originally compiled on mainframe computers back inthe days, but have been continually re-compiled through-out the intervening years. Even now Csound can compilemany sources written for the older versions of the lan-guage in the 80s. But despite it’s heritage, at the presenttime Csound is being actively developed, and currently,the Csound code can interoperate with almost any pro-gramming language, providing robust, high performanceand cross-platform solution for sound computing in real-time applications. Csound had been ported to iOS, An-droid and Raspberry Pi, there are Csound-based DAWs,tools to transform orchestra files to VST/VSTi plugins, alibrary for the Unity3D game engine [1], Jupyter notebookbindings and many more .The fist report on the pch2csd project was made at theThird International Csound Conference (St. Petersburg,Russia 2015) [2]. We presented the main concept of theproject, the brief description of the code and a very sim-ple “proof of a concept” working example. Since then, anumber of improvements has been made, including newmodules, mapping tables, and other code generation im-provements.This paper provides the report on current project status,as well as the engine implementation details.The paper is organized as follows. Section 2 lists someother works on simulating music hardware in Csound. Sec-tion 3 provides the overview of Nord Modular G2 and it’spatch format. Section 4 describes the implementation ofthe sound engine in Csound language, including the trans-formation from the NMG2 patch format. Section 5 dis-cusses several patch conversion examples. Section 6 de-scribes the limitations of the project. In the section 7 weconclude the paper and provide some directions for futuredevelopments.
2. RELATED WORK
Csound already has its own history of hardware emula-tion. There are several opcodes which emulate Moog fil-ters and also the mini-Moog synthesiser. The DirectHam- A (not extensive) list of tools and instruments built on top of Csoundcan be found at the community websie, URL: http://csound.github.io/create.html
Proceedings of the Sound and
Music
Computing
Conference,
June
Espoo,
Finland
SMC2017-415 ond synthesiser written by Josep Comajuncosas emulatesHammond with the Leslie effect [3]. The Csound Bookgives a simulation of the famous Roland TB303 [4]. An-other example of TB303 was given by Iain McCurdy, whoalso wrote a code for emulation of Korg Mini Pops 7 andRoland TR-808 drum modules [5]. Csound had been usedfor emulating Yamaha DX7 [6]. Several experiments werecarried to emulate the sound of Access Virus and RolandJP80xx, for example [7]. Eugenio Giordani and Alessan-dro Petrolati created a commercial app which emulatedVCS3 by EMS [8].The DX7 implementation stands apart from other exam-ples, as it translates the synth’s presets into a dynamicallygenerated Csound code. Essentially the same approach isused for this project, but the code generation is more com-plex in our simulation.
3. NORD MODULAR OVERVIEW
Nord Modular and Nord Modular G2 were a unique hybridsoftware-hardware systems. They ran on several DSPs, butwere controlled through a GUI using the software editorwhich is still available from the Clavia website . Once(re)programmed, device can be run in a stand-alone hardware-only mode. For programming, the device should be con-nected to PC or Mac via USB cable. One can also find afreely downloadable copy of demo editor.The Nord Modular system works only in real-time sothe number of modules and voices are the most impor-tant parameter. Different modules cause different load.To optimize the performance several modules were usedwith almost identical functions, but with different oper-ability. For example, OscA oscillator allows changing itswavetype on a flight, comparing to
OscD , which uses thesame wavetypes but demands the patch to be recompiled.There are two main parts of the patch: voice and fx . The voice part is a subject of polyphony, comparing to fx partwhich receives the mix of all voices. Obviously, the greaterthe number of voices played simultaneously, the lesser num-ber of modules can be used before overrun.Nord Modular G2 uses fixed sampling rate of 96 kHz foraudio signals and 24 kHz for control rate signals (i.e. mod-ulation). The overall number of modules is around 200, in-cluding numerous sound generators, envelopes, lfo, filters,random generators, mixers, delay units, switches, MIDIunits, logics, waveshapers, sequencers and FXs.There are 17 sound generators, most of which provideclassical waveshapes with modulations. There are also noisegenerators, simple physical models and a built-in DX7 model.The Filter part consists of 14 filters, i.e. various LP, HP, BPand BR models, and also comb filter, formant filter and a16-band vocoder. The section also includes three differentequalizers of up to 3 bands. The Envelope section provides9 envelope generators from simple Decay-only generatorto multistage one. There are 16 units in a Mixer sectionsstarting from one channel volume controller to 8 channelmixing unit. The FX part includes chorus, phaser, flanger, Nord Modular G2 official page, URL:
Figure 1. An example of the input-to-input connection:the output of the oscillator is connected to the both (leftand right) inputs of the stereo output module.digitizer, frequency and pitch shifters, scratcher, reverb anda compressor. Delay units are included in the separate De-lay section. There are 10 different units, from static one-tap delay to complex stereo delays. The Switch sectioncontains various switches and dmux/mux units. The Logicincludes common binary logic units, i.e. typical logicalfunctions, flip-flops, pulse dividers and counters. Thereare also ADC and DAC converters. All waveshaping unitsare placed in the Shaper part. There are 7 of them, i.e. clip,drive, saturation, rectifier and wrapper units. The Levelsection relates to any modulation types. It also containsthe envelope follower unit. The Random section includes6 various random generators. The Sequencer part includes5 sequencers of different kinds. All of sequencers can belinked in chain. There also MIDI, In/Out and Note sec-tions. The detailed info on each unit can be found in offi-cial NM2 manual.A sound programmer connects the modules using virtualcables. The main cables types are: red (audio signals @ 96kHz), blue (control signals @ 24 kHz), yellow (logic sig-nals in the form of pulses @ 24 kHz), orange (logic signals@ 96 kHz).In addition to these cable types there are also two user-defined types: green and violet. Actually the user can colorany cable in any color using the context menu of an editor,i.e. change color of red cable into yellow. Also there are’dead’ cables of grey color. They appear if you break thevalid link of modules.Another peculiar feature of Nord Modular system is anability to connect one input to another. So if you wantto connect the output of a generator to both inputs of the
Out module, it is allowed to connect one input to another(Fig. 1), and the output from the generator will be passedto both inputs.Also, several modules can change their type, i.e. from redto blue, depending on input connections, i.e. connecting ared cable to any input of mixer turns it from default bluetype to a red one.Moreover, there are some hidden modules which were notincluded in the release version of the editor, i.e. Resonator,Driver, AR-Env, PolarFade. Most of them are not working,but some can be useful . Nord Modular G2 stores patches in a binary file with theextension pch2 . The format is proprietary and has not been A discussion about hidden modules in Nord Modular G2:
Proceedings of the Sound and
Music
Computing
Conference,
June
Espoo,
Finland
SMC2017-416 fficially published by Clavia, so we rely on a commu-nity effort to decode the format done by Michael Dew-berry in the 2005 [9]. According to the information hepublished, the pch2 file starts with a text header terminatedby the NULL byte. It contains general information aboutthe patch (e.g. version, file type, etc.) in human readableform. This text header is followed by a two-byte binaryheader, representing the patch format version and the filetype (a patch or a performance ). All other information isstored in a series of “data objects”. A byte layout of someobjects is presented in the Appendix. For the purpose ofthis project we do not use such objects as Knob Assign-ments, MIDI Controller Assignments, Module Names andTextpad. Hence we read only those, representing the ac-tual sound modules and their connections. For this, wefirst read Patch Description object (Table 3), then read twoModule List objects (Table 4) for VA and FX , then skipthe Mystery Object (Table 1), then read two Cable Listobjects for VA and FX (Table 2), and finally we read twoModule Parameters objects for VA and FX (Table 5).
4. IMPLEMENTATION4.1 Overview
The project is implemented as a C program. The programextracts module and connection lists, as well as parametervalues from the pch2 file, and then composes a csd filefrom Csound code templates and mapping tables storedas plain-text files. We currently have 100 modules imple-mented as Csound user-defined opcodes (including filters,mixers, etc.) and 35 hand-crafted mapping tables to mapvalues from the linear MIDI range to non-linear parameterrange. Storing the data as text allows anyone to change thebehavior of the modules without touching the C code.
We began with the challenges related to oscillators mod-eling. Any sound synthesis algorithm starts from somegenerator, thus the first and the most important part of thepatch to be simulated is an oscillator section. The Nordoscillators produce aliased waveforms at 96 kHz. The Fig-ure 2 shows the amplitude spectra of Clavia’s sawtooth.The audio was recorded at 96 kHz/24 bit on the FocusriteSaffire PRO 40 audio interface. The solid line at the rightborder of plot is a Nyquist frequency (48 kHz). The spectrawas calculated using 2048 points FFT with Hann window.We can clearly see the aliasing part of the spectra, mir-rored from the Nyquist frequency. This feature of NordModular distinguishes it from the popular family of so-called analog-modeling synthesizers, which typically pro-duce alias-free waveforms, and makes it possible to simu-late the corresponding waves by simple generation of idealpiece-wise functions. Numerous records of the oscillatorwaveforms also prove it well. Note, that objects like this appear twice in the patch file, in the VoiceArea and in the FX Area. We do not currently know the purpose of this object, but in ourproject we are only interested in a list of modules and their connectionsto reconstruct patches in Csound, and we have not yet found any caseswhere we would need to inspect this object more closely.
Figure 2. An amplitude spectra demonstrates the aliasingin the NMG2 sawtooth oscillator waveform. A solid verti-cal line to the right is the Nyquist frequency.Filter analysis has been performed through connectingwhite noise generator to the corresponding filter of Claviaand comparing the output amplitude response with the fil-ter models created by the authors.
To simulate the sound and behavior of modules of ClaviaNord Modular G2 we used Csound [10]. It is an open-source language for computer music and digital audio pro-cessing developed in MIT 1986 by Barry Vercoe and re-cently developed by a global community of enthusiasts.Csound can be run on all popular platforms including An-droid and iOS. Through Csound API it can be embeddedin lots of applications, which makes it a nice candidate forNord simulation together with a great amount of includedopcodes .Csound document typically consists of two sections. The Instruments section contains all definitions of instrumentsto be used, and the
Score part contains timeline events andfunction tables. Each of Nord modules is modeled as anUser-Defined Opcode (aka UDO). At the conversion frompch2 to Csound the UDOs, which relate to patch’s modulesare read from txt files and included to the Csound docu-ment. Csound compiler reads code lines from top to thebottom, which is completely different approach to graph-ical system of patching, like MAX, Pd or Nord. Fortu-nately, Csound has a special patching system called zak-space . It provides a given number of audio rate (a-rate) andcontrol rate (k-rate) buses to intercommunicate betweendifferent instruments and UDOs. There are separate com-mutation matrix for audio rate signals and another one forcontrol rate signals. They are completely independent fromeach other, comparing to Nord patching system, where thecables are sequentially numbered. A separate part of ourcode solves that disparity by renumbering the cables af-ter reading their numbers from the patch file. Comparingto typical behavior of Csound opcodes, where each opcode All up-to-date Csound features can be found on the community web-site: http://csound.github.io
Proceedings of the Sound and
Music
Computing
Conference,
June
Espoo,
Finland
SMC2017-417 ypically accepts an input data as some parameters and out-puts the result, our zak-based UDOs do not have any out-puts.In more practical view, the typical Csound opcode/UDOis applied like this: aOut1 SomeOpcode aIn1, aP1, kP2 [, ...] where aIn1 is an input of audio type, aP1 is an a-rateparameter, kP2 is a k-rate parameter, and aOut1 is an a-rate output.In our system we have
SomeOpcode aP1, kP2 [, ...], kIn1, kOut1 where aP1 is an a-rate parameter, kP2 is a k-rate parame-ter, kIn1 is a number of some k- or a-rate bus to read inputdata from, and kOut1 is a number of some k- or a-rate busto send data to.After parameter field our UDOs have IO field, in whichthe numbers of buses in zak space are listed. Using de-scribed approach we are free to list the opcodes in any or-der, just like Nord Modular user can add the modules inarbitrary order. So the first indexed module can be easilythe last one in the audio chain.Another important aspect to be described here is map-ping. Nord modules have several different controllers of alot of ranges, i.e. audio frequency range, amplitude range,normalized values in the range from 0 to 1, delay timeranges, envelope stage durations, etc. The real values ofthe controllers can be seen only when using editor. Thepatch file stores 7 bit MIDI values without any referenceto appropriate range. It made us to manually fill the tablewith data types, ranges and values. Special mapping filesof pch2csd project contain numbers of tables to be used foreach parameter of each module.I.e Module
LevAdd module) table contains follow-ing lines: s 2 LVLpos LVLlevd BUT002
It means that the mapping table for the first parameter of
LevAdd (value to add to input) is dependent on a second ( )parameter, which is the two-state button (table BUT002 ).The button switches
LevAdd from unipolar to bipolar rangeof values. The mapping tables are placed in a separate sub-directory of a project.Also during the development we had to solve a polymor-phism issue. Several Clavia modules are polymorphous.Unfortunately there is no direct indication of current mod-ule type (a-rate or k-rate). It can be discovered only throughanalyzing cable connections. So our algorithm checks themodule type, and its input connections. In case of non-default type of the input, the corresponding module twin isused instead of the default one.
5. EXAMPLES
Here we demonstrate the conversion of a real Clavia’s patch(see picture ...). It consists of a noise generator, a simple 1-pole LP filter and an Output module. We give this ex-tremely primitive patch not for the purposes of timbre dis-cussion but rather to present a clear example of how ourconverter works.The converter default output file is test.csd in the programdirectory. Comments are given after semicolons.The algorithm detects three different types of modulesand take their UDO definitions from the library. sr = 96000 ; audio sampling rateksmps = 16 ; times k-rate lower than a-ratenchnls = 2 ; number of output channels0dbfs = 1.0 ; relative amplitude levelzakinit 4, 3 ; Init zak-spaceopcode Noise, 0, kkk ;White Noise generatorkColor, kMute, kOut xinif kMute!=0 goto Mute ;mutes sound if Mute is Onaout rand 0.5, 0.1 ; seed value 0.1aout tone aout, kColor ; Csound simple LP filterzaw aout, kOutMute:endopopcode FltLP, 0, kikkkkk ;One-pole LP filter; Keyboard Tracking has not been implemented yetkKBT, iOrder, kMod, kCF, kIn, kModIn, kOut xinain zar kInkmod zkr kModInaout tonex ain, kCF+kmod*kMod, iOrderzaw aout, kOutendopopcode Out2, 0, kkkkk; Output module; Only stereo output has been implementedkTarget, kMute, kPad, kL, kR xinif kMute!=0 goto Mute:aL zar kLaR zar kRouts aL*kPad, aR*kPadMute:endopopcode Constant, 0, kk ;Constant value; Only bipolar mode nowkVal xinzaw kVal, kOut ; CHANGEendopinstr 1; VA sectionNoise 10000,0,2FltLP 0,1,0.5,1050,2,2,3Constant 24,2Out2 0,0,1,3,0endininstr 2; FX sectionendin; Here goes the score part of Csound.; We just let it run for a long time...i1 0 [60*60*24*7]i2 0 [60*60*24*7]
We use two special buses per each matrix. Buses
Proceedings of the Sound and
Music
Computing
Conference,
June
Espoo,
Finland
SMC2017-418 igure 3. Sawtooth waveform’s amplitude modulated withan envelope. Nord Modular G2 is on the left, our imple-mentation is on the right.Figure 4. White noise filtered with LFO modulated low-pass filter. The file lengths are equal to 3 seconds. NordModular G2 (left) compared with our implementation(right). The Clavia’s LFO is not exactly a sine.
6. EVALUATION
The practical study of the software shows several issues.Beginning from the oscillator block of the synthesis pro-cess, we discovered that Clavia oscillators run at arbitraryinitial phase. So at each run or patch re-compilation thecomposite waveform of the sum of oscillators slightly dif-fers. Also the exponential form of Clavia envelope gen-erators seems to be sharper than real exp function 3. Wealso discovered that typical sine LFOs actually produce abit asymmetric function. The figure 4 shows the differencebetween spectrograms of signals at the output of modu-lated LPF.During developing we estimated several main limitations.First is related to the modules with non-determinate be-haviour, i.e. all modules from the Random group. Each ofthose modules generates a random sequence, in which thecurrent value depends on previous one. Such a behavior isnot typical for Csound random generators. Another limi-tation relates to the patch presets. Each of Nord Modularpatch contains 8 presets called Variations. User can selectthe desired preset from the interface. This feature has notbeen implemented yet. Despite listed limitations, we hopeto completely overcome them in our future work.Certainly, the in-depth evaluation of such project shouldinclude much more aspects than listed. Meanwhile, at thepresent stage of developing we are concentrated mostly oncreating simulation which should be close to the originalsound of NM2.
7. CONCLUSIONS AND FUTURE WORK
At its present state, the pch2csd project is ready for furtherdevelopment by international computer music enthusiasts.The core has been test to work on Windows and OSX sys-tems. The user is able to open Clavia’s patch file formatpch2. The conversion log shows status of all dependen-cies, i.e. Csound UDOs, mapping tables, etc. It allows userto update the dependencies and also create his or her ownversions of UDOs and mappings if needed. The modulecompletion status is far from uniform. Most of straight-forward modules are finished, i.e. mixing operations orswitching. Random section seems most difficult, becauseof its ambiguous behavior. The same should be reportedon FX section, although the actual quality of the reverb orchorus modules does not correlate with algorithmic patchbehavior, which makes it not so critical.Another important goal we started working on recentlyis to make the project hackable, so users would be able toeasily modify module implementations to contribute to theproject or to modify sound for their own tastes. The plaintext modules and mapping tables were made as well as forthat purpose, but the user experience here is still poor. Asa first step to mitigate this we plan to develop a simpleElectron-based UI with an embedded text editor in thenear future.Our next to-do after providing a completely working so-lution is an integration with some existing Clavia patch edi-tor. It will actually establish the new Clavia-based softwaremodular system running on a Csound core. Also, the nativeCsound developments, i.e. Cabbage Studio (a graphicalUI for Csound build by Rory Walsh) seem very promisingin the context of further integration.Current tool sources can be found on the GitHub : https://github.com/gleb812/pch2csd . Acknowledgments
This work has been partially financially supported by theGovernment of the Russian Federation, Grant
8. REFERENCES [1] R. Walsh, “Csound and unity3d,” in
Proceed-ings of the Third International Csound Confer-ence . St. Petersburg, Russia: The Bonch-BruevichSt. Petersburg State University of Telecommunica-tions, Mar. 2016, pp. 141–155. [Online]. Available:https://doi.org/10.5281/zenodo.50369[2] G. G. Rogozinsky and M. Chesnokov, “Clavia nordmodular g2 patch converter project,” in
Proceed-ings of the Third International Csound Confer-ence . St. Petersburg, Russia: The Bonch-BruevichSt. Petersburg State University of Telecommunica- URL: https://electron.atom.io/ URL: https://csound.github.io/frontends.html The code, as well as sound examples, mentioned in the previous sec-tion, are also preserved at Zenodo, URL: https://zenodo.org/record/581204
Proceedings of the Sound and
Music
Computing
Conference,
June
Espoo,
Finland
SMC2017-419
The Csound book: perspectives insoftware synthesis, sound design, signal processing,and programming
Proceedings of the Third International Csound Con-ference , G. G. Rogozinsky, Ed. The Bonch-BruevichSt. Petersburg State University of Telecommuni-cations, 2016, pp. 132–140. [Online]. Available:http://dx.doi.org/10.5281/zenodo.50364[8] E. Giordani and A. Petrolati, “Csound synthesisapproach for the ivcs3 ios app,” in
Proceed-ings of the Third International Csound Confer-ence
Csound - A Sound andMusic Computing System . Springer InternationalPublishing, 2016, DOI: 10.1007/978-3-319-45370-5.[Online]. Available: http://link.springer.com/10.1007/978-3-319-45370-5
Appendix: NMG2 binary patch format
Field name Value / Comment BitsHeader byte 0x69 8Length 0x4a 16
Unknown
Table 1. Mystery object Field name Value / Comment BitsHeader byte 0x52 8Location 0 / 1: FX / Voice 2Unknown - 14Cable count Nr. of cables in the area 8
Then, for each cable according to cable count:
Color 0-6 3Module from 8Jack from - 6Type 0: in-to-in, 1: out-to-in 1Module to - 8Jack to - 6
End of iteration
Table 2. Cable list binary encodingField name Value / Comment BitsHeader byte 0x21 8Length - 16Unknown - 12Voice Count - 5Height of FX/VA bar - 14Unknown - 3Red cable visibility 0: off, 1: on 1Blue cable visibility 0: off, 1: on 1Yellow cable visibility 0: off, 1: on 1Orange cable visibility 0: off, 1: on 1Green cable visibility 0: off, 1: on 1Purple cable visibility 0: off, 1: on 1White cable visibility 0: off, 1: on 1Mono/Poly - 2Active variation 0-7 8Category 0: No Cat, 1: Acoustic,2: Sequencer, 3: Bass,4: Classic, 5: Drum,6: Fantasy, 7: FX,8: Lead, 9: Organ,10: Pad, 11: Piano,12: Synth, 13: Audio In,14: User 1, 15: User 2 8Padding -Table 3. Patch description binary encoding
Proceedings of the Sound and
Music
Computing
Conference,
June
Espoo,
Finland
SMC2017-420 ield name Value / Comment BitsHeader byte 0x4a 8Location 0: FX Area,1: Voice Area 2Module Count Nr. of modules in the area 8
Then, for each module according to module count:
Module type 8Module index Module ID 8Horiz. position - 7Vert. position - 7Color - 8Appendix - 4
If Appendix != 0:
Unknown - 2Hidden parameter - 4
End of iteration
Padding -Table 4. Module list binary encodingField name Value / Comment BitsHeader byte 0x52 8Length 16Location 0 / 1: FX / Voice 2Module count - 8
For each module:
Module index - 8Param. count Nr. of parameters 8
For each parameter:
Variation 0 8Value 7-bit MIDI value 7Variation 1 8 . . .
Variation 8 8Value 7-bit MIDI value 7
End of both iterations
Padding 8 8Table 5. Module parameters binary encoding
Proceedings of the Sound and
Music
Computing
Conference,
June
Espoo,