Thanks for some documentation. I started deconstructing a coupla times, but very likely ran into the lack of motivation problem myself. That might kick start doing some music.
I remain really eager to compose some chip tunes on Retronitus. Maybe even build an instrument interface or two. Doing that has been on "that list" for a long time! I hope "out of office" means good things Ahle2.
Ahle2: What type of bug... Can any of us help? I often found that I could locate a by discussing with others, who actually may not even understand it.
I would guess it's a wild pointer somewhere in combination with some kind of memory leak. It's hard debug becuase of the "random nature" of this bug.
It may actually not be that hard to fix, but it still drains my motivation since my last session was futile. I spent hours without getting any result.
P.S. is possible make simple FM synthesis on propeller chip ? your next project ? :-)
Of course it is; Aribas FM synth is an excellent example of that.
I will do a phase distortion synth for the Propeller some day. It sounds like something in between FM synthesis and subtractive synthesis.
It's not very cycle intensive unlike subtractive synthesis. And it still sounds more analog (that's a good thing in synth land) than FM syntesis.
I would guess it's a wild pointer somewhere in combination with some kind of memory leak. It's hard debug becuase of the "random nature" of this bug.
It may actually not be that hard to fix, but it still drains my motivation since my last session was futile. I spent hours without getting any result.
Have you tried Valgrind? It's an incredibly effective pointer/memory debugger. Any bad frees, data used after free, etc, will be recorded in a format that's very easy to interpret/parse. From there you can probably drop down to the line number of the problem.
I would guess it's a wild pointer somewhere in combination with some kind of memory leak. It's hard debug becuase of the "random nature" of this bug.
It may actually not be that hard to fix, but it still drains my motivation since my last session was futile. I spent hours without getting any result.
Ahle2, I've been really stumped before by an intermittent bug that was very hard to diagnose in graphics.spin. It turned out to be an issue with messaging between cogs via hub ram. I think I was reloading a buffer before another cog had finished picking up its contents. It was very hard to discover, but once found, it cleared up all the mess and things worked perfectly. Concurrent processing bugs can really blindside you. Have you tried your code on more than one Propeller chip?
@Chip
The sequencer isn't running on the Prop itself. It's a QT application running on the PC. It would have been really cool to make some kind of music editor running on the Prop some day though.
I think that some kind of tracker is more suitable since a mouse driven sequencer might be hard to achieve on the Prop itself.
Btw, I have some awesome ideas for Retronitus on the Prop 2. With that much power in a single cog I will be able to do some things that's impossible on the Prop 1. (OOOps, I said impossible..;) )
Can't wait to push the Prop 2; But I'm afraid that I will be late to the game since it's likely to come to Sweden at a much later time with a much higher price tag.
Ahle2: Perhaps it's may be too hard for Parallax who will be busy with the P2 launch. But I am sure there are many in the USA that would do you a favour and post you P2 chip(s) at cost.
What we really need is someone in China to post them out - postage is rediculously cheap there.
It would have been really cool to make some kind of music editor running on the Prop some day though.
I think that some kind of tracker is more suitable since a mouse driven sequencer might be hard to achieve on the Prop itself.
I've been experimenting with a tracker for the Touchburger boards Doc and I have been working on. I've hit a bit of a brick wall trying to figure out the storage of notes. Midi files do not seem to be a good format since they are not easily edited. Maybe some advice from the guru's would help!
Ahle2: Perhaps it's may be too hard for Parallax who will be busy with the P2 launch. But I am sure there are many in the USA that would do you a favour and post you P2 chip(s) at cost.
What we really need is someone in China to post them out - postage is rediculously cheap there.
When we have chips/boards, we'll probably pick several dozen people on the forums to send them to. Don't worry.
I've been experimenting with a tracker for the Touchburger boards Doc and I have been working on. I've hit a bit of a brick wall trying to figure out the storage of notes. Midi files do not seem to be a good format since they are not easily edited. Maybe some advice from the guru's would help!
I have made some experiments with playing several samples together direct from the SD card. Last week I began a little tracker with the Amiga MOD format. This format needs only 4 channels (tracks) to play at the same time. This description helped me a lot: http://www.mediatel.lu/workshop/audio/fileformat/h_mod.html
The attached picture shows the TV screen of my tracker. I can only edit the current pattern for now, it's mainly meant to test the player. A full editable tracker, including sample editor is a challenging job on a propeller, but not impossible.
So far some MOD files play really well, others have some problems with the sample loops. I will see if I can improve that, otherwise I will switch to a SPI Flash as sample memory.
Very nice to know Andy! I'll check out the format a bit later but it sounds like a good start.The touchburger boards have 1M SRAM with slightly better performance than SPI Flash, according to early tests with XMM drivers. If you're interested I have a couple extra boards.
@Ariba
That's great news! Do you want to share your code?
An amiga style module player/editor has been on my list for a while now. Back then (2008?) I realized that 32kB of memory wouldn't even be enough to play back most "chip style" amiga modules. I also realized that using SD card was impossible (or so I thought until reading your post today). The only option was to use external memory of some kind.
The original module format (soundtracker) is custom made to fit the sound chip in the Amiga (Paula) and that's the reason why it's 4 channels, 8 bit samples, 64 volume steps and why the sample rate per channel can't exceed 28 kHz.
Other computers of that era had to "emulate" Amiga hardware in software to play back modules and it was extremely cycle hungry. An Atari STe (8 Mhz 68000) could almost achieve Amiga quality module playback while using almost 100% CPU time. Module playback on the original Amiga (7.14 Mhz 68000) didn't eat more than some percantage of the CPU time.
@average joe
If you think that MIDI format isn't easily edited, than you should see the Retronitus music format..
Because of this i think it will be quite hard to make a tracker for Retronitus. You will have to edit in an intermediate format and "compile" everytime you wan't to play back.
When you can playback this 4 channel Amiga module on the Propeller, the player is good enough!
Oh how I miss the time spent on my Amiga in the late 80s to early 90s playing modules like this one in the background while coding in Amos (a HIGHLY advanced basic interpreter) or making animation in Deluxe Paint.
It would take some years before Windows users would playback music while doing anything else at the same time.
I read through the Amiga MOD file format and while it's not great for a tracker, it would be PERFECT for a Real-time Pattern Sequencer IMO. I've been interested to work on one but thought it would be better to work on the tracker first. It is a complex file format and I would imagine incredibly difficult to emulate. I will need to think on this a bit though
As Ahle2 pointed out, MOD is the original tracker format. It was initially a commercial product, called SoundTracker funnily, for quickly composing and attaching intro and in-game music for games. I presume it would have been a logical product of the earlier in-game SID tunes and the likes from the various 8-bit platforms.
Computer based sequencers were all MIDI oriented back then.
@average joe
>" If you're interested I have a couple extra boards."
Thank's for the offer, but at the moment I try to do it with the simplest possible hardware, which is an SD card or a Flash chip connected on 3..4 pins.
I think with 1 MB of SRAM which is full random access it should be possible to play 10..20 tracks. Perhaps I come back to you on this later.
@Ahle2
For shure I can share the code I have so far. It is in an early experimental state and a bit messy.
What hardware do you have to try it? My current setup needs a PS2 keyboard, a TV out, a stereo output and an SD card. The Keyboard can also be emulated with PropTerminal. While this is a standard setup for me, I realized that no common used Propeller board has these all "on board" without Add On modules. So I consider to do a version with the PST for HMI. Then you need only a board with SD card and stereo Audio (PropBOE for example).
I have downloaded the "Mantronix Overload" MOD file, and will try it later...
I never had an Amiga computer (but an Atari ST with MIDI), so I really just discovered the 'tracker world' last week. It's amazing what you can do with a few short samples and a pattern sequencer. I really like the effect parameter on every step of the tracks which lets you control a lot of parameters like volume envelope, pitch modulation, but also pattern break or playback speed. The MOD fie format structure is a bit strange, and all the parameters are for the Amiga sound chip. Later tracker formats are more universal, but they expect that you can play up to 32 tracks simultaneously.
@Ariba
My modified demo board has everything needed to get going. Do you access the SD card without a file system? I'm really surprised that this is possible when considering the way samples are looped and the arbitrary sample rate and they they are read from 4 sources at the same time. Then also, a SD card isn't true random access. Seeing is believing, I must try it myself.
My first computer experience was the Atari ST when I was 6 years old. We had it for a year? Until my brother sold it and bought an Amiga instead. The ST was a great computer for the time and I remember playing "Bombuzal" and "R-Type" on it.
While the Amiga was technically more advanced with faster/better grapics and way better sound hardware, the ST excelled at desktop publishing and as a midi workstation.
Today I own two Atari STs and five different Amiga models. I really think both Amiga and Atari ST was way ahead of IBM clones and even Macintosh in the mid to late 80s.
I have made some experiments with playing several samples together direct from the SD card. Last week I began a little tracker with the Amiga MOD format. This format needs only 4 channels (tracks) to play at the same time. This description helped me a lot: http://www.mediatel.lu/workshop/audio/fileformat/h_mod.html
The attached picture shows the TV screen of my tracker. I can only edit the current pattern for now, it's mainly meant to test the player. A full editable tracker, including sample editor is a challenging job on a propeller, but not impossible.
So far some MOD files play really well, others have some problems with the sample loops. I will see if I can improve that, otherwise I will switch to a SPI Flash as sample memory.
@Ariba
My modified demo board has everything needed to get going. Do you access the SD card without a file system? I'm really surprised that this is possible when considering the way samples are looped and the arbitrary sample rate and they they are read from 4 sources at the same time. Then also, a SD card isn't true random access. Seeing is believing, I must try it myself.
...
It's the normal FAT(16/32) file system but I expect that the file has contiguous sectors, otherwise it will not work. All the MOD files I copied to the SD card with a card reader had always contiguous sectors so far. Then every channel has 2 sector buffers in hub ram. The PASM sample player reads from one of the 2 sector buffres and calculates the next sector it will need. These next sectors are loaded by another (Spin-) cog for all 4 channels. Whole sectors are random accessible from the SD card.
The problem is that I have simplified the mapping of the 2 buffers too much, now even sector numbers go into the first buffer, odd numbers into the second. This works well until the first and the last sector of the sample loop are both even or odd. So samples with such loops produces a big glitch. I think the solution is to swap the buffer every time a new one is needed, but its hard to implement that in the current code.
The Overload MOD file has a few of these not fitting loops, so it sounds not so well. If I edit the loops a bit it is not so bad. But it shows also another problem: If the samples are pitched down to much they produvce a lot of aliasing. Perhaps a simple filter can help, but I think to do it right I need to interpolate between samples. You see still a lot to do... I will work a bit on the loop problem and post then a snapshot of the work.
But you need to wait a bit longer. I've tried to implement an interpolation between samples. It sounds so much better if only these random spikes not would be...
So I will post first the filter version then.
@Ariba
I think a lot of people are interested in your tracker, so keep on coding and let the world know what you have come up with.
Regarding sample based music like Amiga modules; Technically speaking it's extremely simple both hardware wise and software wise, but the end result can be very impressive.
No need for any advanced CPU hungry synthesis; But still it can sound like any synth or real instrument or whatever samples you have got. That's why the Amiga doesn't have a "sound" like any other "synth based" computer or game system from the 80s.
Every program or game had their own set of samples. The Paula could even "emulate" all the other PSGs used in other consoles/computers by looping short waveforms. Early amiga games used that technique because it was hard to "come by" samples back then.
While the original Macintosh could play back samples in hardware at almost Amiga like quality, it couldn't alter the pitch or volume in hardware, so playing modules on the Mac still needed software mixing and the 68000 was to slow to pull it of while anything was going on at the same time. Therefore music on the Mac often was just a big sample played back at the same rate it was recorded. So in the 80s the Amiga was unique in the respect that it could "manipulate" samples and create music on the fly in hardware.
The funny thing is that the SID chip is technically many times more complex than the Paula in the Amiga. Still the Paula will impress more, because it can sound like anything (even the SID).
Here are some cool Amiga modules to show of the diversity of Amiga music:
As promised to people that have contacted me privately, I will start documenting how Retronitus works and the formats being used.. etc.. First out is short description of the internal workings.
A short description of how Retronitus works
Retronitus consists of a few different parts; An 8 channel synthesizser, A "sound list interpreter", a music engine and a "sound list trigger".
Below follows a description of each of these parts.
The synthesizer
It's a basic 8 channel synthesizer based around a phase accumulator core.
It has got 4 different waveform types, Saw, Square, Triangle and Noise; Each channel has got a fixed waveform "assigned" to it.
Channel 1 to 3 is square, channel 4 to 6 is saw, channel 7 is triangle and channel 8 is noise. All waveforms types can be modulate in some way or another.
The square can be PWM modulated. The saw can be phase modulated with an added saw wave on top. The triangle can be be masked with the modulation value.
And lastly the noise is "ror + add" modulated with the modulation value. The square and saw waves can have auto incrementation of the modulation value or a fixed modulation value.
Each channel has got a very simple linear volume envelope. It basically just free runs until either max or min volume is reached.
(By using "sound lists" the limitation of this simple envelope design is a non-issue. All kinds of envelopes, like ADSR, can be "faked".
Even Tremolo or AM modulation can be achieved with sound lists. More on sound lists later)
Each channel is updated every sample (~82 kHz) to achieve high quality sound generation.
The sound list interpreter (SLI)
Besides the synth engine itself, this is the most important part found in Retonitus. Retronitus doesn't have memory mapped registers in hub RAM like SIDcog or AYcog.
All registers are internal to the cog and isn't directly writable by the user. So how can sound and music be programmed then?
Well, the so called "sound list interpreter" is the key here. It bassically is a CPU within the CPU(the cog). It gets called each sample, assigned to a different sound channel.
Actually through this multiplexing "trick" it is more like 8 CPUs running inside the cog. Each of these virtual CPUs has an execution rate of 82/11 = 7454 instructions per second.
That is fast enough to achieve sound FX with many times higher resolution, in the time domain, than used in any so called "multispeed sound routine" on a C64 for an example.
The SLI(sound list interpreter) has got 4 instructions; They are, SET, MODIFY, WAIT and JMP. That is pretty much all you need to make sounds the way they are done on 8 bits machines.
So when you want to play a sound FX or an instrument you just point the program counter of the SLI to an address in hub memory where your sound list(program) is located.
This little program will alter the internal registers of a sound channel over time to achieve every imaginable/unimaginable sound heard or not heard from a PSG in the 80s.
The last instruction in every valid sound list should be JMP. Either JMP on the spot (end of program) or jmp -xxx to achieve a sound loop. (vibrato, echo, tremolo.. etc)
The sound list trigger
This is a polling mechanism. It's multiplexed two times, first "sample rate"/11 (Retronitus has got 11 "processes" or time slices for different tasks) and then by 8 (8 channels), therefore the poll rate is 931 times a second for each channel.
This gives enough resolution in the time domain to achieve "instant" triggering of sound FX and instruments.
Each channel has got a trigger address in hub RAM. When the value at this address is 0, the sound list trigger does nothing.
If it isn't 0, it sets the program counter of the SLI assigned to the current channel to this value. In other words it triggers a sound or instrument.
When a sound is triggered, a zero is written back to this address to ensure that it will be triggered just once.
When a user want to play a sound FX in channel X, he/she have to put the address of the sound FX (sound list) at the trigger address of the corresponding channel.
The music engine
It reads music data directly from hub RAM at an user programmable arbitrary tempo. Each channel is completely independant. That makes it possible to have any number of channels playing music.
You can have a tune playing in just one channel or you could use all 8 channels. Of course for a game at least one channel will have to be dedicated to sound FX.
Music data is stored as delta values, both for note values and the timing between each note, this is done to save precious hub memory. Every channel that is currently used for playing music has got its own track.
Each track consists of patterns "glued together" to form the final track.
Since music contains parts that will be repeated many times (for an example a drum sequency can be repeated an entire song), the use of patterns can dramatically reduce the size of a tune.
(Of course a song with no repeating parts can be made by either using a very long pattern or by never using the same pattern twice in a track)
When a track reaches the end it either stops or loops. (this is a user decision)
If the music engine wants to play an instrument with a given note it directly writes to the pitch register of a channel with a frequency value found in an internal "note-to-freq-LUT".
Then it triggers the instrument by writing to the "sound list trigger address" (see "The sound list trigger" part above) assigned to the channel.
Design goals of Retronitus vs success
1. If possible make a complete sound engine + music engine in a single cog. (mission accomplished)
2. Have more sound channels than available on any PSG in the 80s. (mission accomplished, 8 channels achieved)
3. Try to get as close to 100 kHz mixing frequency as possible to get "aliasing free" sound generation. (82 kHz achieved)
4. Include as many waveform types as possible. (4 types achieved)
5. Include many types of modulations. (FM, AM, PWM. PHASE)
6. Include volume envelope for all channels. (mission accomplished)
7. Make music footprint as small as possible without any noticeable issues. (1.2 kB is enough for an 8 channel version of the "Castle Vania" theme. That's includes instrument data!!)
8. Have inbuilt "groove" capabilities (mission failed due to too little cog memory left)
9. Stereo sound. (mission accomplished)
10. Include seamless stereo panning (mission failed due to too little memory and too few cycles left each sample)
11. Include a "sound list interpreter" (like a very simple CPU for each channel) to create sounds in the same way as most 8 bit machines.(mission accomplished)
12. Simple API. (accomplished)
13. Inbuilt Vibrato, Portamento, Tremolo and other effects. (Can be accomplished with "sound lists")
14. Possibility to play sound FX (sound lists) at the same time as music. (mission accomplished)
I always enjoy reading your posts, even if I only understand a small fraction of it. I still use SIDCOG regularly, just to play dump files and impress my mates
Keep up the good work, there are plenty of people on here who appreciate your time and effort.
If you're ever in the UK, I'll buy you a drink or two
Thank you for the Retronitus description. This is how I understand it:
The SynthEngine: -> generates the sound according parameters
SoundListInterpreter: -> sets the synth parameters and change them over time (like Envelope/LFO), implemented as interpreted instructions for a virtual mini-CPU.
something like a "preset / instrument" in a traditional synth
SoundListTrigger: -> something like a "patch" on a traditional synth, that combines several "presets"
MusicEngine: -> the sequencer that plays the "patches"
I can see that this is very flexible. My concern is that it is too complex to program sounds and music. But I guess that's why you have made the PC application to simplify it. Is there some way to import a common sequencer format, like MIDI standard files or perhaps a Tracker format in that software, for the notes to play?
Comments
I remain really eager to compose some chip tunes on Retronitus.
See here:
http://forums.parallax.com/showthread.php?111867-Music-Synthesizer-object-with-General-MIDI-sound-set
Andy
It may actually not be that hard to fix, but it still drains my motivation since my last session was futile. I spent hours without getting any result.
I will do a phase distortion synth for the Propeller some day. It sounds like something in between FM synthesis and subtractive synthesis.
It's not very cycle intensive unlike subtractive synthesis. And it still sounds more analog (that's a good thing in synth land) than FM syntesis.
Ahle2, I've been really stumped before by an intermittent bug that was very hard to diagnose in graphics.spin. It turned out to be an issue with messaging between cogs via hub ram. I think I was reloading a buffer before another cog had finished picking up its contents. It was very hard to discover, but once found, it cleared up all the mess and things worked perfectly. Concurrent processing bugs can really blindside you. Have you tried your code on more than one Propeller chip?
The sequencer isn't running on the Prop itself. It's a QT application running on the PC. It would have been really cool to make some kind of music editor running on the Prop some day though.
I think that some kind of tracker is more suitable since a mouse driven sequencer might be hard to achieve on the Prop itself.
Btw, I have some awesome ideas for Retronitus on the Prop 2. With that much power in a single cog I will be able to do some things that's impossible on the Prop 1. (OOOps, I said impossible..;) )
Can't wait to push the Prop 2; But I'm afraid that I will be late to the game since it's likely to come to Sweden at a much later time with a much higher price tag.
What we really need is someone in China to post them out - postage is rediculously cheap there.
I've been experimenting with a tracker for the Touchburger boards Doc and I have been working on. I've hit a bit of a brick wall trying to figure out the storage of notes. Midi files do not seem to be a good format since they are not easily edited. Maybe some advice from the guru's would help!
When we have chips/boards, we'll probably pick several dozen people on the forums to send them to. Don't worry.
I have made some experiments with playing several samples together direct from the SD card. Last week I began a little tracker with the Amiga MOD format. This format needs only 4 channels (tracks) to play at the same time. This description helped me a lot: http://www.mediatel.lu/workshop/audio/fileformat/h_mod.html
The attached picture shows the TV screen of my tracker. I can only edit the current pattern for now, it's mainly meant to test the player. A full editable tracker, including sample editor is a challenging job on a propeller, but not impossible.
So far some MOD files play really well, others have some problems with the sample loops. I will see if I can improve that, otherwise I will switch to a SPI Flash as sample memory.
Andy
Thanks in advance!
@Ariba
That's great news!
An amiga style module player/editor has been on my list for a while now. Back then (2008?) I realized that 32kB of memory wouldn't even be enough to play back most "chip style" amiga modules. I also realized that using SD card was impossible (or so I thought until reading your post today). The only option was to use external memory of some kind.
The original module format (soundtracker) is custom made to fit the sound chip in the Amiga (Paula) and that's the reason why it's 4 channels, 8 bit samples, 64 volume steps and why the sample rate per channel can't exceed 28 kHz.
Other computers of that era had to "emulate" Amiga hardware in software to play back modules and it was extremely cycle hungry. An Atari STe (8 Mhz 68000) could almost achieve Amiga quality module playback while using almost 100% CPU time. Module playback on the original Amiga (7.14 Mhz 68000) didn't eat more than some percantage of the CPU time.
@average joe
If you think that MIDI format isn't easily edited, than you should see the Retronitus music format..
Because of this i think it will be quite hard to make a tracker for Retronitus. You will have to edit in an intermediate format and "compile" everytime you wan't to play back.
Oh how I miss the time spent on my Amiga in the late 80s to early 90s playing modules like this one in the background while coding in Amos (a HIGHLY advanced basic interpreter) or making animation in Deluxe Paint.
It would take some years before Windows users would playback music while doing anything else at the same time.
Computer based sequencers were all MIDI oriented back then.
>" If you're interested I have a couple extra boards."
Thank's for the offer, but at the moment I try to do it with the simplest possible hardware, which is an SD card or a Flash chip connected on 3..4 pins.
I think with 1 MB of SRAM which is full random access it should be possible to play 10..20 tracks. Perhaps I come back to you on this later.
@Ahle2
For shure I can share the code I have so far. It is in an early experimental state and a bit messy.
What hardware do you have to try it? My current setup needs a PS2 keyboard, a TV out, a stereo output and an SD card. The Keyboard can also be emulated with PropTerminal. While this is a standard setup for me, I realized that no common used Propeller board has these all "on board" without Add On modules. So I consider to do a version with the PST for HMI. Then you need only a board with SD card and stereo Audio (PropBOE for example).
I have downloaded the "Mantronix Overload" MOD file, and will try it later...
I never had an Amiga computer (but an Atari ST with MIDI), so I really just discovered the 'tracker world' last week. It's amazing what you can do with a few short samples and a pattern sequencer. I really like the effect parameter on every step of the tracks which lets you control a lot of parameters like volume envelope, pitch modulation, but also pattern break or playback speed. The MOD fie format structure is a bit strange, and all the parameters are for the Amiga sound chip. Later tracker formats are more universal, but they expect that you can play up to 32 tracks simultaneously.
Andy
My modified demo board has everything needed to get going. Do you access the SD card without a file system? I'm really surprised that this is possible when considering the way samples are looped and the arbitrary sample rate and they they are read from 4 sources at the same time. Then also, a SD card isn't true random access. Seeing is believing, I must try it myself.
My first computer experience was the Atari ST when I was 6 years old. We had it for a year? Until my brother sold it and bought an Amiga instead. The ST was a great computer for the time and I remember playing "Bombuzal" and "R-Type" on it.
While the Amiga was technically more advanced with faster/better grapics and way better sound hardware, the ST excelled at desktop publishing and as a midi workstation.
Today I own two Atari STs and five different Amiga models. I really think both Amiga and Atari ST was way ahead of IBM clones and even Macintosh in the mid to late 80s.
Jeff
It's the normal FAT(16/32) file system but I expect that the file has contiguous sectors, otherwise it will not work. All the MOD files I copied to the SD card with a card reader had always contiguous sectors so far. Then every channel has 2 sector buffers in hub ram. The PASM sample player reads from one of the 2 sector buffres and calculates the next sector it will need. These next sectors are loaded by another (Spin-) cog for all 4 channels. Whole sectors are random accessible from the SD card.
The problem is that I have simplified the mapping of the 2 buffers too much, now even sector numbers go into the first buffer, odd numbers into the second. This works well until the first and the last sector of the sample loop are both even or odd. So samples with such loops produces a big glitch. I think the solution is to swap the buffer every time a new one is needed, but its hard to implement that in the current code.
The Overload MOD file has a few of these not fitting loops, so it sounds not so well. If I edit the loops a bit it is not so bad. But it shows also another problem: If the samples are pitched down to much they produvce a lot of aliasing. Perhaps a simple filter can help, but I think to do it right I need to interpolate between samples. You see still a lot to do... I will work a bit on the loop problem and post then a snapshot of the work.
Andy
Your tracker deserves it's own thread!
Seconded!
Yes, that was anyway my intention.
But you need to wait a bit longer. I've tried to implement an interpolation between samples. It sounds so much better if only these random spikes not would be...
So I will post first the filter version then.
Andy
I think a lot of people are interested in your tracker, so keep on coding and let the world know what you have come up with.
Regarding sample based music like Amiga modules; Technically speaking it's extremely simple both hardware wise and software wise, but the end result can be very impressive.
No need for any advanced CPU hungry synthesis; But still it can sound like any synth or real instrument or whatever samples you have got. That's why the Amiga doesn't have a "sound" like any other "synth based" computer or game system from the 80s.
Every program or game had their own set of samples. The Paula could even "emulate" all the other PSGs used in other consoles/computers by looping short waveforms. Early amiga games used that technique because it was hard to "come by" samples back then.
While the original Macintosh could play back samples in hardware at almost Amiga like quality, it couldn't alter the pitch or volume in hardware, so playing modules on the Mac still needed software mixing and the 68000 was to slow to pull it of while anything was going on at the same time. Therefore music on the Mac often was just a big sample played back at the same rate it was recorded. So in the 80s the Amiga was unique in the respect that it could "manipulate" samples and create music on the fly in hardware.
The funny thing is that the SID chip is technically many times more complex than the Paula in the Amiga. Still the Paula will impress more, because it can sound like anything (even the SID).
Here are some cool Amiga modules to show of the diversity of Amiga music:
A short description of how Retronitus works
Retronitus consists of a few different parts; An 8 channel synthesizser, A "sound list interpreter", a music engine and a "sound list trigger".
Below follows a description of each of these parts.
The synthesizer
It's a basic 8 channel synthesizer based around a phase accumulator core.
It has got 4 different waveform types, Saw, Square, Triangle and Noise; Each channel has got a fixed waveform "assigned" to it.
Channel 1 to 3 is square, channel 4 to 6 is saw, channel 7 is triangle and channel 8 is noise. All waveforms types can be modulate in some way or another.
The square can be PWM modulated. The saw can be phase modulated with an added saw wave on top. The triangle can be be masked with the modulation value.
And lastly the noise is "ror + add" modulated with the modulation value. The square and saw waves can have auto incrementation of the modulation value or a fixed modulation value.
Each channel has got a very simple linear volume envelope. It basically just free runs until either max or min volume is reached.
(By using "sound lists" the limitation of this simple envelope design is a non-issue. All kinds of envelopes, like ADSR, can be "faked".
Even Tremolo or AM modulation can be achieved with sound lists. More on sound lists later)
Each channel is updated every sample (~82 kHz) to achieve high quality sound generation.
The sound list interpreter (SLI)
Besides the synth engine itself, this is the most important part found in Retonitus. Retronitus doesn't have memory mapped registers in hub RAM like SIDcog or AYcog.
All registers are internal to the cog and isn't directly writable by the user. So how can sound and music be programmed then?
Well, the so called "sound list interpreter" is the key here. It bassically is a CPU within the CPU(the cog). It gets called each sample, assigned to a different sound channel.
Actually through this multiplexing "trick" it is more like 8 CPUs running inside the cog. Each of these virtual CPUs has an execution rate of 82/11 = 7454 instructions per second.
That is fast enough to achieve sound FX with many times higher resolution, in the time domain, than used in any so called "multispeed sound routine" on a C64 for an example.
The SLI(sound list interpreter) has got 4 instructions; They are, SET, MODIFY, WAIT and JMP. That is pretty much all you need to make sounds the way they are done on 8 bits machines.
So when you want to play a sound FX or an instrument you just point the program counter of the SLI to an address in hub memory where your sound list(program) is located.
This little program will alter the internal registers of a sound channel over time to achieve every imaginable/unimaginable sound heard or not heard from a PSG in the 80s.
The last instruction in every valid sound list should be JMP. Either JMP on the spot (end of program) or jmp -xxx to achieve a sound loop. (vibrato, echo, tremolo.. etc)
The sound list trigger
This is a polling mechanism. It's multiplexed two times, first "sample rate"/11 (Retronitus has got 11 "processes" or time slices for different tasks) and then by 8 (8 channels), therefore the poll rate is 931 times a second for each channel.
This gives enough resolution in the time domain to achieve "instant" triggering of sound FX and instruments.
Each channel has got a trigger address in hub RAM. When the value at this address is 0, the sound list trigger does nothing.
If it isn't 0, it sets the program counter of the SLI assigned to the current channel to this value. In other words it triggers a sound or instrument.
When a sound is triggered, a zero is written back to this address to ensure that it will be triggered just once.
When a user want to play a sound FX in channel X, he/she have to put the address of the sound FX (sound list) at the trigger address of the corresponding channel.
The music engine
It reads music data directly from hub RAM at an user programmable arbitrary tempo. Each channel is completely independant. That makes it possible to have any number of channels playing music.
You can have a tune playing in just one channel or you could use all 8 channels. Of course for a game at least one channel will have to be dedicated to sound FX.
Music data is stored as delta values, both for note values and the timing between each note, this is done to save precious hub memory. Every channel that is currently used for playing music has got its own track.
Each track consists of patterns "glued together" to form the final track.
Since music contains parts that will be repeated many times (for an example a drum sequency can be repeated an entire song), the use of patterns can dramatically reduce the size of a tune.
(Of course a song with no repeating parts can be made by either using a very long pattern or by never using the same pattern twice in a track)
When a track reaches the end it either stops or loops. (this is a user decision)
If the music engine wants to play an instrument with a given note it directly writes to the pitch register of a channel with a frequency value found in an internal "note-to-freq-LUT".
Then it triggers the instrument by writing to the "sound list trigger address" (see "The sound list trigger" part above) assigned to the channel.
Design goals of Retronitus vs success
1. If possible make a complete sound engine + music engine in a single cog. (mission accomplished)
2. Have more sound channels than available on any PSG in the 80s. (mission accomplished, 8 channels achieved)
3. Try to get as close to 100 kHz mixing frequency as possible to get "aliasing free" sound generation. (82 kHz achieved)
4. Include as many waveform types as possible. (4 types achieved)
5. Include many types of modulations. (FM, AM, PWM. PHASE)
6. Include volume envelope for all channels. (mission accomplished)
7. Make music footprint as small as possible without any noticeable issues. (1.2 kB is enough for an 8 channel version of the "Castle Vania" theme. That's includes instrument data!!)
8. Have inbuilt "groove" capabilities (mission failed due to too little cog memory left)
9. Stereo sound. (mission accomplished)
10. Include seamless stereo panning (mission failed due to too little memory and too few cycles left each sample)
11. Include a "sound list interpreter" (like a very simple CPU for each channel) to create sounds in the same way as most 8 bit machines.(mission accomplished)
12. Simple API. (accomplished)
13. Inbuilt Vibrato, Portamento, Tremolo and other effects. (Can be accomplished with "sound lists")
14. Possibility to play sound FX (sound lists) at the same time as music. (mission accomplished)
I always enjoy reading your posts, even if I only understand a small fraction of it. I still use SIDCOG regularly, just to play dump files and impress my mates
Keep up the good work, there are plenty of people on here who appreciate your time and effort.
If you're ever in the UK, I'll buy you a drink or two
@Ahle2, you are a genious. The description of Retronitus is amazing.
Thank you for the Retronitus description. This is how I understand it:
The SynthEngine: -> generates the sound according parameters
SoundListInterpreter: -> sets the synth parameters and change them over time (like Envelope/LFO), implemented as interpreted instructions for a virtual mini-CPU.
something like a "preset / instrument" in a traditional synth
SoundListTrigger: -> something like a "patch" on a traditional synth, that combines several "presets"
MusicEngine: -> the sequencer that plays the "patches"
I can see that this is very flexible. My concern is that it is too complex to program sounds and music. But I guess that's why you have made the PC application to simplify it. Is there some way to import a common sequencer format, like MIDI standard files or perhaps a Tracker format in that software, for the notes to play?
Andy