MIDI to MOCKINGBOARD Converter Release V1.00

[Tom Porter]

MIDI TO MOCKINBOARD CONVERTER v1.00 Release
-Convert your favorite midi files to Mockingboard...

https://www.dropbox.com/s/z0ld…/MIDI%20TO%20MOCK%20VER1.zip…

The PLAYER disk has a few samples you can try out today! The
Converter requires an emulator, but the player disk should work
on Apple II+, IIE, IIC and IIGS! - We are working on making
documentation better...

I am hoping that we can create a community to support this,
allowing in the future for voices (sound fonts) and a huge
library of MIDI conversion...

Right now its a unique format and not IRQ driven so there are
limitations...but I hope we can fix that in the near future.

[Tom Porter]

Whoops, bad link.... cant edit.
https://www.dropbox.com/s/z0ldxehkebwbfeg/MIDI%20TO%20MOCK%20VER1.zip?dl=0

[Antoine Vignau]

Congrats Tom!

[Michael 'AppleWin Debugger Dev']

Oooh, nice! I'll definitely be making use of this for one of my games later this year.

Any chance to update the UI to show a down arrow in the player? It is crime to show only 3 lines of music files (when you have 24 text lines!) and no down arrow to signal to the user that there are more files!

Are there any plans to throw the source up on GitHub? Also, any plans to support two mockingboards?

Cheers
Michael

[Tom Porter]

I updated the files this morning to include 5 more sample songs on the player disk, and did a few minor bug fixes.

I started to reverse engineer the MCS player but did not get very far, so I had to start from scratch and create my own format. I also do not know how to implement the IRQ timer function.. if anybody wishes to help me out I will add it. Also need help in creating voices (sound fonts) for the various tracks... I know it can be done but not sure how to start on that.

That being said, right now its not much more useful than a song player, but remember its only version 1.00.... I do wish to update it frequently. The first upgrade is pure assembly based player, its actually in pieces on graph paper as we speak!

I don't want to release source code to the converter quite yet, but I will make available code how to play its song's format.

[ian kim]

Nice starting..
I believe that you can make it better.
Also I also want to make MIDI player on my APPLE //e but, I'm not good at programming on APPLE //e..
Anyway, your program would be played some more sound card..
I will try it on SD Music card(Mocking board compatible FM sound card).
Thanks to have good music program.
Ian Kim

[STYNX]

I have used the ALF music File format for midi conversion (not on the A2 though). It is a format targeted towards simple PSG type music chips. There are a lot of tunes on the ALF-disks already and implementing a player is not that hard. You can easily expand the functions of the format by using custom commands that are not yet used in the definition.
Just take a look in the ALF MC1 manual for the definition of the format.

-Jonas

[Michael J. Mahon]

Several years ago, I wrote an Applesoft program to convert MIDI files to
CRATE.SYNTH music files with up to 16 oscillators (voices).

MIDI files are not restricted in size or organization, and all general MIDI
voices are supported, including percussion. It's not fast, but it's quite
precise, and can handle tempo changes while notes are sounding, etc. It is
designed to work in a hard disk environment.

It can produce varying levels of logging, so you can see how it's
allocating oscillators, and it supports track allocation to stereo
channels.

I developed it as a tool for personal use, but it has proven to be quite
capable. It outputs note lists (note, duration) and voice change events for
each oscillator, so it should work quite well for AY8910-type sound
generators.

Maybe I should put it up on my website...

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[Tom Porter]

Mahon, your the sound giant in the room, i'm nothing more than an armature... what I don't have with smarts I make up with 'almost untold hours' of trying to get things to work! I did look at your Midi Converter but I have no idea where to start, it converts the midi directly in the apple? For me it doesn't matter. When I started down this road back in 2013, I found a MS-DOS program that translates midis into txt list of all its properties... what I did then was to take that information into the APPLE and sort it, weeding out everything that wasn't needed. Up until a month or so ago, my biggest problem was making several tracks work with just one beep at a time music... you tested VERY early versions of my Music Master game, thank you very much, I still appreciate it. It, such a relief that most of the computation work for my own midi converter no longer is needed with mockingboard, and is much simpler process.

For Ian Kim... Do you have any advice about creating voices for the mockingboard... I see your nice program but haven't been able to implement it yet. Got a few more bugs with my MIDI-2-MOCK program being worked out, then I really need these! Any help would be appreciated!

[Oliver Schmidt]

On Fri, 7 Apr 2017 07:50:57 -0700 (PDT), Tom Porter
<laserac...@gmail.com> wrote:

>I started to reverse engineer the MCS player but did not get very far [...]

>I don't want to release source code to the converter quite yet [...]

History repeating itself ...

[Mark D. Overholser]

On 08-Apr-17 16:39, Michael J. Mahon wrote:

<< SNIP >>

>
>
> Several years ago, I wrote an Applesoft program to convert MIDI files to
> CRATE.SYNTH music files with up to 16 oscillators (voices).
>
> MIDI files are not restricted in size or organization, and all general MIDI
> voices are supported, including percussion. It's not fast, but it's quite
> precise, and can handle tempo changes while notes are sounding, etc. It is
> designed to work in a hard disk environment.
>
> It can produce varying levels of logging, so you can see how it's
> allocating oscillators, and it supports track allocation to stereo
> channels.
>
> I developed it as a tool for personal use, but it has proven to be quite
> capable. It outputs note lists (note, duration) and voice change events for
> each oscillator, so it should work quite well for AY8910-type sound
> generators.
>
> Maybe I should put it up on my website...
>

This sounds very Cool... Please Post your Utility...


MarkO

[Tom Porter]

**** UPDATED with DOWNLOAD LINK!!!!
MIDI to MockingBoard version 1.10
https://www.dropbox.com/s/z0ldxehkebwbfeg/MIDI%20TO%20MOCK%20VER1.zip?dl=0
Old Links will go to the same place

Mock.v6 is entirely assembly, so now you can go all out with the shortest
note lengths you want (they will still eat space)... faster note transitions.
Updated Manual to cover MUSESCORE 2.00 (Never occurred to me they would update
it in the last 3 years) and a few other minor bug fixes!

[Michael J. Mahon]

As I was preparing to upload CVT.MIDI (I remembered the name wrong ;-),
I realized that it was already on my website! Look under the
"AppleCrate Polyphonic Music Synthesizer" topic, and scroll down to "The
MIDI Converter" for a link to the Applesoft source and information on
its function.

MIDI.CVT is an Applesoft program I wrote to convert MIDI files into
CRATE.SYNTH music for up to 16 simultaneous oscillators. The output
file is a concatenation of 1) a 256-byte directory of the following
music streams, one per oscillator, and 2) a series of page-aligned music
streams. This program only runs under ProDOS and will usually require a
hard disk.

It is quite general in the MIDI files that it can process. Any
reasonable number of tracks, in interleaved or non-interleaved format,
can be processed. All tracks are merged into a single time sequence.

I'm sending it as a TXT file that can be EXECed into Applesoft.

The directory entries are 6 bytes for each oscillator (music stream).
The first byte is the MIDI track number for this oscillator (just
informational, and not accurate when the oscillator is assigned to
multiple tracks), an unused byte, a 2-byte offset into the file, in
units of 256 bytes, to the start of the music stream for this
oscillator, and a 2-byte length of the stream in bytes.

The streams consist of 3-byte entries, of the following format:
80 xx xx - Stop playing (no further music).
81 dl dh - Rest for duration dl.dh.
82 vv xx - Change to voice vv.
nn dl dh - Play MIDI note nn for dl.dh. (Where nn < $80)

The duration is represented as a sample count of 22.05kHz samples, where
dl is the low byte and dh is the high byte plus 1 (to speed up end
testing during CRATE.SYNTH synthesis).

This should allow easy decoding of the produced music files.

The maximum number of oscillators is a program parameter. If more than
the maximum number of oscillators are needed by the MIDI music, CVT.MIDI
will "steal" the longest-playing oscillator and reassign it to the new
note. Note that a Mockingboard, for example, has 6 oscillators.

--

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://michaeljmahon.com

"The wastebasket is our most important design
tool--and it's seriously underused."

[Tom Porter]

In contrast... the 4/3 byte format for MIDI-MOCK I came up with is...

A. TRACK/DURATION ... if less than 240 then its a duration. The duration
is multiplied by 10 (10ms) for the full calculation... equal to max 2440ms. This duration is added to the TIME-TABLE and not for a particular note...

A2. if Track is above 240, 239 is subtracted and computed as a command... the first 6 numbers above 240 are counted as a track number... for the oscillator
on the mockingboard. Future expansions will use higher numbers, as to change
volume, and voices, ect ect, or even the Phaser.

B. It uses the next 3 byte in a command for an oscillator told by (A).
NOTEA/NOTEB/DURATION (needs two notes for full mockingboard sound).

There are counters for location and memory, and how many (MS) the song is into... and every note is compared to the time... so it shuts off the oscillator when it exceeds the last updated note maximum.

The advantage of this last 3 note system... is that if multiple notes are updated on the same time slice (ms).... then only 3 bytes are needed and not 4. There is a way to combine one of the notes (never value more than 4) and the above track number... but would have been difficult to code in assembly, at least for me. It doesn't swap in and out tracks like Mahon's so its limit is whatever the maximum oscillator number is... mockingboard 6, phaser 12, alf 9 ect ect...

[STYNX]

The ALF format generally uses 3 bytes per command. The MC1 or MC16 player is not externally synchronized and was designed by counting cycles to run at a constant rate. The format supports 192 quarter notes (byte values 00-BF) to be used with 00 being "A natural" at 27.5Hz. There are 24 quarter-steps per octave. (The MC1 was limited to values from 30 to 174) 16 control commands (47 commands are not used) can be used. Up to 9 simultaneous tracks can be used.
http://www.applelogic.org/files/ALF%20MC1%20MC16%20Manual%201983.pdf (pages 107-)

Completely documented and ready to use ;-)

The format is optimized to be directly played from memory (including relative jump for subroutines) with up to 64kbytes of 'addressable' data. This means about 21000 notes and/or commands in total across all tracks can theoretically be used. Its very much targeted towards synthesizers that aver a pre-set waveform (PSG or analog syth). The format allows subroutines, custom commands and multiple tracks. Up to 9 oscillators are supported in the implementation for the MC1 on the A2. Strangely enough it has some similarities to MIDI even though it was designed in the late 70s (MIDI was introduced in 1982). Applied Engineering expanded (not documented) the format to support 12 simultaneous tracks.

-Jonas

[Tom Porter]

Midi-2-Mockingboard Updated to v1.20 Download Link Below...
https://www.dropbox.com/s/z0ldxehkebwbfeg/MIDI%20TO%20MOCK%20VER1.zip?dl=0
(all old links point to the new updated converter)

List of improvements... Note Corrections between Octave 1-4... major Octave fixes at O5 and above.... a minor fix to note length conversions... a few more songs added to a second player disk (2 disks of samples). It doesn't sound like much but this was a huge internal upgrade. All old links will go to this new updated version... and many thanks to Open Apple PodCast for mentioning the converter in their new episode #70.

Special Thanks to Michael Apple-Win Developer for his octave correction work.

[Michael 'AppleWin Debugger Dev']

On Thursday, April 20, 2017 at 11:32:56 AM UTC-7, Tom Porter wrote:

Tom,

Looks good !

> List of improvements... Note Corrections between Octave 1-4... major Octave fixes at O5 and above.... a minor fix to note length conversions... a few more songs added to a second player disk (2 disks of samples).

Some questions/feedback:

* Were you going to include the original .MIDI songs so we can compare/contrast against?

* Any plans to increase the size of the 3 lines window? It seems a bit silly and cramped when we have 24 rows.

> Special Thanks to Michael Apple-Win Developer for his octave correction work.

Thanks for the mention -- that is always appreciated!

A couple of minor corrections:

* AppleWin is not hyphenated -- it is one word.
* My last name is Pohoreski -- I have no preference if you use my full name or my GitHub alias: Michaelangel007 -- your choice -- that's zero, zero, seven on the end, like Bond. :-) Just a FYI.

[Michael 'AppleWin Debugger Dev']

Tom,

You may want to include these fixes in the next revision of the "MIDI TO MICK README.txt" file:

* aquire, durrings, intergrated are all misspelt
* upto should be two words:
* Pokey should be capitalized
* Not everyone knows what the Pokey chip is.

Here is the first paragraph with all the above fixes:

- - - 8< - - -

MIDI files are from a bygone era. Synth Machines were all
the rage in the 1970's but were way too expensive. Computers were
quite primitive in the 70's as well, but as the 80's approached,
home users started to acquire personal computers that had dedicated
audio chips like the Pokey (Atari) or SID (C64) that allowed several sounds at the
same time. Most of these could even play music in the background
allowing for great user experiences during gameplay. A standard
was formulated as computer technology became more cookie-cutter, the
MIDI format was a music notation system that allowed for up to 16
instruments in a file, which was compatible with a whole host of
systems and even end user home synths and 'keyboards.' You could
have everything from a piano to drums to a xylophone and was
completely backward compatible, so when future instruments were
developed, they could easily be integrated into the already created
songs with simple commands.

- - - 8< - - -


Also, you want to briefly provide an introduction on why Mockingboard and MIDI even exist:

- - - 8< - - -

Before MIDI was invented in 1983 to standardize the playback of music the Mockingboard on the Apple 2 allowed 3-voice and 6-voice polyphony music which was a vast upgrade over the single channel speaker.

There were a few main problems with the Mockingboard design that allowed MIDI to become the dominant standard:

* Users had to specify notes with frequencies instead of a more convenient "Nth Note" or "Nth Key" on the instrument.
* The use of frequencies introduces errors due to the lack of precision -- the error gets worse the higher frequency due to the limited frequency reconstruction that the Mockingboard is able to do.
* There is no standard format -- such as note on, note off, etc. A Mockingboard "player" is expected to interpret, convert, or read the note data in a format that is friendly to the Mockingboard registers.

- - - 8< - - -

Michael

[Michael J. Mahon]

There's actually no comparison between MIDI, a fully general Musical
Instrument Digital Interface which was the first communication format to
bridge many proprietary formats and is still in wide use, and the
Mockingboard, which is a proprietary design based on a very limited sound
generation chip.

The "notes" for a Mockingboard are not frequencies, but times, specified as
16-bit counter values for the particular clock frequency driving the sound
generator chip(s) in a system--and therefore completely specific not only
to the chip, but to the system in which it is used.

Comparing MIDI to the Mockingboard is like comparing the alphabet to a
pencil! ;-)

[Michael 'AppleWin Debugger Dev']

I respectfully disagree.

A _historical_ context on how two, different, legacy systems both "play music" is indeed:

a) a comparison, and
b) relevant.

A new user won't understand _WHY_ the MIDI to Mockingboard converter even exists in the first place. A short blurb:

a) To let them know that the Mockingboard **pre-dates** General MIDI, let alone MIDI, provides the a context to answer the question.

b) Which question? Namely, the problem was: How does Apple 2 software/hardware play music? The Apple 2 Mockingboard was a proprietary, short-lived solution, due to design limitations. Since the Apple 2 can't natively play back MIDI files the data needs to be transcoded into a format that _can_ be played back by hardware that existed at the time -- specifically the Mockingboard which provides crude polyphony music.

Providing a quick summary introduction is valuable for those that aren't aware of the history, the context, the problem, and solutions.

> The "notes" for a Mockingboard are not frequencies,not frequencies, but times, specified as 16-bit counter values for the particular clock frequency driving the sound generator chip(s) in a system --

16-bit counter pedantry aside, at the end of the day that's what they are since Frequency is loosely equivalent to Time, but point taken.

> and therefore completely specific not only to the chip, but to the system in which it is used.

Right, that's one of the limitations.

> Comparing MIDI to the Mockingboard is like comparing the alphabet to a pencil! ;-)

The analogy isn't _that_ bad, since both DO produce polyphony music, but yeah, that's not a bad succinct summary.

[Michael J. Mahon]

Michael 'AppleWin Debugger Dev' <michael....@gmail.com> wrote:

> I respectfully disagree.
>
> A _historical_ context on how two, different, legacy systems both "play music" is indeed:
>
> a) a comparison, and
> b) relevant.

Well, as I tried to express, MIDI doesn't "play music" at all. It is simply
directs a "musical instrument" to play music.

The Mockingboard is one (rather limited) example of a "musical instrument"
that MIDI, either in real time or recorded in a file, can "play", given an
appropriate MIDI interpreter or converter.

You wouldn't compare sheet music to a trumpet, but MIDI is "sheet music"
and a Mockingboard is like (three to six) trumpets.

> A new user won't understand _WHY_ the MIDI to Mockingboard converter even
> exists in the first place. A short blurb:
>
> a) To let them know that the Mockingboard **pre-dates** General MIDI, let
> alone MIDI, provides the a context to answer the question.
>
> b) Which question? Namely, the problem was: How does Apple 2
> software/hardware play music? The Apple 2 Mockingboard was a proprietary,
> short-lived solution, due to design limitations. Since the Apple 2 can't
> natively play back MIDI files the data needs to be transcoded into a
> format that _can_ be played back by hardware that existed at the time --
> specifically the Mockingboard which provides crude polyphony music.
>
> Providing a quick summary introduction is valuable for those that aren't
> aware of the history, the context, the problem, and solutions.

I agree that some background is indeed useful, but putting things in the
proper perspective is an important part of that.

Recorded MIDI files are a great source of machine readable "sheet music"
for virtually any musical application, particularly polyphonic ones. That's
why I wrote CVT.MIDI--to provide a ready source of polyphonic music for the
AppleCrate 16-voice synthesizer. Because of the wide range of music
available in MIDI format, I recommend it for such purposes.

>> The "notes" for a Mockingboard are not frequencies,not frequencies, but
>> times, specified as 16-bit counter values for the particular clock
>> frequency driving the sound generator chip(s) in a system --
>
> 16-bit counter pedantry aside, at the end of the day that's what they are
> since Frequency is loosely equivalent to Time, but point taken.

Sorry it came across that way, but both the 16-bit precision of the
half-period time and the fact that it's a time, not a frequency, is *very*
relevant.

If frequencies could be specified to 1Hz precision, the Mockingboard could
provide excellent note accuracy. But since half period times are specified,
the counts are small for higher octaves, and the frequency resolution is
quite poor. This results in the Mockingboard being annoyingly out of tune
above the middle octaves, though the low octaves are accurate. (The usual
speaker tone routines for the Apple II suffer from the same problem.)

Unfortunately, the human ear is relatively insensitive to low frequency
inaccuracy, but very sensitive to mid-to-high frequency inaccuracy, so
specifying frequencies by half-period timing with a relatively low clock
frequency (to allow 16 bits to specify low frequencies) results in a pretty
limited "musical instrument", though it's accurate enough in the middle
octaves where it matters most.

>> and therefore completely specific not only to the chip, but to the
>> system in which it is used.
>
> Right, that's one of the limitations.
>
>> Comparing MIDI to the Mockingboard is like comparing the alphabet to a pencil! ;-)
>
> The analogy isn't _that_ bad, since both DO produce polyphony music, but
> yeah, that's not a bad succinct summary.

In hindsight I prefer the sheet music to musical instrument analogy. ;-)

I also think that the ready availability of an IRQ-driven polyphonic
Mockingboard player for the Apple II, plus a fair amount of MCS music,
makes a strong case for converting MIDI or whatever to the MCS music
format, with percussion extensions, if desired.

In any event, have fun making music with the Apple II--it's capable of
great things! The Mountain Computer Music System is a fine example of what
can be done with hardware extensions, and RT.SYNTH and DMS.DRUMMER are good
examples of what can be done with just the native hardware.

[STYNX]

On Saturday, April 22, 2017 at 1:21:00 AM UTC+2, Michael J. Mahon wrote:
> In any event, have fun making music with the Apple II--it's capable of
> great things! The Mountain Computer Music System is a fine example of what
> can be done with hardware extensions, and RT.SYNTH and DMS.DRUMMER are good
> examples of what can be done with just the native hardware.

Thats exactly right :-)

Both means to produce music have their right to be used and enjoyed. The 'native' sound generator shows the ingenuity of the programmer whereas the sound/music card approach is valid as well since the Apple II was intended to be expanded and shows the possibilities the hardware has to offer.

... The Apple II grows with/on you.

.Jonas

[Tom Porter]

Wow, didn't expect a lot of nit picking on my user manual... I know there are a few minor spelling errors but gee... lol.

In reality... when I bought my own mockingboard (from the great A2HEAVEN website... I didn't have much use for it. I decided I would make something for myself, and it just so happens that I gave it out for other people to use. I previously created my own MIDI converter for beep music for the Apple II and its been an on and off again development from 2014. My main problem was not the exactness of the conversion, but trying to have several tracks boiled down into one beep at a time music. Its been somewhat successful but the formulas for the boiled down beeps have only varied results, some songs come out great... some are total crap.

I took all this work and focused it towards mockingboard, once I had a reason to (aka buying one). I am very happy that all that formula work was completely cut out, and the music can be a lot better with a lot less work.

Even if I do spend way too much time in front of a basic prompt or an assembler, it still is only a hobby!

I haven't addressed any of the above info because I'm carefully digesting it, and going to make future improvements based on the information above.

That being said... I could not figure out MCS even with spending time working on disassembling and acquiring all the available information on the internet about MCS. I could not make something truly working... so I decided to scrap MCS format and even the MCS driver and start from scratch. I think the end result is pretty good, although it still needs voices and irq... am working on it... should have an update for you in a couple of weeks that will address both concerns.

NOW... if anybody does have MCS information and can give me the specs how to make NOTE/OCTAVES/NOTE LENGTHS that the MCS driver can read/use, I will be more than happy to work with you to get my midi converter to output to that format so everything can be turnkey in (like a week!) instead of the drudgery of forging my own path thru this mess. I'm not the best assembly programmer.

I also am working on the SFX multi-tasking 1bit audio engine (featured in DogFighters of Mars2 and SFX Breakout)... and I think that is somewhat revolutionary, its an added plus it works without extra hardware. I am busy building SFX Version 2 which will eliminate the huge memory requirements!

[Michael 'AppleWin Debugger Dev']

On Sunday, April 23, 2017 at 5:34:36 PM UTC-7, Tom Porter wrote:
> Wow, didn't expect a lot of nit picking on my user manual... I know there are a few minor spelling errors but gee... lol.

That wasn't nitpicking. If it was I would have corrected the WHOLE dam thing. :-)

Instead of focusing on the messenger, focus on the message. Namely, all the blatant spelling mistakes:

* makes it extremely hard to read, and
* makes you look like either
a) an amateur, or
b) a foreign speaker.

In either case it makes the project look unprofessional. Having some basic spelling and grammar goes a LONG way.

Now, if you want, I _could_ clean up the whole documentation. ;-)
At least that way _I_ would stop bitching about it. :-)

Cheers