AK47M project part 10 (Prototype ready)

I have completed the prototype AK47M and the first versions of firmware and controller software. I used an old cigar box as the enclosure. I have tested the unit using my Yamaha electronic piano and a keyboard amplifier. It works as expected and I am currently  writing a user manual which will explain the operation in greater detail.

The front panel is a piece of laminated paper glued onto some thin MDF. The front panel comprises of a 3×4 keypad, a 2 line LCD display and a row of 4 push buttons.


On the back is from left to right:

  1. The USB power cable.
  2. A pair of jack sockets for the stereo output for the auto accompany synth.
  3. A pair of jack sockets for the stereo output for the solo (right hand) synth.
  4. A 5 way DIN socket for the MIDI input

The following shows a series of screen shots of the AK47 LIVE software that either runs on a Windows PC or the internal Raspberry PI on-board computer.

The windows version simulates the keypad using the PC numeric keypad.


This is the initial screen with control for the solo lead voices and the left right hand split.

The buttons along the bottom deal with navigating the performance file and editing the current performance file.

The green boxes allow for easy selection of a voice for a part. The blue boxes are volume control sliders.


These two screens control the selected style parameter. The style file assigned to the current performance is shown in red text. The individual style parts may be independently controlled

This screen shows the BIAB file selection and the BIAB editor with a chord sequence for “Ain’t Misbehavin”





Lazarus / FreePascal problem on 64 bit machines.

I ported some open source MIDI handler code from Delphi to Lazarus. This was originally working on a 32 bit Windows machine but when I compiled and ran it on my Windows 64 bit machine I got a Segment Violation error when opening the input MIDI port.

I tracked the error down to the system unit called “mmSystem”. This defines interfaces to the windows multimedia DLL –  “winmm.dll”. The offending interface was a function called “midiInOpen”.

The function has a parameter for the address of a callback function. The current “mmSystem” unit defines this as 32 bit and not 64 bit as it should be if the code is compiled for a 64 bit machine. The unit needs to be upgraded to handle both cases.

In the mean time, I hacked my (open source) MIDI driver code to handle both cases:

I used the compiler conditional expressions to determine when I am compiling a 32bit or 64 bit system.

I have defined an alternative interface for midiInOpen call midiInOpenX which has a 64bit parameter (int64) for the callback address.

Seems to do the trick…


// X64 hack
Function midiInOpenX(x1: LPHMIDIIN; x2: UINT; x3: int64; x4: DWORD; x5: DWORD): MMRESULT;stdcall; external 'winmm.dll' name 'midiInOpen';

procedure TMidiInput.Open(const aDeviceIndex: integer);
lHandle: THandle;
lResult: MMResult;

if assigned( fDevices.Objects[ aDeviceIndex ] ) then Exit;

lResult := midiInOpenX( @lHandle, aDeviceIndex, int64(@midiCallback), aDeviceIndex, CALLBACK_FUNCTION );

lResult := midiInOpen( @lHandle, aDeviceIndex, longword(@midiCallback), aDeviceIndex, CALLBACK_FUNCTION );

if lResult <> MMSYSERR_NOERROR then
raise exception.Create( GetLastErrorText );

fDevices.Objects[ aDeviceIndex ] := TObject( lHandle );

MIDI gotchas !!

When I was writing code to handle the MIDI port it behaved well with my Yamaha P120 electronic Piano but behaved badly with my Yamaha PSR 6000. When I played keys on the PSR 6000, some notes would not play and others would not end correctly and kept sustaining.

I was baffled by this and saw that bytes seemed to be dropping out when viewing a raw dump of the port on the Raspberry PI. I was convinced there was a hardware problem, or a bug in the PI operating system.

I could play single notes and they would work but if I played a chord or two notes together I would get a problem. I then analysed the dump again and it struck me that there was a pattern. When a key is pressed, you normally get three bytes, the control byte $90, the pitch byte and the velocity byte. When two notes are pressed on the PSR 6000, I expected to get six bytes, two groups of three, but I got the control byte $90 for key down, the pitch byte for the first note, the velocity byte for the first note, the pitch byte for the second note and the velocity byte for the second note. I got 5 bytes instead of 6.

Its simple, multiple key presses are grouped together using a single MIDI control byte ! I altered the receiver code to keep accepting two byte segments until a new control byte is received. This solved the problem and the code works with both keyboards.

There is a subtle difference between theYamaha P120 midi firmware and the PSR 6000 firmware in this respect.

Gotcha #2 was that Yamaha do not use the MIDI spec for note off. (i.e. a control byte of $80). They use an alternative by using a key on but with a zero velocity. Presumably this helps when grouping mutiple key on/off events together.

Anyhow my code can handle both situations and always outputs 3 byte midi commands irrespective of what is received to keep things simple.

Gotcha #3 was that was a continuous flow of MIDI sense bytes of $F8 and $FE from both keyboards. These are simply filtered out.



AK47M project part 9 (PCB completed & updates)

I have received a set of PCBs and have built the first AK47M prototype. Everything seems to be working and I am currently working on an enclosure for it.

This shows the PCB populated with components:-


The next photo shows the addition of the two synthesizer modules:-


The final photo shows the addition of the PICs, the Raspberry PI Zero W and the wiring to additional components. It is ready to be put in the enclosure:-


There are a few tweaks required for the PIC firmware. I have done a lot more changes to the LIVE software running on the PI.

The “Band in the Bag ™” first cut of software is ready. I can create a chord sheet using an interactive editor using either the QWERTY keyboard or the MIDI keyboard. It handles repeats and variation selections. When a BIAB score is created and attached to a performance, it will play when the zero key is pressed. There is a tap intro for one bar before the sequence is played. The sequence can play to completion or repeat multiple number of times. This will be great to busk along with my Sax.

The LIVE software is now packaged as two versions, one for the Windows PC that interfaces to any attached MIDI device and one for the Raspberry PI that interfaces to the AK47M.

The hardware is modular so that certain functions can be added or dropped depending on requirement.


  1. Either one or both Synth modules can be dropped and an external MIDI device used instead.
  2. The LCD display can be dropped and a HDMI device or Android tablet can be used instead.
  3. The Solo Parts keyboard function can be dropped.
  4. The Fluid softsynth can be installed on the PI to do drums / bass arrangements only.
  5. The PCB can be connected to a keypad with a single PIC and used as the self-powered MIDI-Mate for connecting to a BK7M.

I am now using PIC 16F628A chips that are cheaper and have a more accurate internal oscillator. So I can also drop the resonators.

I am now working on the display of sheet music and lyric sheets. The intention is to synchronise the selection of a music/lyric sheet with the performance selection. I am on the look out for a portable HDMI monitor that I can hook up to the PI.


AK47M project part 8 (Connection to tablet)

I have investigated a simple way of connecting my Android tablet to the AK47M system in order to view and edit configurations.

The general method is to set up a WiFi hotspot on the Android tablet and connect to it from the PI Zero W. This WiFi network can be independent of the Internet and allows for a connection anywhere even on gigs.

Once a WiFi connection is established then a VNC client can be run on the tablet that shows the PI desktop and allows it to be controlled by screen touches or using a mouse attached to the tablet by USB.

When the connection is initially established it is necessary to obtain the IP address of the PI to configure the VNC client. Fortunately, there is an easy way by using a Hotspot manager app as it shows the addresses of attached devices.

I downloaded and installed two free apps from the Android Playstore …..

Hotspot manager allows you to configure a hotspot on the tablet with a WiFi password and switch it on or off as an when required. Running a hotspot does seem to drain the battery more than normal operation. It also lists any connected devices and their addresses.


VNC Client Free is a simple to use app to do the remote desktop connection to the PI Zero W. There is also a client produced by RealVNC that works well.

The IP addresses assigned by the tablet seem to be persistent, so once everything is configured it re-connects with no bother when the system is powered up.

My AK47M application running on the PI Zero W is called “AK47 LIVE” and is configured to run on boot up. This application integrates with the AK47M system and allows performances to be edited for the solo parts and the styles. It also runs the arranger that plays a style file and reacts to variation selections and chords played. There is also an additional tab for a “Band in the bag” which will allow the input of chord and variation sequences for a performance configuration, this is work in progress.


I have completed the AK47M PCB design and it is ready to be manufactured in China. (About £1.50 per PCB.)


AK47M project part 7 (Adding MIDI synthesiser and PCB generation)

I have investigated the possibility of running “FluidSynth” on a Raspberry PI in order to generate sounds from MIDI input. I have decided that a single PI is unable to handle 8 channels of MIDI generated from the Arranger software. It can only hack about two channels reliably with the sample rate halved from 41000 Hz and the latency is pretty bad at around 40 mS. Running several PIs in parallel is not really cost-effective either. This is unfortunate as the FluidSynth would be ideal for the application and could provide a lot of tailor made sounds. I will re-visit this when and if a more powerful cheap CPU card is mass produced.

I hooked up a PI zero running my Arranger software to my MIDI keyboard and this handles the MIDI generation successfully so I decided to look around for MIDI sound generation alternatives. I found a good alternative in the S2 synthesizer. This is produced by https://www.serdashop.com/waveblaster and it is a daughter board designed to plug into a PC sound blaster card. It is built around a Yamaha sound generation SAM2695 chip. I have successfully hooked this up to a PI Zero and generated sound from the Arranger software. The electrical connection to the device is very simple. One thing to watch out for is that the device reset line needs to be brought up to 5v on start up. They cost about £35 and I need two for my project, so I have bust my budget !!



I looked into the possibility of producing a printed circuit board (PCB) for my project as the separate components are on vero board and it looks a bit shoddy.

I was amazed at how cheap the production of PCBs is, especially if ordered from chinese shops and the large range of free CAD tools available for the PC. I tried out several of the free CAD packages and I decided that DipTrace https://diptrace.com/ was the easiest to use. It has a schematic editor for the circuit design. This can be transferred to a PCB design tool and there is a good auto routing tool available to optimise the PCB layout.

The design consists broadly of the following:-

  • Pi Zero W to run Arranger software and generate MIDI from style files and system configuration mesages. Also runs performance editor tools.
  • PIC to handle keypad, keyboard MIDI input and chord finder.
  • PIC to handle LCD display and accept configuration messages.
  • PIC to handle solo keyboard parts and accept configuration messages.
  • S2 synthesiser to generate 8 channels from Arranger software.
  • S2 synthesiser to generate solo keyboard sounds.

I have firmed up on the hardware so I am now going to concentrate on the software running on the PI. I am considering adding these features :-

  • A “Band in the Box” type of interface which was lacking from the BK7M. Here I am able to enter a chord sequence using standard notation for a style and let the software play the arrangement without having to play chords at the keyboard.
  • A display of a PDF file for a performance. This can contain a chord sheet, sheet music, words etc.
  • I can control the PI from an Android tablet using VNC virtual terminal software while it is connected to my WiFi network. It would be cool to be able to set up a local link from my tablet to the PI Zero
  • Some kind of “looping” software for live performance.

AK47m Project Part 6 (Adding a LCD display to the system)

I have added a LCD two line display to my project. I obtained a two line by 16 characters wide that costs about £6. LCD displays generally have a standard interface based on the Hitachi model. It is easily hooked up to a 16F628 PIC. There are 4 data lines, 2 control lines and 5v power lines. Only 4 of the 8 data lines are used and the LCD is programmed using 4 bit nibbles of data. The LCD display that I obtained has the pin out arranged as two lines of solder connections. The usual ones have a single line. The solder pad with a square surround is pin 1 and the pins are numbered from left to right so the odd numbered pins are on the left and the even numbered pins are on the right.

Note that the LCD is powered from the 5v supply but the control and data lines are driven to +3.5v from the PIC. The 5v supply is taken from the USB connection to the power supply. The 3.5v supply for the PIC is derived from the Raspberry PI.

The excellent MikroElectronika pascal compiler has a library to drive the LCD and a simple means to configure the PIC IO pins used to connect to the display. The LCD display connections to the PIC are as follows:-

Pin1 - Ground

Pin2 - +5v

Pin3 - contrast (grounded)

Pin4 - RS (PIC A1)

Pin5 - RW (grounded)

Pin6 - En (PIC A0)

Pin7-10 - High Data (grounded)

Pin11-14 - Low Data (PIC B4-B7)

Pin15 -Backlight LED (+5v)

Pin16 -Backlight LED (grounded)


The PASCAL program requires a declaration of the pin out as follows:

var LCD_RS : sbit at RA1_bit;
var LCD_EN : sbit at RA0_bit;
var LCD_D4 : sbit at RB4_bit;
var LCD_D5 : sbit at RB5_bit;
var LCD_D6 : sbit at RB6_bit;
var LCD_D7 : sbit at RB7_bit;

var LCD_RS_Direction : sbit at TRISA1_bit;
var LCD_EN_Direction : sbit at TRISA0_bit;
var LCD_D4_Direction : sbit at TRISB4_bit;
var LCD_D5_Direction : sbit at TRISB5_bit;
var LCD_D6_Direction : sbit at TRISB6_bit;
var LCD_D7_Direction : sbit at TRISB7_bit;

The display is initialised using the following code, note that the compiler automatically links in the LCD driver library.

 Lcd_Init(); // Initialize LCD
 Lcd_Cmd(_LCD_CLEAR); // Clear display
 Lcd_Cmd(_LCD_CURSOR_OFF); // Cursor off

The display is updated as the following example:

 txt := 'PHSC (c)2018';
 LCD_Out(1,1,txt); // Write text in first row from character pos 1
 txt := 'AK47M Vs 1.0';
 LCD_Out(2,1,txt); // Write text in second row from character pos 1

When I first ran my program, nothing happened ! Eventually I realised that the contrast was not connected on Pin3. This is normally driven by a voltage divider to adjust the voltage. I simply grounded the pin and it worked fine.

These photos show the individual components:-

This is the LCD display with wires soldered on that connect to the PIC.


This is the display PIC. The wires to the right go to the LCD display. The wires to the left take power to the configuration PI card and receive MIDI data.


This is the connector to a PI B+ card to obtain power and send MIDI data to the PI. There are four connections : +5v, +3.5v, Ground, UART Receive.


Here are the three components connected up.


The PIC uses its internal UART to monitor the MIDI messages. I have defined a set of MIDI messages for internal use. These are kept short as there is no flow control. This means I can use a one wire connection to operate the LCD display.

Internal MIDI messages have the general format:

$F1 <length of data> <function> <data>

except for key press messages that have the format

$F1 $00 <key press>

Here is a summary of the messages :-

Key press - $F1 $00 <key press>
Display 1 - $F1 <length> $01 <text up to 16 chars>

Display 2 - $F1 <length> $02 <text up to 16 chars>

Select Style File - $F1 <length> $03 <style file name with extension>

Style Params - $F1 $18 $04 [Voice PC]x8 [Voice Vol]x8 [Voice Enable]x8

Style Aux - $F1 $04 $05 <tempoH> <tempoL> <transpose> <variation select>

Part Params - $F1 $10 $06 [Part PC]x4 [Part Vol]x4 [Part Flags]x4 <Split point> <Split Enable> <spare> <spare>

Chord Finder - $F1 $02 $07 <chord pitch> <chord type>


Midi Mate Revisited

Some while back I developed the “Midi-Mate” that connected my Yamaha electric piano to the BK7M. The BK7M unit does not work anymore so I needed an alternative at short notice. I decided to use my old Yamaha PSR keyboard as an alternative sound generator and link it to my piano using the Midi-Mate.

I re-programmed the PIC to hold a set of pre-programmed performance settings internally and recall them when a key sequence was entered. I was able to double up two lead instruments and split the keyboard exactly in the same way as the BK7M. The PIC was able to hold about 100 settings internally. This worked well except that the settings were static and could not be edited.

I decided to use the hardware developed for my AK47M project to extend this concept further and allow me to program the MIDI controller.

A PIC microcontroller is connected to my electric piano via MIDI and also scans a 3×4 numeric keypad. The PIC is connected to a PI zero W using a MIDI serial link so that the PI can accept keypad messages. The PI serial output is linked back to the PIC. This is done so that the PI can send performance configuration messages to the PIC in response to a keypad selection.
The PIC has all the logic to select instruments on 4 MIDI channels and route piano MIDI messages to any of the channels. It can also handle the channel volumes, split the keyboard and perform transposition.

The PI is simply being used to store and recall performance configurations from file and provide a real time editing function for a selected performance. The software uses exactly the same formats as the BK7M performance files so that configurations can easily be edited by my BK7M editor program. (which I have ported to the PI)
The latency is kept to a minimum as the PIC is handling the routing of key on/off messages.

I run the PI in headless mode and it connects to my wifi network. I can run a virtual terminal on my PC or Android tablet in order to use the editor. The screen shots show the completed unit and the editor/configuration software.


This is the completed unit. There are two MIDI sockets, one for the Piano and one for the Synth. Power is provided using a USB connection to a USB power supply.

A performance is selected by typing in the performance number followed by a hash. The following numbers provide special functions :-

9991 – restart PI

9992 – shutdown PI

9999 – MIDI panic

The software loads the performance file “0.ups” by default. A different performance file can be selected by typing a number followed by the star key.



This is the configuration software running on the PI. When a number is entered on the keypad, the appropriate performance configuration is recalled from file and displayed. Parameters can be selected and changed and then sent to the PI by pressing “Update and Send”. The Previous and Next keys allow you to move to the previous or next performance in the file. The entire performance file with edits may be saved using the “Save to File” button.

Note that the performance file is 100% compatible with the BK7M and the BK7M editor. I have ported a version of the Windows BK7M editor to run on the Raspberry PI.

AK47m Project Part 5 (First cut of arranger software on PC and Pi)

Project Updates —

I have built a skeleton program that extends on the previous work and goes a long way to a full arranger. There are two builds, one for Windows and one for the Raspberry PI.

The Windows build outputs MIDI to an external MIDI device. I am currently using the MidiMan MIDI USB interface to read and write to an electronic keyboard for test purposes. I can alternatively route the MIDI to the Windows MIDI device or the excellent VirtualMIDIsynth and generate audio on the PC itself.

The PI version is linked to the QSynth program (which is a wrapper around FluidSynth) via ALSA and generates audio from an attached USB audio interface.

The arranger software is built around the use of the 3×4 matrix keypad as part of the MIDI interface described previously. I have a simulation of this for the Windows build. The software loads up a BK7m performance file called “0.ups” on start up. Individual performances may be called up by typing the performance number (from 1) and pressing the hash (#, PERF) key. The style file linked to the performance is loaded ready to play. It is possible to load a different performance file by keying in a number and pressing the asterisk (*, FILE) key. The file loaded has a filename of the number plus the .ups extension. e.g. “123.ups” .

Once the performance is loaded, it is possible to start by pressing a chord in the left hand or by pressing the zero (0) key on the keypad. When a performance is running it is possible to change to a variation by pressing keys 1..3 or to stop by pressing the zero key. I am proposing to add 4 extra push switches to handle the variation selections.

I have completed the chord finder logic. This works out the chord played in the left hand, selects the maj, min or dom7th snippet and applies appropriate pitch corrections for the chord key and the chord flavour. (i.e. converting the dom7th snippet to  Maj7th snippet) The snippet for the variation is played entirely and then repeated.

When a new variation is selected, a fill for the current variation is played and then the new variation is started. I ensure that the fill is started at the same beat in the bar as the variation that is playing.

I am selecting the instruments specified in the style file at the moment although the BK7m performance can override these. The instruments are kept within the General MIDI instrument palette.

It is still very much work in progress. The main development is done on the Windows PC and verified occasionally on the PI. I have had mixed success in playing styles on the PI. Some of the styles require a lot of processing power which load the PI up to 100%. The balance of volume between instruments is wrong for the FluidSynth sound font and there needs to be a function to correct this and write back the settings to the performance file.

I will trial the software on a PI B+ that has a lot more capacity. There are no CPU performance problems on my 4 core PC.

I may also trial with the arranger on a PI connected to another PI with the Synth. If I do this then I will use the first PI to drive the keypad. My goal is to keep the overall cost as low as possible.

I will release the two installations soon once I have truly figured out the style file format.


The setup tab allows you to select the MIDI input and output devices, test the output and bring up a debug message window. This is for Windows only.



This is the main control tab. The keypad simulation is to the right. The actual commands are listed in the central window. The red shows the BK7m performance name, the green shows the current chord selection.




AK47m Project Part 4 (Making sense of Roland style files)

I have installed Lazarus IDE and Free Pascal on my Windows PC. The installation is easy and it works out of the box !. There is a function for converting Delphi projects to Lazarus projects. The BK7m performance editor I wrote several years back was a Delphi project. I converted this to Lazarus and it required a few tweaks to get it working but nothing major. The advantage of doing this is that I can develop software more efficiently on the PC and then transfer the projects to a Raspberry PI and compile them with the native Lazarus system. Most objects can be transferred easily, but obviously some of the interfaces to MIDI and ALSA need to be tweaked.

One of the last features I was working on for the BK7m editor was a style file editor, this was shelved due to other work, however I started looking at the work completed as a basis for the AK47m project. There is scant information on the Roland style (.stl) file format around, so I had to do some reverse engineering on the format. Any extra information would be welcome.

Style file (.STL) format

The style file basically has a header block at the start followed by a heap. The header contains tables of indexes into the heap and tables of corresponding object sizes. Each object in the heap, which I have termed as a “snippet” contains a list of MIDI commands and time offsets as in a MIDI file. The “snippet” can be played to a MIDI device and it will play a 1..n bar phrase for a single instrument.

Snippets are created for up to 8 instruments (Drums, Bass, 6 harmony instruments). There are three versions of a snippet for an instrument, namely Major, Minor and Seventh. Each snippet is in the key of C, a Major snippet will play a musical phrase for C Major, and a Seventh snippet will play a musical phrase for C7. The arranger software identifies what chord is being played with the left hand and then applies offsets to the pitches of a snippet to play harmony corresponding to the chord. i.e. transposing C to G would add 7 semitones to each note in the snippet. Some snippets are used for the drum track and these would not get transposed at all.

I asked myself about what happens when a Major Seventh chord is played. i.e. C E G B. I assume that the Seventh harmony snippet (C E G Bb)  is used as a basis and a transformation is applied that converts the Bb to B natural before the pitch offset is applied. Similarly a transformation to get a Cm7 harmony (C Eb G Bb) would convert the E natural to Eb.

One thing I wondered about was whether the simple Major and Minor snippets are necessary since a Major could be obtained by dropping the Bb from the Seventh snippet. Maybe the Major snippet is used to produce a Sixth harmony ( C E G A) by adding a tone above the fifth note. More information on this would help me !!

There is a higher level grouping which I have named as sections. There are 16 sections. The structure is 16 sections of 8 instruments of 3 harmonies. The sections correspond to the variations, intro, outro and fills. Some of the sections are completely empty which is a bit of a puzzle.

I believe that the sections are used as follows:

  1.  Intro 3
  2.  Variation 1
  3.  Variation 3
  4. — spare —
  5. 1 bar fill Variation 2
  6. 1 bar fill Variation 1
  7. — spare —
  8. Outro 4
  9.  Intro 4
  10.  Variation 2
  11. Variation4
  12. — spare —
  13. 1 bar fill Variation 4
  14. 1 bar fill Variation 3
  15. — spare —
  16. Outro 3

There is also a table of Word values for each snippet (snippetUnknown), what this relates to I am unsure – are they flags or offsets. Help required.

Unfortunately my BK7m unit does not work so I am unable to compare what the BK7m does with each snippet.

What puzzles me about this is that there are no snippets for intro 1 & 2 and outro 1 & 2.

On closer inspection of the file, I have discovered that there is another header record that starts with G8<name> . It seems that the header maps to the same structure as the first header. There doesn’t seem to be any record size fields, so I have to search for the string G8<name> in the raw data to find the start of the second record. This format is unbelievable spaghetti.

The snippets missing from the first record are in the second record. Note that the snippet pointers are relative to the start of the record in the file.

I suspect that the second record was added for backwards compatibility. There looks like a third record related to the one touch settings. ( i wondered where these were in the BK7 performance file !)


styleHeader = record

id: packed array [1..2] of char;
 name: packed array [0..15] of char;
 d1: packed array [1..2] of byte;
 tempo: packed array [0..1] of byte;
 d2: packed array [1..2] of byte;
 timeSignatures: packed array [0..15] of timeSig;
 d3: packed array [1..2] of byte;

 snippetPointers: packed array [0..7] of //instrument
 packed array [0..15] of //section
 packed array [0..2] of longint; //maj min 7th

snippetUnknown: packed array [0..7] of //instrument
 packed array [0..15] of //section
 packed array [0..2] of word; //maj min 7th

snippetSizes: packed array [0..7] of //instrument
 packed array [0..15] of //section
 packed array [0..2] of word; //maj min 7th



“id” is set to the string “G8”.

The snippet pointers reference a list of 6 byte records that have the MIDI data and timing data :-



timeSig = record
 beatsPerMeasure: byte;
 beatValue: byte; // 01 = 1/2 02=1/4 03= /8

noteEvent = record
 channel: byte;
 velocity: byte;
 dollar40: byte;
 timeLength: byte;

controllerEvent = record
 channel: byte;
 effect: packed array[0..2] of byte;

pitchWheelEvent = record
 channel: byte;
 pitchTimesThree: packed array[0..2] of byte;
 //pitchWheelCommandAgain : byte;

 programChangeEvent = record
 channel: byte;
 prog: packed array[0..2] of byte;

nrpnEvent = record
 channel: byte;
 msb: byte;
 lsb: byte;
 Data: byte;

eventRecord = packed record
 timeIncrement: byte;
 case pitchOrCommand: byte of
 0: (raw: packed array [0..3] of byte);
 1: (note: noteEvent);
 $E6: (controller: controllerEvent);
 $EB: (pitchWheel: pitchWheelEvent);
 $E5: (programChange: programChangeEvent);
 $EA: (nrpn: nrpnEvent);
 $8F: (); // end of list
 $80: (); //data ??


 eventList = array of eventRecord;

Project Goals

The BK7m Editor can interface to a PC MIDI device and output MIDI commands. When MIDI is connected, it is possible to load a style file and play the individual snippets or any combination of them. This was helpful in deciphering the file structure.

The next project goals are to write a PC based program based on the BK7m editor that can perform the MIDI arranger functions. There are five parts to this:

  1. Create general purpose MIDI input output module that works on Windows and PI.
  2. Load a selected style file into appropiate internal data structures.
  3. Identify the chord harmony from notes played on the lower MIDI keyboard and output the chord name.
  4. Apply transformations of snippets using (3) and play the MIDI notes.
  5. Handle transitions between variations with appropriate fills.



« Older Entries Recent Entries »