Advanced MIDI Programming / Utility

I searched a lot For articles about VB & Midi, found some, but mostly they only handled short messages, the easy part. Here I needed To go further To solve a problem I had. The project turned out To be a bit sizy, but it embeds a lot of knowledge that was hard To find. So it could mean a great deal To someone starting With programming midi.

The main objective was To automate convertions of Roland SC-55 System Exclusive Bulk Dumps into a shorter alternative, using as much short messages As possible, so other modules can receive the messages too. Other features are mixing the SC settings, generate fade In/outs, Read & write midi, more Or less wysiwyg printing of the dump values, midi piano, midi thru, etc.



Click here for a larger image.

PURPOSE

  1. Analyse SC-55 System Exclusive bulk dumps
  2. Generate alternatives for this huge bulkdump in case a high percentage are default data
  3. Edit the Sound Canvas settings

ENVIRONMENT

This is a VB5 project. Since the WebBrowser control is used (provided with Windows 95) it can be run under Windows 95, but Windows NT doesn't install this control (~ SHDOCVW.DLL) automatically, so there you should find a way to install it yourself. No other (than basic VB) controls are used.

About the Project

*** BulkDump_proj.vbp

The main objective of this program was to analyse SC-55 bulk dumps and generate smaller alternatives for those dumps.

A bulkdump containes 7360 nibblized bytes of data. Nibblizing is often used in midi communication, since midi uses only 7bit (0-127) 'lines'. When you want to transmit a value higher than 127 then there is a problem. Nibblizing is the solution, altough it doubles the amount of data. For instance, if you want to transmit &HD8 (216), you have to split it into &H0D , &H08 and send those 2 bytes.

After un-nibblizing the dump data the number of bytes is 3680. Since I am not able yet to record a midi dump, I extract these dump data bytes from a *.mid file. The user has to record his dumps elsewhere and then load it into the program.

In the code the data are put in the array:

Public dmpB(3680) As Byte.

Whenever the user edits one of the parameter values (mixer forms) it will alter the current opened dump value. After editing he can save the new dump values, or generate alternatives.

The 'Alternatives' function looks for non-default values. If only a few are found, the resulting alternative will be much, much smaller in size. A saved dumps size is about 8kB or 2 to 4 bars in the piece of music. The alternative can be less than 1kB, 1 bar.

THE DUMPS

The information in the Sound Canvas manual about dumps is summiere, to say the least.

Everything is transmitted in packets. The largest possible size of a packet is 128 bytes. There are 64 patch common bytes, 112 x 16 patch part bytes, 128 x 2 drum map parameters.

64 + (112 * 16) + 256 = 2112 bytes

This is what they say, but this is much less than 3680. Why?

When I analysed recorded dumps in midi files I found the following structure:

   29 full part packets of 141 bytes (128 data bytes + 13 other)
    1 non-full part packet of 29 (16 data bytes + 12 other)
   14 full drum packets
    1 non-full drum packet of 36 (24 data bytes + 12 other)
   14 full drum packets
    1 non-full drum packet of 36 (24 data bytes + 12 other)

   full packet = 1 DeltaTime byte
                 1 BOX byte - &HF0
                 2 following bytes size 137 Big Endian - _
                   &H81, &H9
                 3 modelbytes - &H41, &H10, &H42
                 1 DT1 (data set 1) byte - &H12
                 3 address bytes - &H480000 patch all _
                   /&H490000 drum map
               128 packet data bytes
                 1 checksum byte
                 1 EOX byte - &HF7
             = 141 bytes

If you look at the data bytes only, you can calculate:

  (29 + 28) * 128 + 16 + 48 = 7360 nibblized
                            = 3680 bytes

THE FORMS

*** frmAbout

Generated by VB5

*** frmAltOpt

This form allows the user to set some options regarding to how the alternatives for the dump should be generated

*** frmBD

This is the main startup form, with menu's. The menu's are explained in BulkDump.htm

*** frmBDp

This form is a kind of a WYSYWYG preview to print the dump data.

*** frmDevCap

This form enumerates the midi devices and lets the user choose one of them, suggesting the MPU-401 ports

*** frmMixA

A form for editing ALL or COMMON parameters, such as reverb and chorus macro.

This form is independant of the data in sc55par.dat and is easy to extract from the project

*** frmMixLong

This form mainly offers the possibility to generate *.SYX files for separate individual system exclusive messages.

*** frmMixP

A form for editing PART parameters.

This form is independant of the data in sc55par.dat and easy to extract from the project

*** frmReadMidi

Since reading midi files can take a while, and sometimes the resulting text is larger then 64kB, this form offers the possibility of Canceling the action, viewing the progress and filtering the midi messages.

*** frmSeq

This form generates fade in and outs in the form of *.mid files.

THE MODULES

*** CD_File.bas

Replaces the CommonDialog control.

*** divers.bas

This module containes general functions.

*** dump.bas

This module containes routines mostly specific to the sound canvas.

*** midi.bas

This module containes all midi API function and my own midi function non specific to the sound canvas.

OTHER FILES

*** sc55par.dat

  [MODULEINFO]
  ManuID   = 41  Roland
  DeviceID = 10  Device ID
  ModelID  = 42  GS standard

  [SHORTMSG] - list of short messages
  01 Bn 00 mm Bn 20 00    bank select    ->No/ShortMsg bytes _
                                           (mm=value)/name

  [PARTYPES] - list of parameter types
  01  1   28   58    -24    +24 semitones ->No/NumBytes/MinHex/ _
                                            MaxHex/MinDec/MaxDec/ _
                                            name

  [COMMON] - common parameters
  000 MAS TUN   0 400000  9 04 00 Master tune ->No/ShortName/ _
                                                ByteOffs/Address/ _
                                                ParType/ _
                                                Altern.SHORTMSG/name

  [PARTS] ->same as common

Don't change anything in this file unless you know what you are doing.

*** BulkDump.htm

Is a short help file for the user.

*** sysex.htm

My own questions directed to you, the reader.

*** SC.gif

Used in BulkDump.htm

*** midi.gif - anoteoff.gif

Used in the program & BulkDump.htm

*** piano.ico

The program's icon

GSall.mid

A saved dump with default values.

Download zipped project file (82k)



Comments

  • Comment

    Posted by Legacy on 10/28/2003 12:00am

    Originally posted by: Alan Valencia

    Good Work!

    Reply
  • Good example....

    Posted by Legacy on 05/22/2001 12:00am

    Originally posted by: M@

    I have not gone all the way through it yet, but this looks like a good source for MIDI information. I have been looking for a listing of MIDI API calls for VB (winmm) but have only been able to find small examples. Any ideas where I might find a complete list?

    Thanks,

    M@

    Reply
  • Delta Time

    Posted by Legacy on 02/09/2001 12:00am

    Originally posted by: E.M. Robertson

    The delta time listed as one byte here is a variable length(as is other MIDI data) byte. Keep reading bytes as long as the high order bit is set. The first byte without it set is the last in the string.

    This example will probably work for a stand alone SysEx message but may not if imbedded in a MIDI file.

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: December 11, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT Market pressures to move more quickly and develop innovative applications are forcing organizations to rethink how they develop and release applications. The combination of public clouds and physical back-end infrastructures are a means to get applications out faster. However, these hybrid solutions complicate DevOps adoption, with application delivery pipelines that span across complex hybrid cloud and non-cloud environments. Check out this …

  • Hundreds of millions of users have adopted public cloud storage solutions to satisfy their Private Online File Sharing and Collaboration (OFS) needs. With new headlines on cloud privacy issues appearing almost daily, the need to explore private alternatives has never been stronger. Join ESG Senior Analyst Terri McClure and Connected Data in this on-demand webinar to take a look at the business drivers behind OFS adoption, how organizations can benefit from on-premise deployments, and emerging private OFS …

Most Popular Programming Stories

More for Developers

RSS Feeds