ENSOF

From Hebrew:

in·fi·nite adjective1. immeasurably great:2. indefinitely or exceedingly great:3. unlimited or unmeasurable in extent of space, duration of time, etc.:4. unbounded or unlimited; boundless; endless:

Tom Srugo (frostrugo@gmail.com)Mentor: Lex van den BroekDepartment of Sonology (& EWP)Royal Conservatory of The HagueBA4 2012

Contents

1. Abstract...................................................................................................32. Motivations.............................................................................................4 2.1 The Resolution Problem................................................................4 2.2 The Preset Recall Problem............................................................5 2.3 Notable Devices............................................................................53. Features..................................................................................................7 3.1 Targets...........................................................................................7 3.2 ENSOF Features...........................................................................74. Engineering............................................................................................9 4.1 Implementation Problems and Solutions......................................9 4.2 Design..........................................................................................10 4.3 Unexpected Problems..................................................................12 4.4 Software.......................................................................................155. Conclusion............................................................................................176. Acknowledgments................................................................................18

Appendixes.............................................................................................19I. EAGLE files............................................................................20

1. PCB Schematics..................................................................202. PCB Boards.........................................................................223. Other Schematics................................................................24

II. Front Panel Cover Design......................................................25 III. Max/MSP Patches...................................................................26 IV. ENSOF Pictures......................................................................32

Abstract This report will describe the motivations, features, design and engineering process of building ENSOF, a custom made hi-resolution hardware remote controller in OSC (Open Sound Control) protocol through ethernet (UDP), which was made originally for studio production and live performance of audio synthesis control within Max/MSP and Ableton's Max for Live softwares. The device can also be used as a remote controller in a vast amount of many other fields, inc. stage decoration and set control, lightning, Public Address (PA) systems, Mixing (Live, Studio and DJ's), Installations, Robotics and almost anything that requires human control with buttons, knobs and sliders interface. At first, the motivations for the project will be presented, following a brief review of some present available models on the market that offer some of the features that ENSOF has to offer, with their cons, as well as some other custom controllers that inspired this project. Then I will tell about the features and concept of ENSOF. Chapter 4 will describe in detail the building process, including the design, electronics engineering process, encountered problems and solutions and will end with a description of the software application for the device. The report will end with a conclusion and appendixes containing descriptive pictures of the building process, internal parts, PCB design, MaxMSP patches and of course the ENSOF in action.

Motivations2.1 The Resolution Problem

2.1.1 MIDI

The main protocol for commercial hardware electronic music control in the market is still the old fashioned 80's MIDI protocol, which was a very clever and useful protocol at that time, but misses a very important feature for "good" or "acoustic-like" expressive musical control. Even that today its possible to transport MIDI over USB or any other hardware, solving most of the speed problems, still the main problem in controlling musical instruments by MIDI is data type resolution, meaning, that the A/D conversion of each sensor/UI element is translated into 7-bit information e.g. resolution of 128 steps for every sensor full range. This is not a problem in triggering and switching messages such as drums triggers or piano pitch notes, but when it comes to velocity dynamics or continuous sensor information, it is basically impossible to have natural musical expression when playing as it is with analog playing - acoustic and electronic. I believe that one of the main reasons many people praise the analog synthesizers over the plug-ins one's, is just because of the ability to have a smooth continuous control over the parameters, which is impossible with almost all of the controllers in the market. This could be solved until few years ago, only by edited automations in the DAW, but never in live performance with hardware control. Many applications require parameter ranges of way more then the MIDI's 128 steps, just as an example, the frequency of a continuous glissandi note or of filter cutoff, can range from ~40-16k Hz, meaning that controlling such a parameter with a normal MIDI controller will map ~16,000 values into 128 values (human ear can notice a few cent's frequency change). This will end up jumping in steps rather then moving smoothly. Trying to fix the problem software-wise by interpolating the incoming values, still keeps the limit of the target values positions. This will give many musical parameters a digital, quantized, unnatural feeling. Other solutions are possible, such as 14-bit MIDI, using 2 7-bit bytes for each element (such as in the pitch-bend control), SysEx messages, and the sending of relative MIDI messages (up or down) for each controller movement gesture. Those solutions should be implemented in the hardware, but since they carry the need for a dedicated software for mapping the values back to a protocol that the plug-in host software can understand, and most hosts only support MIDI and don't support decimal MIDI, it makes the whole idea very tangled and problematic, especially not profitable for commercial distribution. Electronic music control industry is definitely stuck in the past just to satisfy the average user that wish to plug-and-play with no programming, no manuals, no thinking.

2.1.2 OSC

OSC or Open Sound Control, was the answer to all electronic music musicians who wished for a better, more flexible and with higher resolution data type protocol. OSC is a content messaging format developed at CNMAT (Center for New Music and Audio Technology), Berkeley, which is commonly transported over Ethernet UDP/IP. With 32-bit data types, it is now possible to overcome the MIDI resolution problem, and with the name/value pair messages it is very flexible and easy to program and rout controller parameters. Since it is so flexible, and any symbolic path could be chosen to any parameter, and since there is no standard parameter matching list such as in MIDI, causing the need to map controller signals individually to every device (synth, sequencer, plug-in etc..), in addition with the need of minimal networking knowledge, made OSC way less user-friendly then MIDI, causing in fact, that to this day, no commercial OSC hardware controller for live performance is available. OSC is only used in custom made hardware designs in the live performance scene. With the recent popularity of wireless touch-screens mobile phones and tablets, OSC became more known and popular for its wireless networking property to control musical events, but even then, resolution is limited to the pixel dimension of a GUI element (1024 max. in iPad2). Better then MIDI, but still limits expressiveness.

Personally speaking, when I play music, I want to feel and interact with the sensor, also without having to look at it constantly in order not to "miss" the "target" element sensor. There is no 2D replacement to the feel of turning a knob, as well pressure information is not really possible. This is why I didn't choose a tablet as a controller, you overcome some problems in the price of 1 dimension less, and 3 are not so much anyway!

2.2 The Preset Recall Problem

An extremely useful feature which is embedded mainly in Control Surface Mixers, as well in a few MIDI controllers for live performance, is the ability to save and recall presets. With preset recall feature, it is possible to control every software parameter in a set-up with a single UI element (slider, dial etc.) during a performance, and therefore, a single interface with a small amount of elements, could control many parameters of many instruments within a complex set-up, in many cases this compact solution is preferred over a clumsy set up that includes many small controllers or a very large one. This solution is also usually cheaper. The recall feature of-course, requires that the controller be able to sync the states of the parameters, which is done usually by receiving the information from the computer, through another MIDI port. This requires as well that the UI is able to feedback (display) changes from one parameter state to another, this is commonly done for buttons by a single LED next to or on a tactile buttons (on/off or different colors for different states), engined sliders and endless rotation analog potentiometers or rotary encoders, together with circular led display around them to display the parameters states.

2.3 Notable Devices

2.3.1 Devices that Solves (or try to) the Mentioned Issues

– Nord Stage 2 by Clavia. Performance keyboard synthesizer, has internal high resolution like almost any digital synth model that respect itself, and is not a controller, but the reason I bring it is since it has 8 endless rotation knobs with 16 LED's display per knob. I think this was the first synth with preset recall, that included endless rotation knobs with display instead of the annoying "catch/snap" feature (in most normal potentiometer synths, changing preset forces the user to snap the knob/slider to the preset value position in order for the control to start), the Nord Stage 2 has also the cool feature of interpolating between 2 presets (by Modulation wheel or After Touch).

– D-Command by ICON. Digital console for Pro-Tools, has a very high resolution control (internal protocol), motorized faders and endless rotation potentiometers with circular LED display for preset recall. Extremely flexible for customize studio workflow, but is specified and compatible with Digidesign systems in Pro-Tools only, and is a (big) console, therefore not suitable for live performance. Price around $60,000 for 16 channel model.

– Akai APC line. features endless rotation potentiometers with LED rings display and buttons with three color LED's inside them. Faders are not motorized, and it is a MIDI controller after all.

– Behringer BCF2000/BCR2000. MIDI controller with motorized faders and endless rotation knobs with LED rings. Knobs features the choice to send each element as 14-bit MIDI, or sending relative MIDI messages (+/-) as well as choosing minimum and maximum value per element. The problems are that the faders have relatively slow reaction and are terribly noisy. The other issue is that even that it is possible to have over 16,000 values per knob, it

is still limited to 128 values per revolution, so to cover 16,000 Hz with 1 Hz resolution will take 120 knob revolutions. Not so practical in most music genres.

2.3.2 Inspiration

Some other controllers which inspired me, except for the above mentioned, are:

– “The Stribe” by Josh Boughey. 8 position sensors slider box controller. LED bars display. OSC protocol. Arduino/Wiring based. This project helped me a lot making design decisions for how to display the controller feedback (MAX7219 IC), as well for which position sensor model to use (Spectrasymbol Softpot). Josh was also kind to advise me about how to eliminate fluctuations when the sensor is open (ground it!).

– Buchla's Thunder (1990). MIDI controller by Don Buchela, which consisted of multi-touch position and pressure arrays, designed to the shape of user's 2 hands on. Design was copied to the present Buchla 200e series tactile controller.

– AKAI MPD for its force sensor pads. Found this feature extremely useful and musically expressive, can function as a toggle or tactile button or as a continuous controller, so I decided to add FSR's (Force Sensor Resistors) to the ENSOF thanks to this device.

– SLABS designed by David Wessel and Matthew Wright at CNMAT. Is an OSC 24 or 32 pad array with x/y/z (track pad with pressure) sensors. Even that it is not similar to the ENSOF, I did have in mind adding x/y/z pads to the ENSOF, but this idea was eventually abandoned. Yet I was still highly impressed and inspired by this controller.

Features3.1 Targets

The main idea was to build a device, that will allow to control and play live electronic music without having to use the mouse, keyboard or even looking at the screen. I find it way more attractive, easy and fun, to play music by mostly listening to it, and interaction with audience can also be pushed forward. Therefore the device needed to be compact, covered completely by 2 hands, and still to cover up the controlling options of a complicated set-up, with fast ease of use, which is done by recalling presets of different parameter targets layouts, using buttons on the device. A display to tell the user on which layout he is currently playing is needed, to avoid completely the computer screen.Regarding the above mentioned disadvantages of most as all commercial MIDI controllers, a custom OSC controller was designed, to include a sufficient sensor resolution for standard finger controlled sensors (knobs, sliders, FSR) as well a visual feedback of all sensors in order to be able to recall presets via software, and to include enough buttons in order to move between controller layouts, as well as triggering events (samples, notes, automations) and changing sound presets (synths presets, effects presets) as opposed to layout preset, which only change the controller elements parameter targets, without effecting the parameters current values and without changing the sound.To make performance more attractive for both performer and audience, high-power LED's were added on the devise, software controlled, for strobing and coloring the user's face while playing, this lighting can be automated by the musical content, to help performer "feel" the music better (BPM strobing for example).

3.2 ENSOF Features

The hardware features of the ENSOF are:

- 5 Vertical position sensors ("Ribbon Controller") in 12-Bit resolution (4096 values) with x2 40 LED display- 1 Horizontal position sensors in 12-Bit resolution (4096 values) with x2 40 LED display- 15 Endless rotation potentiometers in ca. 13-Bit resolution (2 wipers per pot = double resolution) with 21 LED ring display- 64 Illuminated tactile buttons- 6 Force sensors in 12-Bit resolution (4096 values)- 2 Alphanumeric 17-SEG LED digits display- RGBW Hi power LED (Xlamp by Cree)- 2 White Hi power LED's- 2 Blue Hi power LED's- 1 Red Hi power LED- 1 Green Hi power LED- 1 UV Hi power LED- 4 CV 5V Input (1/4'')

Some expressive features I noticed after building the device which are not possible with normal fader pots are, since it is using position sensor:

- Possibility to jump from value to value.- Range Select (With easy software programming its possible to determine the min/max value when position sensor is pressed and release. Extremely useful!)- Using 2 or more fingers on the position sensor change the value by both fingers position and pressure. Adds another controller playing technique not found anywhere else!

Engineering4.1 Implementation Problems and Solutions

My starting point for the this project was a short course about micro-controllers in the Royal Conservatory of the Hague around Nov-Dec 2010 by Lex van Den Broek and Edwin van der Heide. The only knowledge I had then about electronics was from introductory course I took the same year in the conservatory by Jan Panis.

Giving all the above mentioned motivations, I began to look for implementations for my "Dream Controller". The 3 main subjects I had to deal with first where:- Finding the micro-controller/s to deal with all I/O- Sensors that will overtake the above mentioned problems in the musical controllers industry- Display solutions

4.1.1 Micro-Controller

For the micro-controller part, it was suggested to construct a dedicated PIC chip based circuit to deal with the big amounts of I/O, together with "Lantronix" XPort, for going from serial to ethernet, as found in the IpSon micro-controllers (www.ipson.nl). Luckily just at the time of designing my device, the IpSon64 came out, with 64 analog inputs (0V-5V), and it was decided to use 2 of those, to save time and work, for a total of 128 analog inputs, and to design a separate PIC circuit to handle the LED display's outputs. The output data is converted to serial RS-232 from the ethernet connection by one of the IpSon64 XPort part into the separate PIC display circuit.

4.1.2 Input

It was very clear to me from the start that the best way to recall presets are to use position sensors and endless rotation knobs with some kind of display, but had no clue what are the best (and most economic) components that should be used. Since I had to deal with analog signal inputs for the sensors, for the endless rotation potentiometers, rotary encoders where not an option. Even if I could use digital input, I wouldn't have used encoders, since they come in a very limited number of steps per revolution for the types to be used with hand knobs (16-64 PPR), making it useless for my needs. Any encoders with higher resolutions are priced over $100 per encoder, so the answer was not there. My idea was to use a kind of differentiating potentiometer, or small dynamo, that will output higher voltage with higher turning velocity, and then integrating this input back software wise to get the values of the endless rotation. I found a device like that exists indeed, and is called Rotary Variable Differential Transformer (RVDT) and is a transformer used for measuring the angular displacement of its shaft. RVDTs are not really used with knobs for turning them with the hands, output AC, and their price range start more then I expected. This option was way too messy to deal with. Since my AKAI MPD24 has 8 endless potentiometer with analog pot feel and 128 step resolution this couldn't have been an encoder. I guessed the component Im looking for is somewhere around, and is very cheap, but I just couldn't find it, and everybody I asked told me to use encoders. I decided to open my MPD, and it was indeed a simple looking analog pot. After exhaustive search around the web, I found out it was a simple double wiper endless potentiometer (aka sine-cosine pots), where the "dead range" of one wiper is covered by the other, and with using the 2 wiper inputs, it is possible to determine the exact shaft position. As simple and useful as it sounds, this kind of potentiometers are very hard to find in small amounts, so eventually I ended up buying this component from an AKAI MPD spare part seller.

“Softpot” position sensors by "Spectrasymbol" are used, they claim they are linear, but this is just a lie, its completely logarithmic, and this was solved eventually in the software.

For the buttons, "OMRON" Illuminated tactile switches where used, using a whole IpSon64 board 64 inputs, for on/off switching (even that this sounds like a "waste" of all the resolution, it was the easiest, time-money-effort wise solution). With Tactile buttons is then possible software wise to choose if it should function as momentary switch or as toggle, as well as a selector between multiple buttons, and to change each button function or state in different layouts.

For fingers pressure playing, "Interlink" FSR-400 force sensor is used.

4.1.3 Output

Regarding the display, it took me a while to find a solution, since I was thinking too much "analog-minded" I was trying to find solutions for analog voltage outputs for the display, also thinking of a way to get the best resolution display. Some ways I had had in mind where using VU meters, or bar voltage meter. Later I was considering the LM3914 IC ("National Semiconductor"), that can drive up to 10 LED's with analog voltage input. All those solutions where not practical for my application, some where too expensive, or had no illumination, and some had poor resolution. At the time I was struggling for displaying solution, I was introduced to "The Stribe" controller, made by Josh Boughey in 2007, which is a MIDI/OSC position sensors controller on transparent acrylic, with LED bar's display beneath them, his website in very documents, and he was also very kind to help me in some technical problems. It was then decided to base all the display output data, as it is in "The Stribe", on the MAXIM MAX7219 IC, which is a serial input/output common cathode 7-SEG X 8 digits LED driver, and can be used to driver up to 64 individual LED's as well as being daisy chained for more LED's. 12 MAX7219 IC's where needed for a total of 768 LED's possible, 681 out of are used. Daisy chaining all the IC's (sending very long string) was not so efficient, and eventually a PIC based circuit was build by Lex to split the serial OSC string to 12 single IC's, for better speed and stability.

4.2 Design

Design of the device was made with the following considerations:- Size and shape of the device was suppose to be convenient for 1 to 2 hands finger playing, with trying to fit the shape for maximum amount of simultaneously playing fingers. Also light weighted and compact for traveling.- Economy e.g. the pricing of the whole project, although it was not fixed from the beginning, was expected to be around €700.- Time. I was expecting 4-6 months when I started the design, after not so long I became more realistic regarding my demands and was expecting to finish in 10 months.- Labor. This goes together with time, and regarding the fact it was my first electronics project, I preferred to pay more, in order to work less, and to reduce possibility of any errors in the working process, and to save time.

In order to get the best practical finger control, it was decided as basic design rule to make the device compact and clear to use. I decided my favorite controlling method for multi purpose control (live/studio mixing, synth playing, processes control…) would be a simple straightforward mixer-like layout, divided into similar channels one next to each other, each of them consisting of 3 knobs at the top level, a slider below, 2 buttons at the bottom, and 8 buttons at the side of each slider, divided into 2 groups of 4 buttons. I imagined this way I could have enormous amount of freedom and ease of playing and switching sensor targets in no time per each finger individually. I found 4 sliders of 10cm to be a limit for 1 hand simultaneous sliders playing, (Thumb and pinky playing sliders together limit fingers flexibility considerably!) and together with some consideration for the amount of control target parameters per layout, that will stay clear and possible to memorize for the

user, 5 channels seemed as best choice, having 4 channels attached with distances small enough for (My) 4 fingers simultaneous control, and 1 channel separated, to act as multi purpose "Master Channel", and 15 knobs, 3 of them above the "master" separated from the others. Horizontal slider beneath the 4 channels was designed, to function as "Crossfader" making the device fit also for DJ's software control. 5 force sensors where designed to fit a complete hand simultaneous control (5 simultaneous fingers is possible in pressure control with some practice) 3 in the bottom spaces between the 4 channels just above the "crossfader" and another 2 from its 2 sides. Another force sensor was added sometime in the working process with no reason (Had free space and free inputs so why not…?!). Between the "master channel" and the 4 "hand channels" I made space for adding more buttons, and 2 digits alphabetic display, since I had some free space and free outputs in this space, High power LED's where added in the working process. It is therefore possible at maximum to control 9 parameters simultaneously, using first hand's 4 finger on 4 sliders, and 5 force sensors with the second hand. I did developed, unexpectedly, a technique for playing all 10 fingers using the thumb from the sliders hand to control the "crossfader".

Regarding the above mentioned design, a distance not greater then 3.5cm had to follow between each 2 sliders (2cm wide) out of the attached 4, together with good resolution for the LED's display (40 2.5mm LED's X 2 (from both sides) for each 10cm slider, and 21 LED's for the knobs ring), and considering the fact that the knobs had to be exactly above the sliders, and that buttons were 1x1cm, it was pretty obvious that at least a 2-layer PCB most be designed to get the designed size with all the LED's traces. Modular approach was taken, for pricing reasons, as well as a better way to track malfunctioning (which I got very often…) and in general for a much organized and easy working flow.2 PCB's were designed using "CadSoft EAGLE", one for the slider/buttons part (bottom channel), and second for 3 knobs (upper channel), mainly to have the "crossfader" horizontal slider possible, since if I had a whole channel of knobs with slider, I had to design and produce 1 "half board" only for the slider part and that was not economic. It was also better for my working flow and more safe, to design the slider/button part, and to see it works (since it was my first PCB design), then to leave the knobs part for later.Calculating the overall sizes, design of the slider/buttons PCB was ca. 15x3.5cm, with hundreds of traces for 10 buttons switch's with illumination, 90 LED's into the MAX7219 driver 8-SEG x 8-DIG matrix (40 LED's are mirrored) together with voltage and data traces, was not an easy job. The knob circuit was even more tricky, because of the ring shape of the LED's (See Appendix for Eagle board and scheme design). Regarding the above, only 2mm diameter screw holes were possible, this caused a huge problem in the assembly phase, which will be described later in detail.

Regarding the rather high costs of a single PCB, for the circuit of the buttons, alphabet digits and high power LED's, 2 perforated prototype boards circuits where made by hand to cut costs.

Taking into account the modular design, and all the interconnection between the modules, together with the obvious possibility that things wont woks as expected, and that modules would be connected and disconnected many times, flat-cables with male/female connectors were used for interconnection. Even that the conductance of the flat-cable with the connector was getting loosed after many plugging, the time benefit from using those connectors in comparison with soldering was countless. The connectors where also extremely helpful in the final assembly of all the modules together, where so much mess of wires was inside the compact device volume, that sticking a soldering iron inside would have caused more harm then good.

For keeping the compact size of the device also in the hight dimension, together with its panel size, a special care had to be taken in the positioning of the modules, against the other circuits (2 IpSon64, PIC display-controller) beneath them, considering especially the high connectors, and of-course, the screws.

The device was built to work with +9V DC, since that is the operating voltage for the IpSon micro-

controllers. All modules needed +5V DC for operating the MAX7219 IC's and the sensors (position, force, switches), therefor x4 LM340 5V regulators where used, on the PIC display-controller board, to split and regulate the voltage supply input between all the modules, for better stability.

High Power LED's can not be powered using the MAX7219 driver power. Therefore, darlington transistors function as a transistor switch per LED, directly connected to the 9V power supply with the MAX7219 on the base as the control voltage.

2 IpSon64 were used, one for all button switches inputs (64 in total), and for the display output string ethernet-to-serial conversion (which goes to the PIC LED's drivers divider circuit), and one for all sensors inputs (6 position + 6 force + 15x2 double wiper pot's = 42 in total), each of them having its own IP address and port, and are "merged" into single ethernet cable using external ethernet switch, or a router for wireless communication with the computer (wireless communication is slower).

Unfortunately, since 2 IpSon64 were used, 2 ethernet connection where needed, and in order to merge them both into 1 ethernet socket, a switch or router is needed. Considering that, a lot of effort was put seeking a switch small enough to fit in beneath the layout of the control panel, with no success. The tiniest switch I found would have made the device at least twice as high, and considering the fact that 2mm screws at such hight do not exist in the market, this could have brought me into a long lasting design problem with assembling everything together. It was them decided to have 2 ethernet sockets on the device, as a default choice, for the sake of a much more compact device, and for (possible) quicker and cheaper assembly process.

All modules and controller boards where assembled together and mounted on 1.5mm aluminum board. (The IpSon micro-controllers family are also mounted on aluminum boards in this way, but in ENSOF case the 2 IpSon64 where mounted straight to the device's aluminum board, to minimize hight).

A Front-Panel was must needed, in order to stick the position sensors above the LED bars, and a full cover front-panel was designed using "Adobe Illustrator" and was laser cut on 2mm transparent acrylic (Plexiglass).Rubber knobs (white, and 3 black for "master channel") were put on the potentiometers. (** up to now, 7 knobs are still on backorder)

Having still 22 free input, and some little space left at one of the corners, I am planning on adding still a few CV jack (1/4") inputs, for any desired sensor or CV external module. (Mainly for my PAiA Theremax Theremin CV outputs).

The resulting size of ENSOF is 220x310x37mm (WxLxH), and has 2 ethernet connections on its right panel with 2 reset buttons for the IpSon's, and 5.5mm diameter 9V DC power plug socket with a switch at the back panel.

4.3 Unexpected (But Expected…) Problems

Here I shall describe some of the technical troubles I got into during the working process.

- The first major trouble I recall was that some slider/buttons modules were working for several seconds and then "crashing" or not even turning on, and going extremely hot after. After hours of frustration with no clue what was wrong, I noticed the problem occurred only on the green LED bar's modules, together with an "accident", where 16 LED's trace was cut by mistake, causing the module to work properly, I realized that the MAX7219 was taking too much current due to the

green LED's, making it "crash" and go crazy. Changing the current-setting-resistor to a higher value (Rset) seemed to solve the problem.

- The PCB design for the knobs modules was done in only 2 days, under terrible rush to finish and stand my time schedule, which caused mistakes in the design that brought with it hours over hours of fixing the accumulated problems. First, all the anode-cathode marks on the PCB were inverted by mistake, causing me to solder 2 modules with 63 LED's each wrong. The modules where still working, but negative and strangely. Since I had only 1 spare PCB of those, I had to de-solder completely 1 PCB, during which this exhausting process I slipped and cut many tracing connections, which I had to later track and manually connect back. Second, 4 connection were wrong on the PCB, forcing me to cut and manually reconnect them correctly on each of those PCB.

- When the position sensors were not pressed, they gave some continuous wiggles and peaks around 150 (out of 4096) which caused the last tracked pressed value (in software) to get lost and be pulled down. This was fixed by adding 10K resistors between sensor signal and ground, pulling down the sensor to ground when open (not pressed). This solved the keeping-last-pressed-value problem in the software.

- After many designing efforts, the hight between the aluminum base and PCB's was minimized to 30mm. Which introduced me to a very unexpected problem, since all PCB's screw holes where 2mm in diameter, I had to find M2 x 30mm screws, and those screws, longer then 25mm are extremely rare and almost impossible to get. After weeks (!) of searching and asking, I found a model shop in Amsterdam that sells them (thanks to Paul from EWP), and was waiting for almost 2 months until they got them, having to pay around €40 for minimum amount. Having all modules working and ready to be mounted after 8 months of daily labor, yet still laying on the table apart for few weeks just because of some rare screws was the most irritating part of this project.

- Designing the plexiglass panel, didn't take into account some small deviations in the mounting of the modules onto the aluminum board, making it "almost" fit, and having to optimize the design and make a 2nd one, which is better at the moment, except for a crack I made on it, and 1 button that misfits and is being pressed by the panel (sill after long hand filing to make it fit at all). Therefor a 3rd panel is planed to fit perfectly in near future. (Every panel cutting is around €60…)

- The Alphanumeric 17-seg display. I think I spent more then (the last) 2 weeks only to make it (almost) work. The problem was, the MAX7219 IC is common cathode, and the 2 alphanumeric components I had were common anode, with 1 anode pin and 17 LED segments pins, this was then impossible to operate even in a common cathode LED display, since the MAX7219 is working on 8x8 matrix, where maximum of 8 LED segments is possible per each common cathode (Digit). I had to make a circuit board by hand for switching 34 LED's for 2 alphanumeric digits using the MAX7219 common cathodes (Digits pins) as the Quad Switches ground, and the anodes (Segments pins) as gate control, this was the only way to group them, and this whole circuit board had to fit inside the (already finished) device, in between all the screws and mess of wires. The most compact and flexible way I found was to use 9 HEF4066b Analog Quad Switch, and I was very lucky to find a wide rectangular area beneath the knobs modules where I could place this switching board, it didn't work, and after some playing around I figured out that if the switching board turns on together with the MAX7219 driver, it doesn't function. If I turn it on after the driver, it worked good. To this moment, I have no clue why. So luckily I had some bit more space on the board for a relay, and together with LM555 timer I made a circuit to power the switches few milliseconds after the device turns on, just then, and after routing and soldering all the switches, I was terrified to figure out that thanks to the mess off connections on the bottom of the switching board, it was too high in 1-2mm that the knob modules above it could not be attached to the (already highest possible) screws they mounted to. I had no choice but to disconnect everything, and start all over, with the smalls wires I found, by cutting apart single wires off my flat cable. After completing this, and connecting all the modules (including nuts), I was amazed to see that the alphanumeric digits

go crazy and respond as if the switches were shortcutting some LED pairs together. I thought the small pressure that was still on the board from fixing the modules with the nuts made a shortcut between the wires. I took it out, and back few times, after not finding the problem, blaming the "crosstalk" all the time, I decided to disconnect the switching circuit again, and connect it LED by LED, until I find the problem. I then realized, that from some reason, using more then 3 MAX7219 Digits (common cathodes) as the HEF4066b grounds, something is going wrong. No matter what I did, it worked great with 3 common cathodes times 8 LED's to a maximum of 24 LED's. Adding another MAX7219 "Digit" to the switching circuit, was shortcutting things only on those "Digits" (on the alphanumeric LED's, other LED's with the same IC worked OK), I guess it must be something in relation with the turning on problem. Not wishing to spend another 2 weeks like those (which were the worst in a period of a year) on a small feature as that, I decided its time to finish the project, and compromised on 1 full functioning alphanumeric digit, and another one with only 7 LED segments function for numbers display only (adding the fact that anyway I burnt 1 of its LED's).

- The previous problem apparently did effect the other LED's connected with the same MAX7219 as the switching board, and from another (probably related) unknown reason, small amount of current is constantly leaking to all LED's, most noticeable on the red ones. I guess it all has to do with the fast current switching of the MAX7219, together with sinking external current from the HEF quad switches. But I had no cheap, quick way to get over it at this last phase. Therefore I compromised again and left it like that.

- The MAX/MSP patch was reacting slow from beginning, CPU load was over 85% constantly (both cores), and MAX was crashing every time while more then 2 force sensors where used simultaneously. Apparently it couldn't handle the high amounts of data (printing many "dropped strings" messages). Using MAX "speedilm" object, to limit the incoming data flow, passing in incoming UDP messages "only" every 10ms and ignoring the rest, reduced CPU load to around 40%, solved the crossings completely and no strings were dropped.

- Power Consumption. The devices sensor input were reacting strangely as more LED's where turned on simultaneously. At first some inputs wiggled a bit, when more LED's turned on, all inputs started to wiggles, and going completely crazy and outputting crosstalk-like noise when even further LED's where on. As usual I blamed the crosstalk due to the all the MAX7219 IC's fast switching. It was then all clear, when Lex checked the power consumption of the device. The device consume more then 0.8A when all LED's are off (!) and demanding over 3.5A when most LED's are on. Since I was using a home use 1500mA transformer, the voltage was dropping as more LED's were turned on, it was then obvious why the device was malfunctioning on higher current states. Using a 4A (!) transformer improved the input wiggles considerably.

- Some fluctuating wiggles are still occurring, especially in the most left knobs module, and giving the fact it determines knobs value by differentiation, the irregular wiggles causes the value to move randomly up and down, and not just fluctuating around fixed value. This problem was solved on the other knobs by averaging, and opening a gate only when the differences in values is higher then a certain threshold, making sure its human intended movement. But in the mentioned module, the irregularity is rather big, and is increasing with more LED's turned on. After blaming the innocent crosstalk so many times during this project, I would be careful to blame it again, even that I cant think of any other reason for this behavior. I believe moving the mentioned module IpSon inputs to different inputs (more then 20 free), might solve the problem, proving it was probably a crosstalk in that area. - The last biggest problem at the moment is, that the device literally crashes rarely, when too much LED's on certain modules are turned on simultaneously. First those modules MAX7219 LED driver crash and heat up terribly, showing unexpected LED's display, and after a while taking down the whole device with it, and some time is needed for the device to cool down, or it will crash on every

power on. Since the behavior of the individual modules before it all crash, including the heat-up, is very similar to the current limiting problem I had with the green LED's modules at the beginning, I assume its the same problem, just that when all modules are connected together, they behave differently then they did individually and stable. I therefor assume limiting the current further down with higher Rset values, should solve this problem in near future. In the meanwhile I use only single point display on the problematic modules rather then full metering to avoid any malfunctions while playing.

Looking back I could definitely say, I spent way much more time and effort on fixing errors (which I usually made myself in the first place) than on the pure design and construction of the device itself, as well as some considerable amounts of money for all those parts I burnt and broke, or the spare parts I never used or the ones that didn't fit eventually.

4.4 Software

During all construction, testing and actual implementation, I used Cycling '74 Max/MSP (v5 and then v6), and Max for Live (M4L), for all the OSC data flow, input as well as output for display, using udpreceive and udpsend objects.With some binary calculations, it was possible to have individual LED control on the modules, and eventually a patch mirroring the device function was programmed, to match the current sensors input value with the matching display with the correct value in real time, for real time playing display feedback.As was mentioned, after grounding the position sensor when open, it was possible to remember the last pressed value, before the value was pulled to ground. In this way it was also very easy to capture the first value when slider is pressed, making the Range feature possible (see 3.2). Position sensors values are converted from logarithmical to linear, this gives less resolution as going up the sensor, but with 4096 value, I find it negligible.Knobs values are calculated by relative change, and different resolution (Steps Per Revolution) can be determined per knob. Irregularities where fixed by averaging and detecting directional intended control movements. (see 4.3)User can switch between full meter or single point display per slider or knob (Range display also possible for sliders).It it also possible to connect the force sensors with their above nearest sliders LED bars, for pressure feedback instead of position sensor display.The Power LED's can be controlled by any control signal, making it easy with little extra programming, for example, to react to the music's threshold level, or just to match selected channel/s to individual LED's (For instance: Blue LED strobe with the bass drum while white LED strobe with the hi-hats, green LED strobe by Synth LFO1 etc.). This helps feeling the music for the performer, while also visually pleasing for audience.

After optimizing the data flow speed, CPU is ranging from around 45%-65% in normal control conditions. When 10 continuous sensors are played simultaneously (maximum possible with 2 hands), CPU load does not exceed 85%.

Thanks to last versions of M4L, together with Ableton Live's API in Max, it is extremely easy to target any MAX floating values or MSP signals, to any parameter in any plug-in in the session, as well the ability to control almost any function in the software itself (Tempo change, Play, Stop, Solo/Mute channels, Panning, Launch Clips etc.)therefore, M4L patch was programmed, where each sensor could target, using menu selection, any parameter in any channel anywhere in the session. Every sensor target is featured with: Minimum and Maximum offset and Jitter amount that can be determined, as well as Curve reaction (linear to log/exp) amount, Inverting the range and

choosing the sampling frequency of the sensor, for CPU efficiency.Although up to this date, Ableton Live (v8.2.5) does not support OSC and UDP communication (also in M4L), this was solved using TouchOSC MIDI Control Surface scripts for Ableton, to allow incoming UDP messages.

At the moment I am working on adding the "Layouts" presets possibility, where different sets of parameter targets ("Controller Layers") could be changed while playing, using the buttons on controller itself. When this is done, a number of parameter "Layouts" presets could be prepared in advance for complex set-ups with many plug-ins (Synth's and FX's) and well as M4L devices, and could be fully controlled, practiced and performed, using only the ENSOF controller, with no mouse-keyboard-screen intervention.

ConclusionTo summarize this project, it was very exciting experience for me, exposing me to many different areas I didn't plan touching when started, including- analog and digital electronics, PCB design, soldering (way more then I ever thought), networking, product design and more. At start all I wished for was just having higher resolution control then MIDI has for making some noise, and thanks to someone who told me that everything is possible, it soon became an ambitious project, to produce, in my honest opinion, probably one of the most flexible and powerful music controller around, way beyond what the commercial market has to offer for sure.Even that there was no exact design for the controller through most of the design process, and although many improvisations were done all along the construction process, I find the resulting design extremely appealing, compact, and user friendly, and past my initial expectations by many factors. I would like to add here, that if the market had a similar device to offer, I would have bought it, since after all, the music is the goal in my case, yet I am sure that spending around a year for not compromising on products which are made for the average user and based on profit considerations, will payoff very soon, hopefully.

AcknowledgmentsWithout a lot of help from others, ENSOF would have never came out the (beautiful) way it did, if at all.First I would like to thank my electronics mentor, Lex van den Broek, from the Electronic Workplace (EWP) of the Royal Conservatory of the Hague, for an unbelievable dedication to this project, encouraging me at the beginning, when I didn't believe I can ever actually build a thing like this, through all my (many many...) daily questions and mistakes, always taking the time, also after working hours, to check and advice as well as to program and build what would have taken me another year to do. Without Lex I could never have built my own "dream machine". Here I would also like to thank all the great staff of the EWP- Paul, Tomer, Marlus, Dan and Pablo, for letting me work in the EWP almost every day, always interested and helpful with everything, tolerating my music and letting me use the good soldering iron.To Jan Panis, for giving me great foothold into analog electronics with his teachings, and also advising me and helping me find the right components and implementation methods for this device.To Johan van Kreij, bringing "The Stribe" to my attention, which later solved many technical troubles I has at the time, and to all the teachers of the Sonology department, that without you I would never have had acquired the "musical-control" needs which led me to build the ENSOF in the first place.To Josh Boughey ("The Stribe" creator) for helping me in some technical questions.To Yaniv Schonfeld, for the cool pictures.

Big Thanks!

Appendixes

I.1.1 PCB Schematics for low channel part: Slider with 2 LED bar, Force sensor and 10 Buttons

I.1.2 PCB Schematics for upper channel part: 3 Endless 2 wiper Knobs with Circular LED rings

I.2.1 PCB Board for low channel part: Slider with 2 LED bar, Force sensor and 10 Buttons

I.2.2 PCB Board for upper channel part: 3 Endless 2 wiper Knobs with Circular LED rings

I.3 Extra Schematics

Hi-Power LED transistor switching

Power delay to the alphanumeric digits switching board

II. Front Panel Cover Design

III. Max/MSP Patches

First complete panel layout design (Max used for graphics only)

IpSon64 input test patch (Made by Lex)

Normal input (stable)

Voltage drop input (noise at all inputs)

PIC to x12 MAX7219 display controller test patch (Made by Lex)

LED bar output test patch

Binary calculation for single point and meter display for MAX7219 IC

ENSOF full Max patch (Edit Mode)

ENSOF full Max patch (Locked Mode)

IV. Pictures

PCB's Arrives

First day at the EWP, Koncon

Caterpillar

PCB surprisingly work!

Puzzle's pieces

Buttons board front (with “Cree” Xlamp at bottom, x4 ~800mA LED's!)

Buttons board back (you can see XLamp cooler and the 1 Watt resistors)

Alphanumeric digits switch board back (before reconstructing it 3 times)

PIC display-controller (green board) and the switch board (yellow board)

The 2 IpSon64 mounted and the PIC board with the voltage regulators

My favorite dish- Spaghetti!

Not even close to finish

LED Check

With the panel cover and all sensors glued

Side view (2 IpSon64 sockets with their PIC reset button)

Back view (Power socket and switch)

It's Magic

Point Display and Upper Hi-Power LED's (Inc. the UV LED)

10 Fingers Technique, thumb controls the horizontal slider in between the force sensors fingers

White Mood

Green Mood

Blue Mood

Done!