Ah, that's it: there was an old definition for _wypin left in the internal code that had the wrong order of arguments. Fixed now, thanks Andy and Roy!
David: the root problem should be fixed if you #include <propeller.h> and get the _wypin definition from there instead of relying on the built in one. Or, you can build the most recent github .
Ah, that's it: there was an old definition for _wypin left in the internal code that had the wrong order of arguments. Fixed now, thanks Andy and Roy!
David: the root problem should be fixed if you #include <propeller.h> and get the _wypin definition from there instead of relying on the built in one. Or, you can build the most recent github .
Thanks! It works now with or without propeller.h. I've added propeller.h to my sources because I guess that's more appropriate than relying on the built-in functions. Are you saying I also don't need these lines:
Ah, that's it: there was an old definition for _wypin left in the internal code that had the wrong order of arguments. Fixed now, thanks Andy and Roy!
David: the root problem should be fixed if you #include <propeller.h> and get the _wypin definition from there instead of relying on the built in one. Or, you can build the most recent github .
Thanks! It works now with or without propeller.h. I've added propeller.h to my sources because I guess that's more appropriate than relying on the built-in functions. Are you saying I also don't need these lines:
I did some experimenting and I guess I need these lines but not the _clkset call. Is this the correct way to handle clock configuration? I can certainly set _CLOCKFREQ manually but the values I've seen in sample code for _SETFREQ look like a magic numbers to me. Better to get it from a header file I think.
David,
Use clkfreq instead of _CLOCKFREQ, or you can also use _clockfreq() to get the value. Using either of those you don't need those 2 lines.
I switched to _clockfreq() and was able to remove those two lines. Thanks for the advice. Is there a best practice for this? Is clkfreq preferred over _clockfreq()?
clkfreq/clockfreq has been a mess because historically Catalina, PropGCC, and Spin all used different names and ways of accessing them on P1, and then P2 added another layer of complexity. Some day I'd like to go through and clean all of this up.
clkfreq/clockfreq has been a mess because historically Catalina, PropGCC, and Spin all used different names and ways of accessing them on P1, and then P2 added another layer of complexity. Some day I'd like to go through and clean all of this up.
Yeah I feel that too. It seems difficult to remember which one to use.
After all of the suggestions here, this is the final version of my test program to show how to create sound from a C program. Now I'm going to try to get my granular synth code working.
ersmith,
If you try to use clkfreq inside of an __asm {} block, you get this from the compiler: "child killed: segmentation violation"
Thanks Roy. It's not allowed because it's a memory reference (loading from 0x14) and not a register. But you're right, it should not have segfaulted. It should produce a sensible error now.
In general only local variables are allowed in inline assembly, and clkfreq (in all its variations) is a global variable.
Now that I got the simple sample program working I tried the Auduino granular synth code and it didn't sound that interesting. To see if it was the P2 version that was at fault I dug out an actual Arduino and programmed that with the same code and it still doesn't sound interesting. I guess I need to find some more interesting synth code...
Has anyone done a MIDI player for the P2? I know there are .WAV players but I'm interested in software that can take MIDI note numbers and play the corresponding notes.
No I think you'd first need to encode the instrument wavetable information into a mod file which include the synthesized samples in the data as well as the note sequences which reSound can play. Musical software or other tools on the PC or MAC may be able to do this conversion for you but YMMV.
No I think you'd first need to encode the instrument wavetable information into a mod file which include the synthesized samples in the data as well as the note sequences which reSound can play. Musical software or other tools on the PC or MAC may be able to do this conversion for you but YMMV.
I think a wavetable synth would have to be able to resample the sample waveforms to generate different pitches wouldn't it? Or are you suggesting that I have a separate sample for each MIDI pitch?
Playing a mod file just plays out the sample at different pitches for the different note frequencies by either skipping or interpolating the original audio data samples. I think that's basically how it works from memory.
Playing a mod file just plays out the sample at different pitches for the different note frequencies by either skipping or interpolating the original audio data samples. I think that's basically how it works from memory.
What is a MOD file? Does it contain samples or just note values?
Edit: I did Google the MOD file format but it still wasn't clear to me if the samples were per note or per voice and whether the playback engine did resampling.
It's a musical file format that contains samples and note sequences.
Samples are not per note they are per voice I believe.
Modfiles were big in the late 80-90s & demoscene etc and came from the Amiga which had a hardware chip (named Paula) that could accelerate its 4 channel playback which simplified things, and it really sounded cool at the time. Took the PC quite a bit longer to catch up there. I think the Gravis Ultrasound was one of the early mass marketed sound cards for PC's that could do decent wavetable synthesis (I had one back in the day), and there was a lag before games etc used it.
It's a musical file format that contains samples and note sequences.
Samples are not per note they are per voice I believe.
Modfiles were big in the late 80-90s & demoscene etc and came from the Amiga which had a hardware chip (named Paula) that could accelerate its 4 channel playback which simplified things, and it really sounded cool at the time. Took the PC quite a bit longer to catch up there. I think the Gravis Ultrasound was one of the early mass marketed sound cards for PC's that could do decent wavetable synthesis (I had one back in the day), and there was a lag before games etc used it.
So if reSound can play MOD files I guess it can do what I need it to do. I'll have to look over its documentation. I'm not sure that the low-level driver is open source though. I could only find a .binary file.
It's still very early days for P2. In time you'll probably get what you want with more audio synthesis options etc. I think both Ahle2 and I are optimistic in making use of HyperRAM/HyperFlash for larger sample playback too which would open up a lot more possibilities.
By the way I believe his SIDCOG has been ported to the P2 as well, which could synthesise audio for you, but you may need to develop the translation from midi notation to calling primitive note on/off routines at different frequencies. There may even be some P1 MIDI SPIN playback code you could look for and if you find that it may be possible to port to P2 as another option to the MIDI to MOD conversion method.
David,
reSound does resampling and can have up to 64 independent input channels mixed and played back, each at arbitrary frequency, volume and output into up to 8 outputs(pins). It can be used for pure sample playback, sound buffering and/or waveform output all at the same time. There are examples in the thread for common uses, but there will be more examples over time.
reSound will eventually be completely open source and part of the libs/examples included in Propeller Tool! I'm not there yet though, so there will be one more Beta comming out before the source will be public.
The Amiga had four independent audio DMA channels feeding four DACs. They could each operate at variable sample rate, and that's what the mod players did originally. This meant no software mixing needed on the Amiga, so very low CPU overheads. An important feature in a game when the CPU is only rated at 0.5 MIPS.
Many games had Amiga specific music just because of this format. The Wikipedia article doesn't acknowledge this point.
The first place I heard MOD tracker files was in the demo scene in the late 80s and early 90s. I think the demo scene used them more than anywhere else (including on PCs). Amiga games sure did have them, but I don't recall any PC games that used them. They probably did exist, but sound on PCs was pretty bad until later in the 90s. The earliest Sound Blaster cards were only mono 8bit with 23kHz max. It wasn't until later models that we got stereo (still limited to 22kHz in stereo). However, then we got sound cards like the Gravis and various other makers that would to multi channel wave playback with all kinds of advanced features. However, most games by then would either play CD audio (or just play mp3 like streams) or use general midi for music.
I know when I started in games in 1993, we were using something called "Miles Sound System" and it was all just playing samples for sound effects, and playing CD audio or MP3s for music. It could also play midi songs via things like the Roland MT-32, or GS-80, among a few other General Midi devices (including some sound cards like the Sound Blaster AWE32 which had a GM sound set for doing such things).
Of course, these days things like ACID Pro, are glorified trackers.
David,
reSound does resampling and can have up to 64 independent input channels mixed and played back, each at arbitrary frequency, volume and output into up to 8 outputs(pins). It can be used for pure sample playback, sound buffering and/or waveform output all at the same time. There are examples in the thread for common uses, but there will be more examples over time.
reSound will eventually be completely open source and part of the libs/examples included in Propeller Tool! I'm not there yet though, so there will be one more Beta comming out before the source will be public.
That sounds great! I've been playing with it a bit and it sounds very good. I'll look over the example code as you suggest.
MOD tracker music was very common on Amiga games, but equally many used custom routines like TFMX, DW, Hippel, etc
Too bad that my alltime favourite Amiga game music isn't in mod format. Maybe I'll need to write a TFMX player for the P2 as well?!
What's great is that there litterly is thousands upon thousands of 4 channel mod files available on the internet and most of them will play perfectly well on the P2 if they just fit in the HUB memory. I had a great time devolping the tracker player and finding all those tunes that are included in the example. Most of which I used to have on my actually Amiga back in the days. I had hundreds of mod files filling up the limited harddrive space that I had back then. (BBS anyone?)
MOD tracker music was very common on Amiga games, but equally many used custom routines like TFMX, DW, Hippel, etc
Too bad that my alltime favourite Amiga game music isn't in mod format. Maybe I'll need to write a TFMX player for the P2 as well?!
What's great is that there litterly is thousands upon thousands of 4 channel mod files available on the internet and most of them will play perfectly well on the P2 if they just fit in the HUB memory. I had a great time devolping the tracker player and finding all those tunes that are included in the example. Most of which I used to have on my actually Amiga back in the days. I had hundreds of mod files filling up the limited harddrive space that I had back then. (BBS anyone?)
How does one go about creating a MOD file? Do you have to use an Amiga?
David,
Great!! 👍I will make an interface for C as well. That seems to be what you prefere. It should not take much effort to convert from the Spin2 interface that I have already got. Then I have to get it working in PNut since it obvoiusly needs to work in Chips interpreter to be part of demo suite. Spin2 was not implemented in PNut when I began coding and I wanted to be sure that the interpreter and compiler were stable before switching over. I Think the time has come now.
Comments
David: the root problem should be fixed if you #include <propeller.h> and get the _wypin definition from there instead of relying on the built in one. Or, you can build the most recent github
#define P2_TARGET_MHZ 160 #include <sys/p2es_clock.h> ... _clkset(_SETFREQ, _CLOCKFREQ);Use clkfreq instead of _CLOCKFREQ, or you can also use _clockfreq() to get the value. Using either of those you don't need those 2 lines.
It's hard to tell really, there are so many variants of the clkfreq/clockfreq stuff in the code with differences depending on language.
If you try to use clkfreq inside of an __asm {} block, you get this from the compiler: "child killed: segmentation violation"
Example:
int frequency = 20000; int y; __asm { qfrac frequency, clkfreq getqx y }If I change it to this then it works:
int frequency = 20000; int y; int temp = clkfreq; __asm { qfrac frequency, temp getqx y }I tried some of the other flavors of clkfreq also, same result. It's okay if it's not allowed, but it should maybe not segfault
Yeah I feel that too. It seems difficult to remember which one to use.
#include <stdint.h> #include <propeller.h> #define AV_BasePin 8 #define LeftPin (AV_BasePin+6) #define RightPin (AV_BasePin+7) #define SAMPLE_RATE 250000 void main() { uint16_t output = 0; _pinstart(LeftPin, p_dac_dither_rnd | p_dac_600r_2v | p_oe, _clockfreq() / SAMPLE_RATE, 0); for (;;) { _wypin(LeftPin, output); output += 100; while (!_pinr(LeftPin)) ; } }In general only local variables are allowed in inline assembly, and clkfreq (in all its variations) is a global variable.
Edit: I did Google the MOD file format but it still wasn't clear to me if the samples were per note or per voice and whether the playback engine did resampling.
Samples are not per note they are per voice I believe.
Modfiles were big in the late 80-90s & demoscene etc and came from the Amiga which had a hardware chip (named Paula) that could accelerate its 4 channel playback which simplified things, and it really sounded cool at the time. Took the PC quite a bit longer to catch up there. I think the Gravis Ultrasound was one of the early mass marketed sound cards for PC's that could do decent wavetable synthesis (I had one back in the day), and there was a lag before games etc used it.
By the way I believe his SIDCOG has been ported to the P2 as well, which could synthesise audio for you, but you may need to develop the translation from midi notation to calling primitive note on/off routines at different frequencies. There may even be some P1 MIDI SPIN playback code you could look for and if you find that it may be possible to port to P2 as another option to the MIDI to MOD conversion method.
reSound does resampling and can have up to 64 independent input channels mixed and played back, each at arbitrary frequency, volume and output into up to 8 outputs(pins). It can be used for pure sample playback, sound buffering and/or waveform output all at the same time. There are examples in the thread for common uses, but there will be more examples over time.
reSound will eventually be completely open source and part of the libs/examples included in Propeller Tool! I'm not there yet though, so there will be one more Beta comming out before the source will be public.
The Amiga had four independent audio DMA channels feeding four DACs. They could each operate at variable sample rate, and that's what the mod players did originally. This meant no software mixing needed on the Amiga, so very low CPU overheads. An important feature in a game when the CPU is only rated at 0.5 MIPS.
Many games had Amiga specific music just because of this format. The Wikipedia article doesn't acknowledge this point.
I know when I started in games in 1993, we were using something called "Miles Sound System" and it was all just playing samples for sound effects, and playing CD audio or MP3s for music. It could also play midi songs via things like the Roland MT-32, or GS-80, among a few other General Midi devices (including some sound cards like the Sound Blaster AWE32 which had a GM sound set for doing such things).
Of course, these days things like ACID Pro, are glorified trackers.
Too bad that my alltime favourite Amiga game music isn't in mod format. Maybe I'll need to write a TFMX player for the P2 as well?!
What's great is that there litterly is thousands upon thousands of 4 channel mod files available on the internet and most of them will play perfectly well on the P2 if they just fit in the HUB memory. I had a great time devolping the tracker player and finding all those tunes that are included in the example. Most of which I used to have on my actually Amiga back in the days. I had hundreds of mod files filling up the limited harddrive space that I had back then.
Great!! 👍I will make an interface for C as well. That seems to be what you prefere. It should not take much effort to convert from the Spin2 interface that I have already got. Then I have to get it working in PNut since it obvoiusly needs to work in Chips interpreter to be part of demo suite. Spin2 was not implemented in PNut when I began coding and I wanted to be sure that the interpreter and compiler were stable before switching over. I Think the time has come now.