Project Logs

Collapse

• #8 - Check your manufacturers'/distributors' holidays

  Michele Perla • 10/06/2018 at 22:42 • 0 comments

  Hey there,

  So, I failed hard: my to-go PCB manufacturer and main component supplier (both Chinese) had holidays just when I was going to order all the stuff for the new CORE revision, as well as for the 3 full analog modules I talked about in the previous log, and guess what? Boards and components are on their way, yes, but sadly they'll get delivered AFTER the Musical Instrument's challenge deadline.

  What does this mean? For the sake of the project it's not a big deal because as long as I get my boards, everything's fine. For the Musical Instrument challenge, though, it means that I have to make whatever I can with the only prototype that I got available, a board that has design flaws and straight hardware issues in the most important part (the CV out), issues limit the amount of things that I can do with it; it also means that since I don't yet have any analog module with CVs to test, I can't really test and show the CV out capablities, like sending 1V/Oct signals to oscillators or sending envelopes to filters or amplifiers. Finally, a strange issue somewhere between the 2nd Teensy DAC pin, the MUX, the S&H circuit and the output buffer makes CVs 5,6,7, and 8 barely usable. So, I'm left with 4 CV outs with a limited voltage range (not the 10Vpp I originally intended), that cannot use the full 12 bit resolution of the DAC (because of wrong positioning of the gain stage in the S&H), and with no voltage-controllable stuff. 

  So, I spent the last days implementing proper digital oscillators on the CORE, one of the many functions I'd like to have on the CORE in the future. At the moment each CV out is actually used as an oscillator output, and each oscillator is controlled by a different MIDI channel. 

  I first implemented the 4 basic waves: sine, tri, saw, and pulse with pulse width control.

  Then, I implemented a rudimentary single note handler, that I then evolved in a 8-note buffer for each channel, with pitch bend.

  To test this setup I have a DAW that gets notes from a USB MIDI keyboard and sends them to the CORE via USB MIDI on several channels, while the CV/audio outs are connected to different channels of a mixer and finally the mixer stereo output is connected to two channels of an audio interface for monitoring and recording.

  Because of the issues mentioned before, I only have 4 outputs coming from the CORE, but I repeat, the CORE's software is already handling 8 concurrent oscillators with MIDI-to-frequency conversion; the 4 broken outs are just not connected to anything.

  Here's a quick improvisation (with issues) that I made with it (cheat: I'm using arpeggiators in the DAW on the 4 different MIDI channels since I yet have to implement one in the CORE). 

  This video should act as my Hackaday Prize entry video / Musical Instrument challenge composition, In case I don't manage to make any more progress.

  For reference, here are scope pictures of outputs 5,6, 7 and 8.

  CV 5 output is stuck at 4 V, trying to output a voltage from the DAC may get just a small chunk of the least significant bits out, everything else is just saturated. I guess there's an issue in the S&H gain stage here.

  CV 6 is just dead, it looks like the jack is connected to nothing. This could be a broken/not properly soldered buffer output resistor, but I double checked and everything seems alright; no idea.

  CV 7 may look like it is working, and in fact here's it outputting a triangle wave, but when the adjacent CVs are also outputting something there are some more evident glitches here and there.

  CV 8 is a mess :) unlike CV 7, which almost works as it should, CV 8 looks like the MUX is going out of sync and every other sample that should go to CV 5,6, and 7 appears here too. When outputting sounds on CV 5-6-7-8 at the same time, CV 8's output becomes a ghosting mess of all 4 channels mixed together. Here's CV 8 trying to output a sine wave.

  Here's CV 8 again, with a smaller time...

  Read more »

• #7 - Modules shmodules

  Michele Perla • 09/13/2018 at 09:28 • 2 comments

  Heya,

  quick update with the last month's worth of work.

  So, I'm setting out to make a 8CV+8Gates module right? And I want to test 8 voice polyphony with it, right? But how can I test it if I don't have 8 oscillators? Heck, I don't even yet have ONE oscillator.

  That's why I decided to make the 4 main building blocks to a synth to test my whole system, a VCO, a VCF, a VCA, and an EG :) The only digital module is going to be the EG, everything else is fully analog (you can read specs in the Details of this project).

  Here's some renderings:

  As soon as I finish designing the EG I'll order all the things and try them out!

  So, stay tuned :)

  Cheers, 

  Mick

• #6 - Summer, lunar eclipses and work

  Michele Perla • 07/31/2018 at 15:47 • 0 comments

  Hi there,

  It's been a long time since my last update, but there's a reason to this. The first prototype of the new Eurorack CORE module was a bit faulty, the CV section was not working as I wanted, and the two boards layout with clunky connectors made the thing quite expensive. 

  I spent the last couple of months fixing issues and optimizing the design, and I ended up with two more revisions. This last revision, rev3, uses less than half of the resistors of the first one, 8 opamps less, loses the 8 CV offset pots to favor a more stable 2 way switch to select between unipolar and bipolar CV out, and reduces the CV out range from 10V to 8 (who needs 10 octaves anyway). I also lost the 2.4 inch ILI9341 custom board to favor a ready-made 2.2 inch one, this should help in production, and added space for a SPI ROM to store all the user programs/configurations/settings/sequences/etc. Finally, I added a dedicated Clock output (the Gate In TS jack becomes a 3.5mm TRS jack with Clock In/Clock Out), and most importantly I managed to fit the whole design in one 105x105mm board.

  Then, I began working on two smaller versions of the CORE, which are the CORE lite and CORE mini. These will be not only a cheaper and smaller alternative to the CORE, using a Teensy 3.2 instead of the 3.6, and reducing the number of CVs/Gates to 4 and 2 while keeping the 2 CODEC connectors on for 4in/4out audio, but also (in the case of the CORE mini) to provide standalone functionality to the CTRL modules, as explained in the next paragraph.

  The CTRL modules are my new approach to complex control surfaces with high expandability: I ditched the IOAPEX design because it was "dumb" and because I couldn't find a decent way to hide the module in an Eurorack system that wouldn't require drilling holes in a case. For "dumb" I mean that using the IOAPEX the CORE could not be automatically aware of which module is connected to it. The new CTRL modules host a MCU that communicates via HS I2C with the CORE, therefore any installed module can declare its functions to the CORE without much user intervention; the idea is that you plug in a module and the CORE would either scan for newly installed modules at boot or at user's request and it will automatically know what's in the system. Having an MCU means that there's also room for more advanced functions; in particular I am going to use a SAML21 from Atmel/Microchip, a chip that has two integrated 12 bit DAC channels, HS I2C, USB, UART for MIDI I/O, and of course ADC pins for the analog sensors (pots, sliders, etc) and digital pins to control LEDs and buttons. These advanced functions will allow any of these modules to be used as CORE mini controllers; I still have to properly figure this out but the idea is that instead of getting a CORE mini + Teensy 3.2, an user could just buy the "raw" CORE mini board and plug it in some way to the CORE mini; I am thinking of making a Teensy 3.2 mockup PCB that provides a nice connector for the CTRL module.

  There's not been any development yet on the CODEC, that is I yet have to adapt my old designs into an Eurorack compatible format; other than that, I was thinking of using a more easily available CODEC chip, since there's no AKM distributor in Europe (yet). The only new idea I had was to provide both Eurorack-level and Line-level inputs and outputs on two different jacks; a cool thing would be to also let the CODEC work as a standalone module, that is to say without a CORE plugged the module would just convert line-to-eurorack and viceversa. The Eurorack-level connector will also be used as an external pre/post connector; for example, the HI-Z module will have an Eurorack-level output that can be connected to one Eurorack-level input on the CODEC to effectively have an HI-Z channel on your CODEC interface.

  While I keep working, you can take a look at this short...

  Read more »

• #5 - 100 likes on Facebook + unboxing some stuff

  Michele Perla • 04/25/2018 at 10:21 • 1 comment

  Hey people,

  yesterday marks the day when the project reached 100 likes on Facebook, and at the same time it's the day when I received the big shipment from China, YAY!

  I ordered the PCBs from JLPCB and most of the components from their parallalel procurement service, LCSC; this way I had to pay shipping fees for one package instead of two. Other components were ordered from Mouser (a couple of ICs and some connectors) and from Thonk (jacks and pots); I am still waiting for Thonk's delivery though :/

  Anyways, here's a mostly out-of-focus video of me opening the package for the first time :)

  Cheers,

  Mick

• #4 - Components are on their way, or how to become poor in one day

  Michele Perla • 04/19/2018 at 15:14 • 0 comments

  Hey folks,

  I did it, I ordered all the parts for the CORE 1.1 prototype!

  About the components

  Boards and components are on their way, along with a DIY Eurorack case kit to host everything.

  Of course, in the rush of buying everything because I want to make this ASAP, I ended up sending PCB files to the fab house with some minor mistakes (USB connector footprint is a bit different from the one I found in stock, 2 diodes and 2 resistors fooprints are smaller than the ones I had to buy, and finally the optocoupler power supply is 3.3V intead of 5V). All in all, silly mistakes that can be easily solved with a couple of flying wires or soldering tricks.

  I ended up splitting the project in 5 PCBs: 

  • Main board, hosts power, the Teensy and all the analog goodies for the CV outs
  • Controls board, hosts all the jacks/LEDs/pots/etc
  • USB/MIDI board, hosts the USB and the two MIDI connectors
  • TFT module board (it's just a smaller clone of the ubiquitous 2.4" ILI9341 boards)
  • Panel (because PCB-made panels are cheaper than aluminum)

  You can see them here:

  I encountered some issues while making the panel, mainly with the correct spacing of jacks and pots; I ended up changing the pots to Volca-style pots with integrated indicator so that they would take less panel space with respect to a normal pot with knob on it (the spacing between the knobs would have been too little).

  I also decided to separate the USB/MIDI controls from the Controls Board because those vertical connectors are longer than the others on the board, therefore they would stick out from the panel and that would look kinda off. 

  All in all, I should receive everything for next Friday (not tomorrow), so in the meantime I'll work on the CODEC, IOAPEX, and IOAPEX submodules :)
  

  About the poorness

  Well, ordering everything basically had me emptying my bank account. So yeah, I'm going to have a tough time for some weeks. I should receive some extra funding in a couple of weeks (from selling furniture that I had in France and that I couldn't ship back to Italy), with that I'll hopefully cover the expenses for the other prototypes.

  Conclusions

  I can't wait to solder everything, mount it, see if everything fits properly, check the S&H, program everything etc. 

  I'll keep you all updated, next update will probably be me unpacking stuff and soldering it all :)

  See you around.

  Mick

• #3 - "Woah, we're halfway there..."

  Michele Perla • 03/31/2018 at 18:05 • 2 comments

  Hey folks!

  This is just a quick update about the development of the project; work on the CORE module is ongoing and it is looking nice so far, check this out:

  This is the front panel PCB of the CORE as of now; I had a small issue with the 2.4" TFT display, unfortunately the readily available pre-made modules are a tad big, just enough to not let me fit the design of the front panel in a nice and clean 21 HP (1/4 of a standard Eurorack case width), so I decided to draw my own display module; the bonus is that I didn't put the classic SD slot you find on basically every ILI9341 320x240 TFT display modules, so on the long run I might save some cents.

  I'm going to openly release the slightly smaller TFT breakout because it might come in handy.

  Other than that, I eventually decided not to go for an almost full thru-hole design and switch back to mostly SMD parts; a TH design would be easier to solder (I thought about a kit version), but the 140 resistors on the board would take a tad too much PCB real estate. 

  Update done, let's get back to work.

  Cheers, 

  Mick

• #2 - CORE: On how to maximize functionality with limited resources, or about my love for multiplexers

  Michele Perla • 03/24/2018 at 16:56 • 0 comments

  When I first thought about redesigning the CORE my main goal was to use one Teensy to control at least one IOAPEX module and two CODEC modules, to reduce the overall cost of a full system (one Teensy 3.6 is at around 30 $), to reduce the number of duplicated parts over the modules or, in other terms, to agglomerate the mandatory common parts in one module. These common parts are, again, the Teensy, but also the USB port, MIDI ports mainly. 

  Minimum Common Denominator

  I for one don't like having to reserve one USB port for my audio interface and another one for my USB MIDI controller, and with the increasing number of laptops that sport less and less connectors for peripherals I suppose that the average user would like to have MIDI+Audio over one single USB cable, too.

  Secondly, to get more flexibility out of the CODEC modules I want to use low-jitter I2S master clock generators, in the form of two selectable oscillators that output 22.5792 MHz and 24.5760 MHz, but I don't want to have two oscillators near each AK4558 codec, it would take more resources (PCB real estate, Teensy pins to enable/disable them, actual component cost). I'd rather have them near the Teensy.

  Third, the Teensy requires a 5 V power supply, which may or may not be available in an Eurorack system, so I'd like to have a small switching supply to convert the readily available 12 V from an Eurorack supply to 5 V (switching rather than linear because a 12-to-5 V linear supply would dissipate more power than it would be ever needed by the whole module).

  This need for a main, minimum common denominator, module is why the CORE is now, well, the core module of the MAD project. 

  This also sets the CORE as a must-have thing for a MAD-powered setup, and to justfiy the eventual price of this module I can't just make it something that has a USB port and MIDI IN and OUT. I need features.

  Available Resources

  A Teensy 3.6 has a LOT of pins, but a lot of them are reserved for the IOAPEX, for the two CODECs, for the I2S external clocks, for the TFT, and for the MIDI ports.

  In particular, the IOAPEX requires full control over an SPI port, plus a reset pin and the two ADC channels.

  The two CODECs share 3 I2S pins (master clock, bit clock, frame select), then there's a TX and RX pin for each codec (4 total), one GPIO for each codec (for powering it down), and they also share the I2C bus (two more pins).

  The MIDI ports take only two UART pins.

  The two I2S master clock generators take one pin each and they share their output on the I2S MCLK pin (when one clock is disabled its output is in Hi-Z mode, thank you three-state outputs).

  The TFT takes 5 pins (three SPI pins and 2 hardware chip selects).

  About the SPI ports, the IOAPEX is going to be reserved on SPI2, the TFT on SPI0 (because the Teensy optimized TFT library makes extensive use of the SPI0 4 words FIFO), and this leaves a free SPI1 port. But, since I want to keep its pins for SPI instead of using them for GPIOs, the SPI1 pins are reserved too (4 pins). This is to allow future small upgrades (a RAM chip, or a Flash ROM maybe, or whatever). I'm also keeping untouched the common CS pins for the SD and memory expansions available on the Teensy Audio Adaptor in case someone wants to fiddle with them on a CORE.

  All of this leaves us with 30 available pins; 3 are analog only pins A10, A11, and AREF but since the IOAPEX is going to make full use of the two ADC channels continuously they're a no-go; furthermore, I'm fine with the way the AREF pins is connected on the Teensy itself so I do not need to touch it.

  So it's down to 27 pins, two of which are the two DAC channels. Not bad after all.

  Features, you said?

  This is where I thought about CV outs and Gate outs. 

  The DACs have already been used to output audio and CV, and driving a gate can be as simple as connecting one pin straight to a jack. Since there's going to be a USB port and MIDI ports already...

  Read more »

• #1 - A new hope

  Michele Perla • 03/22/2018 at 17:50 • 2 comments

  Hi folks!

  It's been a long time. 

  A time during which I changed country (again), a time in which I did not stop working.

  In fact, I have some nice news: MAD 1.1 is almost ready.

  WHAT WE LEAVE

  For a full list of info about the previous revision, check the former project page.

  The PSU is no more; since the project is shifting towards the Eurorack format there's no need to reinvent the wheel since most Eurorack cases come prepacked with a nice and powerful PSU.

  The main modules are not going to be stackable on top of each other (maybe except for the IOAPEX, more on that later). Also the idea of having small modules that would interconnect with each other using pin headers is gone, too. Eurorack means that the modules will all be on one big front panel, so it's kinda difficult to mate modules set in this fashion. This led to the integration of some old submodules into bigger main modules (like the CODEC, which is the old CORE+IN+OUT modules).

  The IOAPEX will have 128 instead of 256 digital IOs and analog ins, why? Because it's so much easier to find the 44-pins XC9572XL than the 64-pins one. Also, the digital IOs can be set up to scan matrixes, so there's still PLENTY of room for controls.

  WHAT WE GAIN

  More features than before! 

  Having to redesign for Eurorack made me lose the ability to stack modules on top of each other, making the use of a single Teensy 3.6 to drive multiple modules trivial. 

  This is why I decided to make the CORE a standalone module, not just a simple codec breakout. At first, in early v1.1 design phases, I thought that the CORE would provide just a USB port for PC communication and two MIDI ports for the sake of utility. But I also always thought of adding a TFT display to handle device configuration without resorting to custom tools on a PC, and I also always looked for a way of using the two DAC channels of the Teensy to do something useful. Finally, I also wanted to justify the eventual price tag of a mandatory module in case someone wants to use the IOAPEX and/or a CODEC to make their own MIDI control and/or USB audio interface. 

  So, here comes CV! The two DACs are going to be multiplexed to provide 8 CV channels, which will be used by default for Note, Velocity, Pitch bend and Modulation, along with 8 Gate channels which will be used for note gating, and for clocks. These CVs will be mapped either to USB-MIDI or to physical MIDI channels, and with a bit of software juggling they could be used to make, say, step sequencers, or to make 8 Note CVs instead of just 2. This would make a neat addition in any modular rack!

  As I said in the previous "chapter" the old CORE becomes CODEC, which will integrate the old IN and OUT modules in one big Eurorack module. The new CORE will have a custom header that will connect to the CODEC by means of an IDC cable. The new CODEC module will still retain the expandability features seen in the previous IN-OUT modules, so to have guitar buffers, mic preamps, phono preamps, passive speakers outs etc. 

  About the IOAPEX, since it will not provide any directly usable control in an Eurorack system, it will probably stack behind a CORE module. The user will then branch the IOAPEX submodules (with pads, buttons, encoders etc) to the IOAPEX using IDC connectors; in this way the IOAPEX will not take valuable rack space, leaving room for other modules.

  Conclusions

  It's been almost a year since I started working on this project, and it's finally taking its real shape. I still envision a crowdfunding campaign, which will only happen after I get a full set of prototypes in a rack and show them off at various expos (Maker Faires, Synth meetings, etc). I'd also like to get a collaboration with some hardware manufacturer to make custom Eurorack cases with FATAR-style keyboards that would connect to the IOAPEX, but that is a bit more far-fetched at the moment. 

  Of course, to do...

  Read more »

View all 8 project logs