I have a couple of questions about it. What's the way to create a .mod file without breaking out the Commodore and Protracker? And the .raw files - is there a way to create them with modern software?
Let me know if I can improve the Quick Byte. I'll keep it current with your newest code releases.
There are plenty of ways to edit/make both music and sound effects on a modern PC running any OS! The samples are just raw samples in any common format, so just take whatever sound editor you have laying around (I like Audacity). Save any sound bite to raw 8 or 16 bit format using any sample rate. And you should be able to use simpleSound to play it back with pitch, volume and panning parameters applied induvidually per channel. In the normal configuration, you can play 8 samples with applied parameters at the same time, but by changing a constant you can have up to a total of 64 at the same time using just a single cog. If you only want to play back samples, you don't need to call any tick() or pollTick() method at all. That is only to process the music data.
To produce or edit modules you can have a look at...
ProTracker 2 clone - An almost perfect 1:1 clone of the most popular Amiga version
OpenMPT - A modern actively developed editor for many different module formats, including ProTracker
And, some offtopic, as I don't know if this thing can save a .mod: Sunvox. This is a heavy machine, a tracker based modular synth: https://www.warmplace.ru/soft/sunvox/
@Ahle2 said:
If you only want to play back samples, you don't need to call any tick() or pollTick() method at all. That is only to process the music data.
Ahle2 thanks much! Can you clarify what you mean by this statement? Are you saying you can start a sound file without the 50ms pollTick() method for playback? I need to understand the difference between processing and playback, I guess, at a high level.
I've also updated the Quick Byte with links to the various sound file editors MikyTracker, Protracker 2, MPTClone and Audacity. This is shaping up to be a very complete offering to the P2 community from the P2 maniac.
Interestingly, it's more like machine code editor than sheet music editor. It's all lines of hexadecimal...
But then, I guess sheet music is actually like a program...
Ahle2, in the Space Invaders emulator, we got the 8080 emulation, the video output, the sound output, and the control inputs all running on one COG, thanks to interrupts.
This is kind of an extreme case, but by getting everything running in one cog (and only 3 pins), the whole video game becomes an object which can be instantiated on one cog. We are going to have some standardized game cabinets with display, sound, inputs and an RJ-45 jack that goes back to a P2 board with 8 such jacks.
Would there be any value in a bare-bones version of simpleSound that runs from an interrupt, only? It would be a sub-object to a game.
Wait, maybe this is overkill. Perhaps what we need is just a multi-interrupt driven video, audio, and input driver that lives in the Spin2 interpreter cog. That way, people could write games using Spin2, while the same cog handles all of the I/O. Baggers' sound player is very simple. It just starts tracks on command and sums them all together. This would enable one-cog video game development in Spin2. There might be some meaningful improvements possible to the current audio, though. You probably have an idea of what those would be.
I was talking with my friend Matt about the P2 the other day and his first question was: Is there a multi-file SD object and an audio player that can handle multiple simultaneous sources? Matt has used the P1 (with code I helped with) to develop stand-up non-video type games for places like Chuck-E-Cheese, but sound is always the issue, hence he turned to a Sparkfun board (for audio) that lets him do what he wants. He'd really like to integrate everything into the P2.
I don't care care about retro video, but I would like a multi-channel audio player that can pull from a multi-file SD object. I think I'd rather put it into its own cog as I frequently use inline PASM and would like that interpreter space for myself.
That is correct... For sound effects you only need sound.start() at the top and then call the sample methods whenever you want to play a sound effect.
When it comes to sample playback, simpleSound is just a thin abstraction layer for reSound that does the heavy sound processing, mixing and sample playback. Mod music is basically just timed samples played back with different pitches, volumes and some fx using multiple channels at the same time; So reSound is the perfect back end for the sample playback, mixing and sample looping part. BUT, the music data has to be read and interpreted; That's where simpleSound with the trackerPlayer object comes into play. But instead of wasting a whole cog for something that isn't very CPU hungry, that only runs 50 times a second, you can have the main loop (usually) of the application call the music routine when it has some spare time. Normally you would want that 50 Hz be as precise as possible (vsync), but I made the pollTick method to handle any rates above 50 Hz. You can even call it at random intervals each time and it will still play back the music at the right speed. (as long as each interval is at least 20 ms).
@Ahle2 I wonder if pollTick() would be better handled with an interrupt to assure it's always handled in time...
On the other hand, games almost always have a loop that is 60 Hz or faster, so maybe doesn't matter...
@Rayman said:
@Ahle2 I wonder if pollTick() would be better handled with an interrupt to assure it's always handled in time...
On the other hand, games almost always have a loop that is 60 Hz or faster, so maybe doesn't matter...
Yes, the best way is to use the normal tick() method with a timer interrupt OR have a display driver that runs at 50 Hz that calls that method each vsync. But I know almost everything these days are 60 Hz or above (even in Europe), so I made the pollTick method as well, to handle this easily.
The 50 Hz display driver is in construction now, driven by a P2 clocked at PAL Amiga x 45 and if nothing interferes it will be ready tomorrow as it works now, I only (1) want more colors as in P1 version (2) need to attach P1 converted Spin methods to a P2 pasm code. The goal is of course to port PropPlay from a P1. I have an idea how to make a Paula-like synth without using a noise DAC, but first... let convert a PropPlay. The learning curve was steeper than I expected but now I am starting to feel at home with the P2 which is a much more powerful beast than it looks.
@JonnyMac said:
I was talking with my friend Matt about the P2 the other day and his first question was: Is there a multi-file SD object and an audio player that can handle multiple simultaneous sources? Matt has used the P1 (with code I helped with) to develop stand-up non-video type games for places like Chuck-E-Cheese, but sound is always the issue, hence he turned to a Sparkfun board (for audio) that lets him do what he wants. He'd really like to integrate everything into the P2.
I don't care care about retro video, but I would like a multi-channel audio player that can pull from a multi-file SD object. I think I'd rather put it into its own cog as I frequently use inline PASM and would like that interpreter space for myself.
Agreed Jon. We have 8 cogs so no need to put everything into one cog. Having a cog that can do a whole gambit of audio (sound effects, audio replay or whatever) would be more useful.
While some of us (me) are interested in retro, having 8 games on one P2 is of no interest outside of proving it can be done. It’s a great demo of something that can be done but IMHO there’s no actual use.
My SD object has a pasm cog that runs the physical disk (ie SD sector reading and writing) and has file location and loading (in the root directory) as an extra ability. But the full FAT32 (Kye’s converted to spin2) needs to run in a different (spin) cog. But read, the FAT32 is not required to locate and load/run 8+3 file names from the FAT32 root directory. Ken’s in the process of making the SD Driver into a Quick Bytes. It uses a simple 4 long hub interface.
If you need any help getting this running just let me know. Your input would be helpful in making the Quick Bytes more user friendly - I’m too techo so often miss the basics explanation.
@Cluso99 said:
But the full FAT32 (Kye’s converted to spin2) needs to run in a different (spin) cog.
Is there an object available somewhere?
Several years ago I added LFN reading to KyeFAT on a P1, a simple update which made PropPlay look much better without these ~1 things in the directory list. PropPlay uses full hub RAM on P1 but here we have 512k of it, so why not to use?
Another way can be a filesystem structure modelled after Atari 8bit, fast and simple, but then a writer has to be written on PC to write this kind nonstandard filesystem.
I have my own variant of Kye’s FAT32 for P1 with a few extras such as reporting the start sector address of a file. I have converted it to P2 but it won’t run with my SD Driver yet
There’s this problem with hub addressing that has so many gotchas it’s taken me months to debug. I keep putting it down and then need to go back and start the integration again.
I do have it working when using my ROM SD Driver and ROM serial/monitor. But making it work with my pasm drivers has been elusive. Armed with more knowledge, I’ll be back on it in a few days after I get the VGA Driver running. I am sure I did post the spin code - it’s probably in my P2 OS thread and I’m sure there’s a link to it from my RetroBlade2 now you have it what can it do thread. Sorry on my iPad and searching and adding links is not easy.
The multifile wav-player already exists and has been for months. It's called rePlay and can have up to 64 sources (theoretically thanks to the reSound back end) of different formats (8 bit,16 bit, nr channels), with different sample rates and with different volume, panning settings, running at the same time. I have never released anything, because the state of SD drivers back then was misarable. Buggy, stalling, slow and just hacks of P1 driver. I can't release anything that I can not stand for, so I started doing my own SD driver. It's in the works and I will not release rePlay until it's done OR if something else comes up that fits the bill.
I had a look at your Quick Byte and I have some comments...
The simpleSound engine was first released in 2020-09-18 in the reSound thread
It's the Commodore Amiga computer, not the Commodore 64 that runs the original Protracker software
In the main loop you could skip the update_sound() method and all timing related stuff, just call the sound.pollTick() it handles everything internally
Eek! Amiga and C64 are so massively different beasts. Entirely different design engineering teams. It's like confusing the 6800 with the 68k, lol. You'd have to be a normal Joe to get that one wrong! :P
It's very common for Americans to think that the Amiga is the C64, it happens all the time. And the reason is that while the C64 was a commercial hit in the states and all the "kids" had one when they grew up, the Amiga strangely never really got a foothold in the country where it was designed; And Americans associates the company name, Commodore, with its only big hit in states. In Europe and other parts of the world, the Amiga was an extreme hit and for many years it was the number one most sold home computer. It took a while until PC computers got to the point, with addon cards and faster processors, to actually emulate (mostly in software) what the Amiga could do. And I too think it hurts a little bit when people confuse the two. Even though I LOVE the Commodore 64, it's not comparable in any sense of the word.
I had a look at your Quick Byte and I have some comments...
The simpleSound engine was first released in 2020-09-18 in the reSound thread
It's the Commodore Amiga computer, not the Commodore 64 that runs the original Protracker software
In the main loop you could skip the update_sound() method and all timing related stuff, just call the sound.pollTick() it handles everything internally
Other than that... great little Quick Byte!
Updated accordingly. I'll add the reSound thread at the bottom of this Quick Byte, too. On that last item, I removed update_sound() method from the code example.
Tag me on this thread when you make updates and I'll do the same on the Quick Byte.
@Ahle2 said:
It's very common for Americans to think that the Amiga is the C64, it happens all the time. And the reason is that while the C64 was a commercial hit in the states and all the "kids" had one when they grew up, the Amiga strangely never really got a foothold in the country where it was designed; And Americans associates the company name, Commodore, with its only big hit in states. In Europe and other parts of the world, the Amiga was an extreme hit and for many years it was the number one most sold home computer. It took a while until PC computers got to the point, with addon cards and faster processors, to actually emulate (mostly in software) what the Amiga could do. And I too think it hurts a little bit when people confuse the two. Even though I LOVE the Commodore 64, it's not comparable in any sense of the word.
This is correct. Chip and I had a C64, as did our neighbor friends. Through all of our experience with it, I don't think I knew much about the Amiga other than the name and an association with something we considered "all C64". Chip probably paid closer attention because he went to more of the weekend computer shows and read the printed magazines.
A few people I knew bought Amigas, but I was really overwhelmed by them, technically. I saw in the early-mid 90's that many Europeans were using them to produce video for TV commercials, since good rendering software had been developed.
And because the Amiga had genlock capability built into the hardware, so it was the obvious choice for "mid range" quality overlays for TV shows in the 80's and early 90's. I used to have two video recorders, a genlock and an Amiga computer to do video editing with overlays and sound effects in the 90's. I used the Scala 500 software package (pirated of course, but I was a teenager and had no money)
I remember the whole tv game "Who Wants to Be a Millionaire?" was running on One Amiga.
They just hide part of the unique main pictures with different keys.
candidates , main program feed only see part of the main.
Pictures, graphics, sound effects, light effect(dmx) and game running on one Amiga in 1998.
[https://en.wikipedia.org/wiki/Who_Wants_to_Be_a_Millionaire?]
The Amiga's OS was pretty advanced for the time. The "Intuition" toolkit used, for example, compositing for window management. The kernel provided fully pre-emptive multitasking. Dynamic linked lists were used for nearly everything, including memory allocations. And of course it was naturally a 32-bit OS because of the 68k. PC weenies liked to call the Amiga a 16-bit computer but by today's gauge the original 68k is a 32-bit processor.
Of course, game developers mostly ignored the OS. At best, it occasionally got used as a loader for the game. These games could be put on a HDD. Most games just booted directly from floppy disc though.
I just realized that you can play the Tempest 2000 music on P2 with simpleSound. The Atari Jaguar doesn't have a proper sound chip, just a DAC and an extra CPU, so apparently they just made a MOD player, lol.
TELEVISION IS THE RETINA OF THE MIND'S EYE
(The tune that has that is "02 - Part 1.mod", btw)
That game is weird and at the same time considered one of the only good games for the system.
The Nintendo 64 didn't have proper sound chip either, so "a lot" (well some) of the music is made with FastTracker 2. The funny thing is that the sound effects and music code had to run on the same processor (Reality Signal Processor) as the graphics engine. Sound, naturally, wasn't more important than graphics, so a lot of games sounded bad compared to the PS1 with its awesome sound chip.
Comments
@Ahle2 It looks like you have to repeatedly call "sound.pollTick()" to get music to play, is this right?
Yes, Ray. Somewhere (in one of the demo files) it says that pollTick() should be called at least 50x/sec for proper playback.
@Ahle2 I turned this into a Quick Byte; it's too good not to share!
https://www.parallax.com/simple-sound-engine-demo/
I have a couple of questions about it. What's the way to create a .mod file without breaking out the Commodore and Protracker? And the .raw files - is there a way to create them with modern software?
Let me know if I can improve the Quick Byte. I'll keep it current with your newest code releases.
Ken Gracey
Thanks Ken
There are plenty of ways to edit/make both music and sound effects on a modern PC running any OS! The samples are just raw samples in any common format, so just take whatever sound editor you have laying around (I like Audacity). Save any sound bite to raw 8 or 16 bit format using any sample rate. And you should be able to use simpleSound to play it back with pitch, volume and panning parameters applied induvidually per channel. In the normal configuration, you can play 8 samples with applied parameters at the same time, but by changing a constant you can have up to a total of 64 at the same time using just a single cog. If you only want to play back samples, you don't need to call any tick() or pollTick() method at all. That is only to process the music data.
To produce or edit modules you can have a look at...
Milkytracker is another modern incarnation.
There is also a Milky Tracker: https://github.com/milkytracker/MilkyTracker/releases/tag/v1.03.00
And, some offtopic, as I don't know if this thing can save a .mod: Sunvox. This is a heavy machine, a tracker based modular synth: https://www.warmplace.ru/soft/sunvox/
Ahle2 thanks much! Can you clarify what you mean by this statement? Are you saying you can start a sound file without the 50ms pollTick() method for playback? I need to understand the difference between processing and playback, I guess, at a high level.
I've also updated the Quick Byte with links to the various sound file editors MikyTracker, Protracker 2, MPTClone and Audacity. This is shaping up to be a very complete offering to the P2 community from the P2 maniac.
Ken Gracey
This is a great way to add sound and music to games.
Best part is the large number of decent quality .mod files on the internet.
But, the mixing of sound effects together is also great.
It was very easy for me to add music and sound effects to that "tetris" game using this.
I watched some youtube videos on protracker:
Interestingly, it's more like machine code editor than sheet music editor. It's all lines of hexadecimal...
But then, I guess sheet music is actually like a program...
Ahle2, in the Space Invaders emulator, we got the 8080 emulation, the video output, the sound output, and the control inputs all running on one COG, thanks to interrupts.
This is kind of an extreme case, but by getting everything running in one cog (and only 3 pins), the whole video game becomes an object which can be instantiated on one cog. We are going to have some standardized game cabinets with display, sound, inputs and an RJ-45 jack that goes back to a P2 board with 8 such jacks.
Would there be any value in a bare-bones version of simpleSound that runs from an interrupt, only? It would be a sub-object to a game.
Wait, maybe this is overkill. Perhaps what we need is just a multi-interrupt driven video, audio, and input driver that lives in the Spin2 interpreter cog. That way, people could write games using Spin2, while the same cog handles all of the I/O. Baggers' sound player is very simple. It just starts tracks on command and sums them all together. This would enable one-cog video game development in Spin2. There might be some meaningful improvements possible to the current audio, though. You probably have an idea of what those would be.
I was talking with my friend Matt about the P2 the other day and his first question was: Is there a multi-file SD object and an audio player that can handle multiple simultaneous sources? Matt has used the P1 (with code I helped with) to develop stand-up non-video type games for places like Chuck-E-Cheese, but sound is always the issue, hence he turned to a Sparkfun board (for audio) that lets him do what he wants. He'd really like to integrate everything into the P2.
I don't care care about retro video, but I would like a multi-channel audio player that can pull from a multi-file SD object. I think I'd rather put it into its own cog as I frequently use inline PASM and would like that interpreter space for myself.
@"Ken Gracey"
That is correct... For sound effects you only need sound.start() at the top and then call the sample methods whenever you want to play a sound effect.
When it comes to sample playback, simpleSound is just a thin abstraction layer for reSound that does the heavy sound processing, mixing and sample playback. Mod music is basically just timed samples played back with different pitches, volumes and some fx using multiple channels at the same time; So reSound is the perfect back end for the sample playback, mixing and sample looping part. BUT, the music data has to be read and interpreted; That's where simpleSound with the trackerPlayer object comes into play. But instead of wasting a whole cog for something that isn't very CPU hungry, that only runs 50 times a second, you can have the main loop (usually) of the application call the music routine when it has some spare time. Normally you would want that 50 Hz be as precise as possible (vsync), but I made the pollTick method to handle any rates above 50 Hz. You can even call it at random intervals each time and it will still play back the music at the right speed. (as long as each interval is at least 20 ms).
@Ahle2 I wonder if pollTick() would be better handled with an interrupt to assure it's always handled in time...
On the other hand, games almost always have a loop that is 60 Hz or faster, so maybe doesn't matter...
Yes, the best way is to use the normal tick() method with a timer interrupt OR have a display driver that runs at 50 Hz that calls that method each vsync. But I know almost everything these days are 60 Hz or above (even in Europe), so I made the pollTick method as well, to handle this easily.
The 50 Hz display driver is in construction now, driven by a P2 clocked at PAL Amiga x 45 and if nothing interferes it will be ready tomorrow
as it works now, I only (1) want more colors as in P1 version (2) need to attach P1 converted Spin methods to a P2 pasm code. The goal is of course to port PropPlay from a P1. I have an idea how to make a Paula-like synth without using a noise DAC, but first... let convert a PropPlay. The learning curve was steeper than I expected but now I am starting to feel at home with the P2 which is a much more powerful beast than it looks.
Agreed Jon. We have 8 cogs so no need to put everything into one cog. Having a cog that can do a whole gambit of audio (sound effects, audio replay or whatever) would be more useful.
While some of us (me) are interested in retro, having 8 games on one P2 is of no interest outside of proving it can be done. It’s a great demo of something that can be done but IMHO there’s no actual use.
My SD object has a pasm cog that runs the physical disk (ie SD sector reading and writing) and has file location and loading (in the root directory) as an extra ability. But the full FAT32 (Kye’s converted to spin2) needs to run in a different (spin) cog. But read, the FAT32 is not required to locate and load/run 8+3 file names from the FAT32 root directory. Ken’s in the process of making the SD Driver into a Quick Bytes. It uses a simple 4 long hub interface.
If you need any help getting this running just let me know. Your input would be helpful in making the Quick Bytes more user friendly - I’m too techo so often miss the basics explanation.
Is there an object available somewhere?
Several years ago I added LFN reading to KyeFAT on a P1, a simple update which made PropPlay look much better without these ~1 things in the directory list. PropPlay uses full hub RAM on P1 but here we have 512k of it, so why not to use?
Another way can be a filesystem structure modelled after Atari 8bit, fast and simple, but then a writer has to be written on PC to write this kind nonstandard filesystem.
I have my own variant of Kye’s FAT32 for P1 with a few extras such as reporting the start sector address of a file. I have converted it to P2 but it won’t run with my SD Driver yet
There’s this problem with hub addressing that has so many gotchas it’s taken me months to debug. I keep putting it down and then need to go back and start the integration again.
I do have it working when using my ROM SD Driver and ROM serial/monitor. But making it work with my pasm drivers has been elusive. Armed with more knowledge, I’ll be back on it in a few days after I get the VGA Driver running. I am sure I did post the spin code - it’s probably in my P2 OS thread and I’m sure there’s a link to it from my RetroBlade2 now you have it what can it do thread. Sorry on my iPad and searching and adding links is not easy.
The multifile wav-player already exists and has been for months. It's called rePlay and can have up to 64 sources (theoretically thanks to the reSound back end) of different formats (8 bit,16 bit, nr channels), with different sample rates and with different volume, panning settings, running at the same time. I have never released anything, because the state of SD drivers back then was misarable. Buggy, stalling, slow and just hacks of P1 driver. I can't release anything that I can not stand for, so I started doing my own SD driver. It's in the works and I will not release rePlay until it's done OR if something else comes up that fits the bill.
@"Ken Gracey"
I had a look at your Quick Byte and I have some comments...
Other than that... great little Quick Byte!
Eek! Amiga and C64 are so massively different beasts. Entirely different design engineering teams. It's like confusing the 6800 with the 68k, lol. You'd have to be a normal Joe to get that one wrong! :P
It's very common for Americans to think that the Amiga is the C64, it happens all the time. And the reason is that while the C64 was a commercial hit in the states and all the "kids" had one when they grew up, the Amiga strangely never really got a foothold in the country where it was designed; And Americans associates the company name, Commodore, with its only big hit in states. In Europe and other parts of the world, the Amiga was an extreme hit and for many years it was the number one most sold home computer. It took a while until PC computers got to the point, with addon cards and faster processors, to actually emulate (mostly in software) what the Amiga could do. And I too think it hurts a little bit when people confuse the two. Even though I LOVE the Commodore 64, it's not comparable in any sense of the word.
Updated accordingly. I'll add the reSound thread at the bottom of this Quick Byte, too. On that last item, I removed update_sound() method from the code example.
Tag me on this thread when you make updates and I'll do the same on the Quick Byte.
Ken Gracey
This is correct. Chip and I had a C64, as did our neighbor friends. Through all of our experience with it, I don't think I knew much about the Amiga other than the name and an association with something we considered "all C64". Chip probably paid closer attention because he went to more of the weekend computer shows and read the printed magazines.
Ken Gracey
A few people I knew bought Amigas, but I was really overwhelmed by them, technically. I saw in the early-mid 90's that many Europeans were using them to produce video for TV commercials, since good rendering software had been developed.
And because the Amiga had genlock capability built into the hardware, so it was the obvious choice for "mid range" quality overlays for TV shows in the 80's and early 90's. I used to have two video recorders, a genlock and an Amiga computer to do video editing with overlays and sound effects in the 90's. I used the Scala 500 software package (pirated of course, but I was a teenager and had no money)
I remember the whole tv game "Who Wants to Be a Millionaire?" was running on One Amiga.
They just hide part of the unique main pictures with different keys.
candidates , main program feed only see part of the main.
Pictures, graphics, sound effects, light effect(dmx) and game running on one Amiga in 1998.
[https://en.wikipedia.org/wiki/Who_Wants_to_Be_a_Millionaire?]
The Amiga's OS was pretty advanced for the time. The "Intuition" toolkit used, for example, compositing for window management. The kernel provided fully pre-emptive multitasking. Dynamic linked lists were used for nearly everything, including memory allocations. And of course it was naturally a 32-bit OS because of the 68k. PC weenies liked to call the Amiga a 16-bit computer but by today's gauge the original 68k is a 32-bit processor.
Of course, game developers mostly ignored the OS. At best, it occasionally got used as a loader for the game. These games could be put on a HDD. Most games just booted directly from floppy disc though.
I just realized that you can play the Tempest 2000 music on P2 with simpleSound. The Atari Jaguar doesn't have a proper sound chip, just a DAC and an extra CPU, so apparently they just made a MOD player, lol.
TELEVISION IS THE RETINA OF THE MIND'S EYE
(The tune that has that is "02 - Part 1.mod", btw)
That game is weird and at the same time considered one of the only good games for the system.
The Nintendo 64 didn't have proper sound chip either, so "a lot" (well some) of the music is made with FastTracker 2. The funny thing is that the sound effects and music code had to run on the same processor (Reality Signal Processor) as the graphics engine. Sound, naturally, wasn't more important than graphics, so a lot of games sounded bad compared to the PS1 with its awesome sound chip.