Posted on

Daniel’s Status Report 02/21

I spent the first half of this week preparing to present the design report on Wednesday.

After that,  I took time to revise the Intel documentation for the IP blocks available in the Quartus software tool chain. By taking advantage of the already existing IP blocks for the audio codec, DAC control, and DSP, it may accelerate the interfacing endpoints of the WaveShaper to get the project to a demo-ready stage. I am not familiar with using IP blocks under the Quartus toolchain, so I needed to familiarize myself with the general process and set up a project file that could be used to program the fabric.

We have all the tools required to attempt to create an end-to-end test and produce a series of notes from Shayaan’s oscillator hardware descriptions. Namely, using the audio “stack” of blocks to ultimately drive the Wolfson audio chip.

Moving forward, I would like to use the HSP chip to create a interface to receive USB payload data and pass the wrapped MIDI commands to the main control module of the WaveShaper.

Posted on

Daniel’s Status Report for 02/14

This week, I continued to explore options for communication between the driving PC, the WaveShaper, and additional MIDI peripherals. Earlier this week, I had considered and sketched out a protocol wherein all auxiliary (i.e., non-MIDI) information would be transferred within the SysEx commands of the MIDI spec. While this is still feasible and should be able to keep up for live, real-time music, the USB specification enables the use of “composite devices” which support multiple, simultaneous interfaces. This could lend itself to more flexibility and warrants more analysis before setting in the serial communication in stone. From an ease of implementation point of view, it would have the advantage of having convenient parallelism between these conceptually disjoint streams without the need for additional hardware or cables.

(This design decision was prompted with the choice for the DEC-10 FPGA in mind, seeing as it supports both USB host and device interfaces.)

We would want to consider support the following serial streams.

  • PC to the WaveShaper for MIDI notes and events.
  • PC to the WaveShaper for a “shell”-like command interface.
  • WaveShaper to PC for probing into the sound synthesis datapath.
  • WaveShaper to PC for responses to “shell” commands.
  • [Optional] A final USB audio input interface which can enable the PC to be used as a speaker / audio sink.

These could all be interfaced through dedicated, corresponding USB device classes.

While it would be incredibly helpful to offload the multiplexing to the USB hardware and controllers, I would want to revise the hardware we are deciding on more thoroughly before making such a jump. That said, the option remains to merely implement the first MIDI with SysEx interface (which would be in line with the original plan).

Posted on

Team’s Status Report 02/07

On Monday, February 1st, we presented a final proposal for the complete set of features and scope of The Waveshaper. Having decided what we are building, we shifted focus this week onto the beginnings of a hardware-implementation design.

We met to form consensus on a high-level description of what The WaveShaper is to be in technical terms, specifying HDL modules, finalizing the choices for I/O, and defining the black-box specifications (inputs and outputs) for the individual components and sub-systems of which The WaveShaper shall be comprised. Successful divide-and-conquer team dynamics require each contributor to understand precisely how their own work interfaces with the parts a teammate will design

Specifically, this week we decided:

  1.  To implement on an FPGA development board.
  2.  To sample at 44.1kHz with a 16-bit-depth.
  3.  To use MIDI’s user-defined System Exclusive (SysEx) commands for WaveShaper-specific communication.

These questions will lead the design process over the next week:

  1.  Which FPGA development board to use?
  2. How can we best quantify the signal bandwidth requirements in terms of FPGA area, speed, and extended features?
  3. What memory solution is best for our requirements?

 

Of possible interest is the more specific block diagram we made in our first all-hands meeting after the proposal presentation.

Posted on

Daniel’s Status Report for 02/07

This week, with the finalized proposal in hand, each group member focused on completing specific details of the projected system implementation. After a group meeting, we divided responsibility for the next set of design decisions to be made in parallel.

I spent time researching both the MIDI and USB protocols to address the following question:

Suppose we want to interleave standard MIDI note events with specialized, device-specific serial commands over a single USB connection (e.g. requests for auxiliary data, control commands for sound synthesis parameters, and FX tuning). What is the best method to achieve this?

While it would be feasible to draw the protocol directly from prior MIDI instrument designs, our anticipated data throughput is likely to present a more intense requirement. In particular, we expect to transmit multibyte sequences that may need to be information-dense enough to define complex effects.

The MIDI 1.0 specification provides a System Exclusive (SysEx) message format that allows arbitrary, “manufacturer”-defined data. As a result, it appears advantageous to “flatten” the interface by embedding our own messaging protocol and custom commands within these SysEx messages, thereby maximizing compatibility with existing MIDI devices and software. It would be much easier to find conformant MIDI streams than have to test and integrate a custom protocol that wraps around the MIDI layer.

While the project is thus far in a draft stage, I believe the emphasis on design decisions and FPGA architecture are paving a clear road ahead. That said, to put rubber to the road, I would like to ensure that skeleton drivers for what is to be the user-facing desktop software are ready by this time next week or (at least near completed).