Let there be Music! Hydra Dense Music Format (HDMF) demo.
epmoyer
Posts: 314
I hate electronic music. I’m not talking about Herbie Hancock’s “Rockit” , the creative musings of Imogen Heap, or even Elevator Musak. I mean the intolerable drivel spewed forth from what today seems like every greeting card, Christmas ornament, children’s toy and breakfast cereal on the market. Grating insidious music that pounces viciously upon your ears with overtone soaked square waves of despair. Music without dynamics. Without polyphony. Without a soul.
The Hydra deserves better than that.
In response, I give you HDMF (Hydra Dense Music Format).
The HDMF project began as the desire to add good music to SpaceWar!, and became an engine for converting MIDI data to a compact form which could be effectively rendered by Nick Sabalausky’s sound driver.
The road has been long and hard, and there is much to tell, but for now here are two demo’s of HDMF in action (attached). Enjoy!
HDMF Features:
MIDI TRANSLATION:
MIDI data can be translated into HDMF very efficiently. This was the _most_ important feature in my mind. I wanted to be able to compose the music for SpaceWar! in an external toolset and then import it into the game, using all the musical goodness that MIDI has to offer (polyphony, velocity, time granularity, etc.). I have written a Windows application called the “HDMF Converter” which translates MIDI data into HDMF.
The demo examples were all generated by using the HDMF Converter to translate “industry standard” MIDI files downloaded from the web. Other than shifting the frequency of the bass line in the ms-pacman theme up an octave (which I did with a 3rd party tool), all the examples are translated directly using the HDMF converter with no other intervention.
The HDMF converter outputs ‘DAT’ section code which can be cut and pasted directly into the Propeller IDE. In a nutshell, it’s quick and painless.
NICKOPHILIC:
I am a “Nicophile”; I just love Nick Sabalausky’s fabulous Hydra sound driver and I can’t say enough good things about it. HDMF was written to bolt directly into Nick’s driver, in that the format can be readily translated into PlaySoundFM() calls. As Nick’s driver grows and changes in the future, HDMF will have an easy time picking up the new features and remaining compatible.
POLIPHONY:
The HDMF format (yes, I realize that is redundant [noparse]:)[/noparse] supports up to 8 voice polyphony. Today the HDMF Converter limits file generation to 6 voices, because that is what Nick’s sound driver currently supports.
FINE TEMPORAL GRANULARITY:
Part of what makes MIDI sound so good (and RTTTL sound so lifeless) is that RTTTL only specifies note start times and durations on fixed time boundaries (quarter notes, half notes, etc.). MIDI allows note start and end times to be specified with typically 96 divisions per quarter note (although the spec supports other divisions). HDMF specifies note start times and durations on a 10msec boundary, allowing the human aspects of a performance to come through.
“VELOCITY” CONTROL:
Like MIDI, HDMF stores the volume (or “velocity”[noparse];)[/noparse] of each note separately, so that performance dynamics can be expressed. HDMF currently uses 6 bits of velocity information (MIDI uses 8).
“FREQUENCY” CONTROL:
HDMF is currently capable of playing notes at arbitrary frequencies. This potentially allows the encoding of pitch bend and detune effects. Frequencies are currently stored as 13 bits. Just storing the MIDI note values would have taken 7 bits, so this is a possible extravagance. I could have decided to encode note values instead and save 6 bits in the protocol at the expense of creating a 256 byte frequency lookup table in the code. I think I chose wisely, but I’m willing to debate this point.
INSTRUMENTS:
HDMF supports the declaration of 8 playback “Instruments”, where each instrument is defined by a “wave shape” and an “amplitude envelope” (as defined/implemented in Nick’s sound driver). Any of the 8 playback instruments can then be assigned to each playback note. The current demos do not yet take advantage of this feature (all notes are played using a sine wave shape and a default envelope).
I intend to explore the possibility of supporting PCM “instruments” for (limited) percussive effects. PCM data tends to be large, so I don’t anticipate people wasting the data space for whole drum kits or anything, but a single snare or wood block might be fun if the data set were small.
SIMPLICITY:
HDMF is simple. The current playback engine is written in 28 lines of spin code and runs in its own cog.
DENSITY:
For the features it aims to support, HDMF is very dense. Each note takes either 5 or 6 bytes to represent (Notes played shorter than 1.28 seconds take 5 bytes, longer notes take 6)
GRACEFUL DEGRADATION:
The HDMF Converter does its best to render MIDI into HDMF using the channels you give it. If you want 4 channels for music and 2 left over for game sound effects, then you crank the HDMF Converter down to 4 channels and let it rip. As gracefully as possible the converter will attempt to squeeze your MIDI data into the available channels, cutting notes short if necessary. Of course, it you want a superior experience you should compose/choose music that meets your design constraints.
HDMF Demo Operation:
Press up and down on gamepad 0 to select a song.
Press ‘A’ to play the selected song.
The song length in bytes is displayed to the left of each song.
After starting a song the menu will not respond until the song completes (I haven’t implemented a “stop song” call yet, so I sit and wait for the song to finish).
What’s Next:
The demos are being released in binary format for now (i.e. without source code) because HDMF is still in a state of flux. As I complete the music composition for SpaceWar! I will tweak the HDMF protocol accordingly so that it meets the needs of real game design.
Immediately after the next SpaceWar! release I will release an HDMF package with demos, demo source code, the HDMF Converter, the HDMF converter source code, and an HDMF specification document (so you can see the guts of the storage protocol).
Post Edited (epmoyer) : 5/13/2007 6:53:14 PM GMT
The Hydra deserves better than that.
In response, I give you HDMF (Hydra Dense Music Format).
The HDMF project began as the desire to add good music to SpaceWar!, and became an engine for converting MIDI data to a compact form which could be effectively rendered by Nick Sabalausky’s sound driver.
The road has been long and hard, and there is much to tell, but for now here are two demo’s of HDMF in action (attached). Enjoy!
HDMF Features:
MIDI TRANSLATION:
MIDI data can be translated into HDMF very efficiently. This was the _most_ important feature in my mind. I wanted to be able to compose the music for SpaceWar! in an external toolset and then import it into the game, using all the musical goodness that MIDI has to offer (polyphony, velocity, time granularity, etc.). I have written a Windows application called the “HDMF Converter” which translates MIDI data into HDMF.
The demo examples were all generated by using the HDMF Converter to translate “industry standard” MIDI files downloaded from the web. Other than shifting the frequency of the bass line in the ms-pacman theme up an octave (which I did with a 3rd party tool), all the examples are translated directly using the HDMF converter with no other intervention.
The HDMF converter outputs ‘DAT’ section code which can be cut and pasted directly into the Propeller IDE. In a nutshell, it’s quick and painless.
NICKOPHILIC:
I am a “Nicophile”; I just love Nick Sabalausky’s fabulous Hydra sound driver and I can’t say enough good things about it. HDMF was written to bolt directly into Nick’s driver, in that the format can be readily translated into PlaySoundFM() calls. As Nick’s driver grows and changes in the future, HDMF will have an easy time picking up the new features and remaining compatible.
POLIPHONY:
The HDMF format (yes, I realize that is redundant [noparse]:)[/noparse] supports up to 8 voice polyphony. Today the HDMF Converter limits file generation to 6 voices, because that is what Nick’s sound driver currently supports.
FINE TEMPORAL GRANULARITY:
Part of what makes MIDI sound so good (and RTTTL sound so lifeless) is that RTTTL only specifies note start times and durations on fixed time boundaries (quarter notes, half notes, etc.). MIDI allows note start and end times to be specified with typically 96 divisions per quarter note (although the spec supports other divisions). HDMF specifies note start times and durations on a 10msec boundary, allowing the human aspects of a performance to come through.
“VELOCITY” CONTROL:
Like MIDI, HDMF stores the volume (or “velocity”[noparse];)[/noparse] of each note separately, so that performance dynamics can be expressed. HDMF currently uses 6 bits of velocity information (MIDI uses 8).
“FREQUENCY” CONTROL:
HDMF is currently capable of playing notes at arbitrary frequencies. This potentially allows the encoding of pitch bend and detune effects. Frequencies are currently stored as 13 bits. Just storing the MIDI note values would have taken 7 bits, so this is a possible extravagance. I could have decided to encode note values instead and save 6 bits in the protocol at the expense of creating a 256 byte frequency lookup table in the code. I think I chose wisely, but I’m willing to debate this point.
INSTRUMENTS:
HDMF supports the declaration of 8 playback “Instruments”, where each instrument is defined by a “wave shape” and an “amplitude envelope” (as defined/implemented in Nick’s sound driver). Any of the 8 playback instruments can then be assigned to each playback note. The current demos do not yet take advantage of this feature (all notes are played using a sine wave shape and a default envelope).
I intend to explore the possibility of supporting PCM “instruments” for (limited) percussive effects. PCM data tends to be large, so I don’t anticipate people wasting the data space for whole drum kits or anything, but a single snare or wood block might be fun if the data set were small.
SIMPLICITY:
HDMF is simple. The current playback engine is written in 28 lines of spin code and runs in its own cog.
DENSITY:
For the features it aims to support, HDMF is very dense. Each note takes either 5 or 6 bytes to represent (Notes played shorter than 1.28 seconds take 5 bytes, longer notes take 6)
GRACEFUL DEGRADATION:
The HDMF Converter does its best to render MIDI into HDMF using the channels you give it. If you want 4 channels for music and 2 left over for game sound effects, then you crank the HDMF Converter down to 4 channels and let it rip. As gracefully as possible the converter will attempt to squeeze your MIDI data into the available channels, cutting notes short if necessary. Of course, it you want a superior experience you should compose/choose music that meets your design constraints.
HDMF Demo Operation:
Press up and down on gamepad 0 to select a song.
Press ‘A’ to play the selected song.
The song length in bytes is displayed to the left of each song.
After starting a song the menu will not respond until the song completes (I haven’t implemented a “stop song” call yet, so I sit and wait for the song to finish).
What’s Next:
The demos are being released in binary format for now (i.e. without source code) because HDMF is still in a state of flux. As I complete the music composition for SpaceWar! I will tweak the HDMF protocol accordingly so that it meets the needs of real game design.
Immediately after the next SpaceWar! release I will release an HDMF package with demos, demo source code, the HDMF Converter, the HDMF converter source code, and an HDMF specification document (so you can see the guts of the storage protocol).
Post Edited (epmoyer) : 5/13/2007 6:53:14 PM GMT
Comments
One would have to write a "loader" application either on the PC on as a separate Hydra app that would jam the music data into high memory on the EEPROM, and then you could stuff the game app in the lower 32K as usual via the IDE.
Does anyone know if the IDE erases the whole EEPROM on a software image load, or just the bottom 32K?
It's called the Hydra Asset Manager. Using the windows tool you upload data in the unused portion of eeprom and i think some of the hydra demos already using code for accessing it. Not that it would be difficult for a programmer of you skill to do it anyway.
Damo
Edit: Go to the very last post for the latest version 1.06 instead for the first download which is 1.04.
I was unaware of the asset manager and it looks like just what I need. I'll start experimenting with moving HDMF music assets into upper memory on the EEPROM. I'm practically giddy at the potential I see here for putting large complex music pieces into games. Even something as huge and complex as the piece "Sunday" from Demo 2 would only take up 8 out of the available 96K!
I've not looked at the sound possibilities of the Hydra yet. Would I be right in thinking that to use this would need 2 cogs? 1 for the HDMF player and one for Nick Sabalausky’s sound driver?
Keep up the good work [noparse]:)[/noparse]
Damo
The HDMF engine spends a lot of time idle, waiting on the system counter to time the next PlaySoundFM call, but the overhead will increase as I add the EEPROM code and move song assets into upper EEPROM memory using HAM.
If Nick's engine takes 1, then the combination will no doubt take 2, but if Nick's takes 2 then perhaps the possibily exists to merge HDMF into Nick's driver and still live in 2. Again I'll check it out when I get back.
But, this midi system will surely come in handy!
Andre'
Listen to (HSS).
This is a song I wrote not that long ago that I'm going to release and upload onto the (HSS) site soon.
The above song is less then 4k in size and not only has musical data, but also small audio samples.
Just listen to the drum kit and machine noise in the background, all of which are samples. Even the little synth lead and bass gutiar are sampled.
The lead is sampled from my old 1972 ARP Odyssey. While the bass is sampled from a 1960s Fender Precision.
(HSS) supports MOD music playback along with 2 channels of Sound FXs and even compressed ADPCM SAMPLE playback all at the same time.
I really got to release more docs on it though. I promiss I will soon. [noparse]:)[/noparse]
Now seeing how the Hydra is starting to take off there is more incentive to do so now then ever before!
If anyone is interested in adding music to their program or game all they got to do is send me an e-mail or PM. [noparse]:)[/noparse]
Epmoyer, I wanna hear your engine. [noparse]:)[/noparse]
Can you post a Mp3 recording of a song?
Thanks!
--Andrew Arsenault.
I will shoot to post an MP3 tonight.
I'm a chiptune junky, So I'm excited to hear what your new engine sounds like! *smiles*
6 channels is a lot! [noparse]:)[/noparse]
www.yvan256.net/soundcards/samples/Ultima_6_-_Create_a_new_character_-_Game_Blaster.mp3
The two sound chips used where both SAA1099(s) made by Philips.
"Creative Music Systems" later changed their name to "Creative Labs" afterwards.
Does your engine allow for other waveforms? Like sqr-wave or saw-wave? [noparse]:)[/noparse]
If it does then that would be GREAT!
Sine-waves make for great electronic pianos, flutes and some wood winds.
Saw-waves makes for nice string instruments.
Sqr-wave works fell for some piano sounds and brass. [noparse]:)[/noparse]
It sounds good though! As a trained composer and musician, I do like the level of expression in the playback engine!
--Andrew Arsenault.
(ps) Tron's composer "Wendy/Walter Carlos" did some really interesting compositions in the late 60s of synthetic music on a early prototype of the Moog.
Especially the Mario tune brought a smile to my face! it's perfect!
For most games this engine would be wonderfull for the background music, however I wonder.... what about the sound effects of a game (like explosions, gunshots, "lasers" etc etc,)?
I imagine this engine is not suitable for that, and in that case how can sound effects be mixed to the same audio output?
Ideally the music sound engine should also include a "channel" that can do sound effects, or otherwise somehow it should be able to co-operate with another cog that creates the sound effects, and would take it's audio output and mix it with the music.
Just my two cents...
Mahjongg
Andrew,
Yes sine, square, saw, and triangle waveforms are supported. HDMF is really a front end to Nick Sabalausky's 6 channel sound driver which ships on the CD with the Hydra. The HDMF format allows you to specify 8 "instruments" for a given song, where each "instrument" can be either a synthesized voice (sine, saw, etc. with an amplitude envelope similar to an ADSR model, per Nick's driver) or a PCM sample.
Nick's driver doesn't support playing back PCM samples at different frequencies, so it is not (currently) possible to use PCM samples as flexible sampled instruments, since you can only get one note out of them. PCM samples today are best suited for game sound effects and percussion.
The ability to use sampled instruments is what makes your driver look appealing to me. I'll noodle around with some demos and see what I can pull off.
Mahjongg,
HDMF is really a note playback engine which feeds Nick's driver. The HDMF converter is like a "note scheduler" that takes MIDI data and produces a schedule of when each note should be played and what channel to play it on. It is possible to tell the HDMF converter to work with a limited number of channels, so if you were making a piece of game intro music you might choose a complex piece with 6 voice polyphony an have the HDMF converter render it into 6 channels. For an in-game piece of music you would generally set the HDMF converter to 4 channels and choose/write a piece of music that stuck to 4 voice polyphony (if the MIDI data has places where 5 notes play at the same time, for instance, the HDMF converter will schedule a stop of the first one to play the 5th one, so you will only ever use the requested 4 channels and will only ever hear 4 voice polyphony). That would leave 2 channels available for game sound effects, which could be synthesized sounds or PCM samples.
Some odds and ends:
There may be some process / cog interoperability issues for me to work out. I am about to put the system to the test in SpaceWar! so I'll end up doing whatever is necessary to allow the game to make sound effect play calls on 2 channels while the HDMF engine is making music calls on the other 4. As a game author you can slice that pie up however you like; n-channel music and 6-n channel game effects.
I am going to modify the HDMF converter’s note scheduler so that it favors lower channel numbers and tries to stuff all the notes there. That way if you convert a piece of music which uses 4 voice polyphony then channel 4 would only ever get used when 4 notes were actually playing simultaneously. Then I could create a mechanism for a game's sound FX engine to temporarily "borrow" a channel from the music engine when it needs to play more FX that the "normal" channel allotment. For example, imagine SpaceWar had 4 channel music and 2 channel SFX. Channels 1-4 are music, 5-6 are sounds for ship 1 and ship 2 SFX respectively. Now, say someone enables their shield and the game engine wants to play a shield sound (which occurs relatively infrequently in the game), but doesn’t want to stop the "photon torpedo" sounds already playing on 5 and 6, it could temporarily "borrow" channel 4 to play the shield sound. While the shield sound was playing you would loose part of the music, but since the music playback was scheduled to use lower channels first (and only use higher channels when multiple notes were playing), channel 4 would only be used when 4 voices were playing simultaneously, so all you loose during the shield sound is one note of a 4 part harmony.
I figured out the Hydra Asset Manager (HAM) last night and got a little snippet of HDMF music to play out of high (>32K) EEPROM memory. Now I need to see if I can make the EEPROM reader re-fill the HDMF playback buffer full fast enough to play an entire song from EEPROM. Right now I’m using Nick’s EEPROM driver in a separate cog (because that’s an easy place to start), but once I get it working that way I’ll pull his code into the HDMF cog and try to get the HDMF engine with high-mem EEPROM playback running in just a single cog.
Enjoy.
Write these values into the array that the audio engine peeks into.
long snd_chl1_wavptr 'Pointer to HUB sample address write-only
long snd_chl1_wavend 'Length of sample write-only
long snd_chl1_wavloop'Loop point of sample write-only
long snd_chl1_freq 'Playback Frequency write-only
long snd_chl1_keyon 'Playback Amplitude / Keyon write-only
long snd_chl1_wave 'Channels Audio Out read-only
long snd_chl1_offset 'Samples playback Position read-only
long snd_chl1_counter'Channels Freq Accumulator read-only
long snd_chl2_wavptr 'Pointer to HUB sample address write-only
long snd_chl2_wavend 'Length of sample write-only
long snd_chl2_wavloop'Loop point of sample write-only
long snd_chl2_freq 'Playback Frequency write-only
long snd_chl2_keyon 'Playback Amplitude / Keyon write-only
long snd_chl2_wave 'Channels Audio Out read-only
long snd_chl2_offset 'Samples playback Position read-only
long snd_chl2_counter'Channels Freq Accumulator read-only
long snd_chl3_wavptr 'Pointer to HUB sample address write-only
long snd_chl3_wavend 'Length of sample write-only
long snd_chl3_wavloop'Loop point of sample write-only
long snd_chl3_freq 'Playback Frequency write-only
long snd_chl3_keyon 'Playback Amplitude / Keyon write-only
long snd_chl3_wave 'Channels Audio Out read-only
long snd_chl3_offset 'Samples playback Position read-only
long snd_chl3_counter'Channels Freq Accumulator read-only
long snd_chl4_wavptr 'Pointer to HUB sample address write-only
long snd_chl4_wavend 'Length of sample write-only
long snd_chl4_wavloop'Loop point of sample write-only
long snd_chl4_freq 'Playback Frequency write-only
long snd_chl4_keyon 'Playback Amplitude / Keyon write-only
long snd_chl4_wave 'Channels Audio Out read-only
long snd_chl4_offset 'Samples playback Position read-only
long snd_chl4_counter'Channels Freq Accumulator read-only
long snd_chl5_wavptr 'Pointer to HUB sample address write-only
long snd_chl5_wavend 'Length of sample write-only
long snd_chl5_wavloop'Loop point of sample write-only
long snd_chl5_freq 'Playback Frequency write-only
long snd_chl5_keyon 'Playback Amplitude / Keyon write-only
long snd_chl5_wave 'Channels Audio Out read-only
long snd_chl5_offset 'Samples playback Position read-only
long snd_chl5_counter'Channels Freq Accumulator read-only
long snd_chl6_wavptr 'Pointer to HUB sample address write-only
long snd_chl6_wavend 'Length of sample write-only
long snd_chl6_wavloop'Loop point of sample write-only
long snd_chl6_freq 'Playback Frequency write-only
long snd_chl6_keyon 'Playback Amplitude / Keyon write-only
long snd_chl6_wave 'Channels Audio Out read-only
long snd_chl6_offset 'Samples playback Position read-only
long snd_chl6_counter'Channels Freq Accumulator read-only
long dpcm_start
long dpcm_length
long dpcm_offsetval
long dpcm_freqval
long dpcm_amp
I'm looking forward to playing with your converter.
I've got some .SID stuff I've converted to .midi and
I'm curious to see how your tool works on them!
I know that in reality the Hydra really has 1 sound
connection (pin 7 IIRC) but has there been any thought
to stereo output on a free pin? Take it from 8 to 16 voices?
Perhaps just a second copy on another cog would get the job done.
It' nice that you've adapted this to work with Nick's driver,
this starts to establish some "standards" -- [noparse]:)[/noparse]
Oldbitcollector
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The comments and code above are proof that a million monkeys with a million propeller chips *could* write Shakespeare!
I now can (rather disturbingly I must say) play SpaceWar! with the theme from mario bros. cycling endlessly in the background. I also have a new version of the demo working where the menu is always "live" and songs can be started/stopped at any time. If a song is currently playing when a play_song() call is made, the driver will automatically stop the current song and start playing the new one. I also discovered that it sounds best to finish queuing all notes of a chord into the sound driver before stopping a song in progress; otherwise you hear only part of the last chord which makes the hanging notes sound very unintentional.
Next on deck is to add support for passing play_song() a pointer to a song asset in upper EEPROM and having it play the song from there. My first pass at that will use an extra cog (running Nick's EEPROM driver), and then once I get that working I'll try to merge bits of his driver into mine and get EEPROM HDMF playback working just one cog (that is, one cog plus the cog running Nick's sound driver).
The current version of the HDMF driver occupies about 520 bytes.
Version 0.2 of Demo 1 is attached. Press 'A' to start a song and 'B' to stop the song in progress. You can start and stop songs Willie Nillie now.
There is an occasional bug where a EEPROM song may fail to start properly if you start it while another one is playing. I'll have to chase that one down later on.
You'll need HAM (the hydra asset manager) to load the attached .eeprom file. Get the latest version (currently 1.06) from the HAM discussion thread here:
http://forums.parallax.com/showthread.php?p=628778
(Make sure you go down to the last page of postings and get the most recent version.)
H.A.M. Load procedure:
1) Load the HAM driver into your the propeller IDE and run it (benson_ham_driver_1_06.spin). You'll see a load screen appear on your Hydra TV, and it will say "Waiting".
2) Run the Hydra Asset Manager windows application.
3) Set the com port to the port your Hydra is attached to.
4) Drag the attached file (HDMF_Demo3_128K_HAM_image.eeprom) into the "Memory Map" window in the HAM windows application
NOTE: There is currently a small bug in HAM which means you have to drag the EEPROM file to a point just above the black "Memory Map" box (otherwise it will show you an error near the bottom of its screen saying that the asset "doesn't fit"). If you get the error just try again until you get it to drop in.
5) Click "Upload to Hydra"
6) When the upload is complete you will get a "Programming complete" message from HAM.
7) Reset your Hydra and the Demo will start
The demo lists the song sizes, in bytes, and lists whether they will be played from RAM or EEPROM. Up/Down (gamepad) to select a song. A to play. B to stop.
Coming into the home stretch now....
HDMF is almost ready for a source release so you can all play with it.
Up next: 1) Integrate EEPROM driver into HDMF driver to free up a cog. 2) Add some instrument / transpose / envelope controls into the HDMF converter application 3) Write some documentation for the HDMF format and use of the Converter App 4) Add music to spacewar! 5) Release spacewar! with music 6) Release HDMF Source.
If you ask nicely I'll swap 4 and 6 so you can play with it sooner
In fact I took this as a prompt to try out HAM for the first time and that's great stuff too.
Does HDMF download the music from high eeprom to RAM to play, or play it straight from high EEPROM?
I'm very glad that the HDMF release is getting some people to try out HAM; hopefully as more of us use it HAM will become a standard and over time I suspect it will become both easier to use (for end users installing HAM enabled hydra projects) and more convenient to release projects in. I've found it a piece of cake to develop with, though it would be nice if it evolves to support some kind of asset directory so that you don't have to hard code the memory locations of your assets and keep updating them as they move about during development. Still, that's just icing on the cake; its quite usable (and fantastic to have) as is.
Yes, the current version buffers EEPROM data into a circular 32 byte buffer in RAM. The buffer is divided into two “banks” and I call Nick’s EEPROM driver to pre-fetch a bank once all the notes in it have been played.
The upcoming version will incorporate the relevant pieces of Nick’s EEPROM driver into the HDMF_Player cog. My belief is that the EEPROM reads happen so fast relative to note playback speeds that I will be able to just fetch a note at a time from EEPROM into a 6 byte buffer. I think that even for chords where multiple notes are scheduled to play at the same time you won’t be able to hear the fetch delay. I expect to give it a shot this evening, so I’ll let you all know.
I'm afraid that's just too much fun not to go ahead and do. I'm in.
I will also be releasing source for a "HDMF Light" implementation which will allow HDMF music to be played from RAM only (not EEPROM) using only a single cog (Nick's sound driver) provided that the application's main loop rate is sufficiently high to service the playback.
I got the first pieces of the "Live Player" (formerly "Slave Player" above) working, in as much as I can send serial data from the Converter app and receive it with the new Live Player app. Now I need to make up a little serial protocol, send real music data over, and implement some start/stop/rewind/forward controls so that you can preview HDMF pieces easily. The Live Player will allow me to test out the last remaining unimplemented feature in the HDMF driver (instrument support), and then the driver will be done.
Hurrah!!! You may have just saved my project!
Well you were the inspiration for the "HDMF Light" player! I figured it was worth formalizing since undoubtedly other projects will end up in a similar boat (i.e. needing some music with only one cog to spare). I'll throw together an HDMF Light demo like the others when it's ready; and I figure I might as well use a few DK music clips for it.
You can now modify the waveform / envelope settings, click "Send to Live Player" on the main form, and immediately hear what the song sounds like with the current configuration options.
I also started writing the User's Manual, which is about 1/4 done.
It's time to make myself a to-do list of essential tasks that need completion for the first release and just start banging them out. All the fundamental pieces are there now.
Time for bed!
Post Edited (epmoyer) : 5/20/2007 7:20:35 AM GMT
I wanna hear.
Some odds and ends:
The first release of the HDMF driver will still require 3 cogs (HDMF player, EEPROM driver, Sound Driver). A second release will follow sometime thereafter which will eliminate the need for the second (EEPROM) cog. The reason? I expected to use Nick's cogless EEPROM driver but the HDMF player is written in SPIN and the cogless EEPROM driver is in ASM. I figured I'd just call the ASM from my spin but I realized today that you can't really do that! It seems obvious to me now, but of course the cog's internal memory is full of the spin interpreter, so there is no way to "jump" to a snippet of ASM from SPIN. I never really noticed that before about the propeller architecture, but now it makes sense. Any time you execute ASM code, you do it by starting it up in a new cog. The solution? I'll write a EEPROM driver in SPIN. Why? Its much easier than writing the HDMF player in ASM, and I should have plenty of time (believe it or not) to load from EEPROM using SPIN. Just for reference, I can blast those fast ragtime pieces from the demos at 10x playback speed today with no problem, so there's lots of spare time in the HDMF driver.
The HDMF player now supports looping (i.e. you can play a snippet of music and set the "loop" flag to have it play over and over).
The HDMF converter now supports transposition (track (by octaves) and global (by half steps)) and tempo modification.
Definitely in the home stretch now. I'll have a release out some time this week.