MML: What are people's actual complaints with the damn thing

[Arkhan]

Yes. All channels. Are people really ignorant of PCE audio stuffs??? Nobody reads the PCM threads I post either? I thought DDA mode was pretty common knowledge.

 PSG.txt from Magickit docs (I think it's in HuC PCEAS section too). Everything should be correct in that doc, except the LFO scaling part.

Yes, a lot of people are ignorant to a lot of PCE stuff.  We aren't exactly a crowded development community.   There's also always something to be learned.

Also, not a lot of people read documentation all the way through.  Some people read, and then forget due to not practicing what they read, and some of the PCE stuff is just sprawled about in weird places.


I knew all 6 channels could be switched to sample mode, and I'm sure OldMan did at one point, but mostly just mixed it up with the LFO or noise mode, since neither of us have looked at that particular stuff in awhile.   It's two modes we don't really use/talk about, mixed up.  No biggy. 

I don't think either of us has really done anything sound-centric in awhile.   I've been busy making games (Atlantean and Inferno), and he's been inhaling plastic fumes, and playing with the CD card stuff.



Also, I don't know about anyone else, but I tend to find your posts hard to read.  You don't seem to proofread what you post, and it's often formatted in a way that isn't very conducive to easy-reading.

So, we end up with a wall of text that has broken sentences via fragmentation, tense change, idea change, or straight up grammatical errors.   It's kind of effort-y to sit and read sometimes.

I know I've told you this in the past.   

If you're trying to document or explain something, proofreading for accuracy and readability is pretty important.   Formatting is a skill in and of itself.




Now, to some of the stuff going on in the thread: As OldMan said, you can take a sample, convert it to 5 bit values, and break it into 32 byte chunks, and store these as custom waveforms.  I swear I've explained it on here before, and it might be in the manual for Squirrel.  I forget, because I've not looked at in a long time.

Then, you can play a note, change the  wave, keep playing the note, and basically string the sample back together.

You won't get the same quality as DDA mode, but it's doable.  I've played around with it before.

You just make sure to use the same note that you sampled in at.

I am not sure if I still have an example of it.  I was doing it for kick drums and ended up liking the completely PSG based kick drum I made more, so I stopped caring for the time being.

What "hack" from OldMan are you talking about that will produce a hum? 

I've thought about it a few times about how to make the samples an easy-to-add-to-MML piece. 

Notation wise, it should be pretty straight forward, and we'd probably end up writing a converter to produce the text-data that you'd paste into the file for a given sample. 

I have to see what symbols are unused in MML, because we'd be basically extending MML and making it a little less standard possibly.

Maybe have samples as %# to indicate which sample data to use, instead of the @# that is in use for waves.

I'll dig around MSXLand and see what they're used to.  They often don't bother with samples though, since you can do plenty without.   

They've got 3 PSG channels, 9 FM channels, and 5 SCC channels to work with, lol.

Funny thing about MSX is that the SCC is real similar to the PCE, except it uses 8 bit values instead of 5, but doesn't support stereo panning.

I prefer the stereo panning

[Bonknuts]

Yes, a lot of people are ignorant to a lot of PCE stuff.  We aren't exactly a crowded development community.   There's also always something to be learned.

Also, not a lot of people read documentation all the way through.  Some people read, and then forget due to not practicing what they read, and some of the PCE stuff is just sprawled about in weird places.


I knew all 6 channels could be switched to sample mode, and I'm sure OldMan did at one point, but mostly just mixed it up with the LFO or noise mode, since neither of us have looked at that particular stuff in awhile.   It's two modes we don't really use/talk about, mixed up.  No biggy. 

I don't think either of us has really done anything sound-centric in awhile.   I've been busy making games (Atlantean and Inferno), and he's been inhaling plastic fumes, and playing with the CD card stuff.

Well, this kinda of stuff gets talked about on other game forums (not centric to PCE). PCE is kinda known for decent samples, sort of how Genesis is known for crappy samples. It was also on wiki, which people love to take as gospel. It's been part of a lot of sound discussions over the years too (all outside this forum). Did I mention it's on wiki? My point being. With all the "experts" out there that don't even write code for these platforms, I would have figured the homebrew community would at least know the basic; samples are easy to do on PCE; can do it on any channel or all channels. Maybe not the exact details, but at least that much.

I'm not knocking anyone. I'm just surprised.

Also, I don't know about anyone else, but I tend to find your posts hard to read.  You don't seem to proofread what you post, and it's often formatted in a way that isn't very conducive to easy-reading.

So, we end up with a wall of text that has broken sentences via fragmentation, tense change, idea change, or straight up grammatical errors.   It's kind of effort-y to sit and read sometimes.

 Other than some grammatical errors (I don't proof read and I type it out fairly quick - as I'm thinking through it). I don't have time to put things into an easy to read essay format. Ideas and information tends to get packed into paragraphs. It also requires some level knowledge to make the connections I'm presenting (again, I don't have time to explain redundant information).

Now, to some of the stuff going on in the thread: As OldMan said, you can take a sample, convert it to 5 bit values, and break it into 32 byte chunks, and store these as custom waveforms.  I swear I've explained it on here before, and it might be in the manual for Squirrel.  I forget, because I've not looked at in a long time.

Then, you can play a note, change the  wave, keep playing the note, and basically string the sample back together.

You won't get the same quality as DDA mode, but it's doable.  I've played around with it before.

You just make sure to use the same note that you sampled in at.

I am not sure if I still have an example of it.  I was doing it for kick drums and ended up liking the completely PSG based kick drum I made more, so I stopped caring for the time being.

What "hack" from OldMan are you talking about that will produce a hum? 

I'm pretty sure I've mentioned this like 5 times already ;_;

You can't fill the 32byte buffer unless you turn the channel "off". Turning the channel off, also has the same effect as setting the volume to zero. When you re-enable the channel, it's the same as setting the volume to max (or whatever volume setting you used before). On all PCEs with the original 6280 (the non A revision), large changes in the volume causes an audible 'pop' on the DAC. There's one for turning off the channel, and one for turning on the channel. The direction of the pop, relative to zero line, is directly related to the change in volume (from no volume to max volume creates a positive side "pop" and max to none creates a negative side "pop"). It's not a small "pop" or click; it's pretty loud in relation to the audio. So if you update the waveform buffer 60times a second, you'll get a 60hz hum. The hum asides, 60x32 = 1.9khz. That's pretty crappy of a playback rate to begin with, but the clicks/pops are the worse part. Bump it up to 120hz with every update, then 3.84khz - still crappy and you up the range of the clicks into a higher the buzz frequency.

 Drumkit type samples are super forgiving of a lot of things, including bit depth, extreme jitter, and other artifacts. In Genesis games, where the jitter is soo bad that the voices have the distinct "genesis" throaty sound to them - the drumkit samples on the same PCM driver don't exhibit these audible artifacts. So maybe that's why you didn't hear it.

 Does that make sense? I used to have pics showing what this looks like (recordings). On any system with an updated 6280A revision cpu, these pops from the volume change are barely there. Only the SuperGrafx, and some models of CoreGrafx I, have this updated revision (later models went back to the original cpu model).

 I mean, If you're just updating the waveform to add "timbre" like effects, at lower than 30hz, that's not sample playback - that's something else. I'm not sure if you're confusing the two. And it'll be more "clickity" than a hum or buzz, simply because the rate is slower.

I've thought about it a few times about how to make the samples an easy-to-add-to-MML piece. 

Notation wise, it should be pretty straight forward, and we'd probably end up writing a converter to produce the text-data that you'd paste into the file for a given sample. 

I have to see what symbols are unused in MML, because we'd be basically extending MML and making it a little less standard possibly.

 Aren't PCE waveforms already none standard for MML? I mean, setting a waveform to a channel? Why not have some sort of "null" type of sample, where all notes for the waveform are interpreted as different samples.

[ccovell]

To add to this discussion:

If you're working on a project and need a channel free for sampled sound effects, and your target is (Super) CD, use the ADPCM hardware.  It's there, free, high-enough-quality, and costs you no CPU time or CD program RAM space.

I guess some people don't want to read, so try watching the few PCE dev tutorials I have recently put on YouTube, where I cover in breezily low detail the capabilities of the PC-Engine & its sound hardware.  (ie: the things reminded above)   https://www.youtube.com/user/wwwchrismcovellcom/videos

You can play around with waveforms and test the audible "popping" using my PCMgine waveform tool, as there is a function that swaps samples around at a fixed rate to channel 0.  Link: http://www.chrismcovell.com/creations.html

[Bonknuts]

Chris, you should do section on the Pro Wrestling games (three on the PCE) that do waveform corruption. If a channel is playing, and write to the DDA port, the sample will overwrite that playback position in the waveform buffer. These games do this to get a single channel metallic timbre change effect. I always thought it was interesting and underutilized.

 About the whole waveform updating thing, 32byte, while the channel is playing - it does make for some interesting sound FX:http://www.pcedev.net/audio/bloodywolf/BW_test1.mp3
http://www.pcedev.net/audio/bloodywolf/BW_test2.mp3
http://www.pcedev.net/audio/bloodywolf/BW_test3.mp3

(the low frequency playback of the channel masks the popping).

[TheOldMan]

So if you wanted 108hz tempo, set the TIMER to 6991 khz, set the software down counter to 108 (instead of writing it to the TIMER counter port), and on each TIRQ call decrement it. When it reaches 00, pass control to the PSG player. Otherwise, on each call you can now write a sample to any channel you like.

I understand the theory (sort of). Here's the problem I have....

I assume setting the TIMER to 6991Khz is meant to lock in a particular clock for the timer.
If I set the down counter to 120 (for 120 beats per minute), I will get timer irqs at the 'clock' frequency. If I decrement the down count, and call the psg driver when the counter hits 0, how do I do 32'nd notes? There are 32 of those per beat, and I only get 1 call.

Now, assume it works (and I think it can, by appropriate choices for the parameters). How do I speed it up? Change the value for the down counter? So i would need a table for the different  tempo/downcounts? Okay, and doable. So it should work.

But now I'm effectively duplicating what the hardware does in software.
And I would still have to send out a sample, regardless of whether the psg driver runs or not, wouldn't I? Otherwise, I'd end up missing samples.

I can see that it should work, but it's not obvious (to me, anyway) how it would be implemented.

[Arkhan]

Well, this kinda of stuff gets talked about on other game forums (not centric to PCE). PCE is kinda known for decent samples, sort of how Genesis is known for crappy samples. It was also on wiki, which people love to take as gospel. It's been part of a lot of sound discussions over the years too (all outside this forum). Did I mention it's on wiki? My point being. With all the "experts" out there that don't even write code for these platforms, I would have figured the homebrew community would at least know the basic; samples are easy to do on PCE; can do it on any channel or all channels. Maybe not the exact details, but at least that much.

I'm not knocking anyone. I'm just surprised.

Yeah, I don't go to other forums because I don't really need that many technobabble places to go to and watch people ramble alot, lol.   I got enough of that watching C64 people argue about the dumbest shit for hours on end.

The homebrew community doesn't have to be expected to know how to do samples.  Besides, on paper it's always easy.  In practice, it may not always be, as other problems (especially with our toolsets) can arise and create issues when trying to do this with a game.

Because it's all hobbyism, and a game platform, the main focus seems to be on the game part.  Not the audio engineering.

Other than some grammatical errors (I don't proof read and I type it out fairly quick - as I'm thinking through it). I don't have time to put things into an easy to read essay format. Ideas and information tends to get packed into paragraphs. It also requires some level knowledge to make the connections I'm presenting (again, I don't have time to explain redundant information).

Yeah, I'm just saying, if you proofread and form better paragraphs/phrasing, you might find that your own points you are trying to make will get across better.   I've lost count of how many times I re-read things you've posted and basically have to try and auto-correct it into a sensible sentence.   Sometimes I just scroll on by and give up.

I'm pretty sure I've mentioned this like 5 times already ;_;

If you did, I missed it because ^^^^^^^^^^^

You can't fill the 32byte buffer unless you turn the channel "off". Turning the channel off, also has the same effect as setting the volume to zero. When you re-enable the channel, it's the same as setting the volume to max (or whatever volume setting you used before). On all PCEs with the original 6280 (the non A revision), large changes in the volume causes an audible 'pop' on the DAC. There's one for turning off the channel, and one for turning on the channel. The direction of the pop, relative to zero line, is directly related to the change in volume (from no volume to max volume creates a positive side "pop" and max to none creates a negative side "pop"). It's not a small "pop" or click; it's pretty loud in relation to the audio. So if you update the waveform buffer 60times a second, you'll get a 60hz hum. The hum asides, 60x32 = 1.9khz. That's pretty crappy of a playback rate to begin with, but the clicks/pops are the worse part. Bump it up to 120hz with every update, then 3.84khz - still crappy and you up the range of the clicks into a higher the buzz frequency.

 Drumkit type samples are super forgiving of a lot of things, including bit depth, extreme jitter, and other artifacts. In Genesis games, where the jitter is soo bad that the voices have the distinct "genesis" throaty sound to them - the drumkit samples on the same PCM driver don't exhibit these audible artifacts. So maybe that's why you didn't hear it.

 Does that make sense? I used to have pics showing what this looks like (recordings). On any system with an updated 6280A revision cpu, these pops from the volume change are barely there. Only the SuperGrafx, and some models of CoreGrafx I, have this updated revision (later models went back to the original cpu model).

 I mean, If you're just updating the waveform to add "timbre" like effects, at lower than 30hz, that's not sample playback - that's something else. I'm not sure if you're confusing the two. And it'll be more "clickity" than a hum or buzz, simply because the rate is slower.

I gave a shit exclusively about drums, so this would likely be why I didn't hear anything.   And, as I said, you can achieve a more than great kickdrum without samples, so I stopped screwing around with it for the time being.
 

Aren't PCE waveforms already none standard for MML? I mean, setting a waveform to a channel? Why not have some sort of "null" type of sample, where all notes for the waveform are interpreted as different samples.

the waveforms operate as the instrument being used.  This is completely normal. This is straight out of PC98/MSX MML usage.  You use @# to specify what voice to use for playback. 

What your describing is how you might define some sort of sampling drumkit, and I've already considered that, as it would lend itself well to how percussion is already handled with Squirrel.

[DarkKobold]

The homebrew community doesn't have to be expected to know how to do samples.  Besides, on paper it's always easy.  In practice, it may not always be, as other problems (especially with our toolsets) can arise and create issues when trying to do this with a game.

Because it's all hobbyism, and a game platform, the main focus seems to be on the game part.  Not the audio engineering.

I have to agree with Arkhan. My goal in creating a homebrew wasn't to learn the deeper details of the PC Engine hardware. Catastrophy isn't going to be stretching the system to its limits. Hopefully, if and when its released, people will think it is a fun, high quality game for a system the love.

I feel like it gets forgotten that I'm not capable of coding in ASM. Sure, there is plenty of info on the psg... that is totally useless from a HuC perspective. Squirrel makes it stupid-easy to integrate music and SFX into a HuC program. Its just damn hard to make decent sounding SFX in squirrel.

 It depends on what your goal is, is it to encourage more 'less capable' homebrewers to make games? If you don't keep it simple, its not going to get used by people like me.

[Bonknuts]

Here's an extreme example of using the 32byte waveform ram as a "buffer" on the SGX:http://www.pcedev.net/6280a/sgx_dump.wav

5bit audio. The playback is something like 56khz! It uses a 1747hz step TIMER setup, and fills the channel using 32 samples. The cpu resource to drive that is super low. The same file, which I can't find at the moment, on PCE sounds horrible (because of the poping on the DAC - it's a loud constant screech). The above wave was recorded from my SGX.

 Such a rate seems unrealistically high. Overkill. But, at such a high rate you could interleave every other sample from a different stream. Now you have two channels of 5bit, playing at 28khz. This is actually how the Genesis mixes channels - instead of mixing them in the digital domain, it just interleaves them at a right fast rate. And because the FM chip in the Genesis is a single 9bit DAC, the accumulation allows higher than 9bit resolution in the analog domain (9bit+9bit = 10bit, etc). So the same on PCE, two channels at 28khz or PMW of two samples for a single channel of 6bit depth at 28khz (driven at 56khz). Given the SGX's filter range, you could probably extend that to four 5bit channels at 14khz, or two 6bit channels at 14khz.

 Why am I mentioning this? Who cares about the SGX except SGX devs? Because there is a solution on the PCE. Remember how I said the pop on the DAC is in relation to the direction of the volume change? What if you reserved two channels. When you turn off one channel, you turn on another (at the same volume). The two different directional pops will cancel themselves out (simple rule: amplitudes add together). But there is a slight delay, in nano seconds IIRC, as to when channel volumes are processed. So it's possible there would be a super slight-tiny hum (because the spikes on perfectly overlap in the time domain; but the analog filtering on the PCE should lessen this even further). I tested out the cancellation on a real PCE, but I haven't tested it with streaming on the PCE itself. And at a rate of 56khz, two hardware channels can get back two or more channels with interleaving the streaming data.

 This sounds easy, but timing has to be precise. If run off the TIRQ instead of the H-int routine, it's mean super tight code for H-int as not to delay TIRQ by too much. Thankfully, with one channel being off (available for 32byte data update), it's only the turning on of one and off of the other, that actually matters in the time domain. I'd probably even buffer in two extra samples (bytes) - so assume 30 bytes/samples per update (bringing it down to 52khz for the base frequency), and allowing any delay time to be covered by the last two samples (last two of 32).

 Does that make sense? tl;dr - wall of text: you should in theory be able to use 32byte buffer method to play high rate samples on the original PCE without pops on the DAC, and have hardware mix multiple sample streams via high rate interleaving, but it requires using two hardware channels. Btw - some Amiga games/demo do this; the faster models can output up to 56khz, so they interleave sample data to extend the 4 channels into 8 channels.

[elmer]

I'll take your question if we can settle for low quality as a compliment, because if you've seen my abilities so far to make this game I think it'd be a given that we have to settle with low quality

On the contrary, I'm really impressed with what you guys have done. 

You game has a real charm to it that a lot of professional games don't. 

Don't they use the same chip? I'm not sure how the sound chip works, but a sample would have to disrupt the music to play.

Yes, samples use the same PSG chip as the music on the basic PCE.

So you have to drop out music channels (temporarily) in order to play a sample instead.

It's no different to how sound-effects also use the same PSG chip, and how sound-effects cause music channels to drop out (temporarily).

It's all up to the sound driver (aka music driver/System Card Player/Squirrel Player) to deal with the technical details, and for the musician that creates the tunes, and usually the sound effects too, to keep in mind when they're assigning which hardware voices play which parts of a tune or a sound effect.

The problem with the System Card Player (and therefore Squirrel) is that it doesn't support sample playback, and that it would be an ugly hack to try to get it to do so.

Also, I'm not sure how I understand how you'd ever play a sample, since you'd have to recreate it with the various waveforms available on the PC Engine.

Nope, the PSG already supports sample playback ... but it's entirely CPU-driven, and it costs a noticable amount of CPU time.

My point being. With all the "experts" out there that don't even write code for these platforms, I would have figured the homebrew community would at least know the basic; samples are easy to do on PCE; can do it on any channel or all channels. Maybe not the exact details, but at least that much.

From what I can see, it's just not relevent to most homebrew developers here, both because the toolchain and sample code don't exist, and becaue it's just not been *needed* in the few homebrew games that have been developed.

If you're working on a project and need a channel free for sampled sound effects, and your target is (Super) CD, use the ADPCM hardware.  It's there, free, high-enough-quality, and costs you no CPU time or CD program RAM space.

Absolutely! The capability just needs to be integrating into the toolchain and sound driver.

I guess some people don't want to read, so try watching the few PCE dev tutorials I have recently put on YouTube, where I cover in breezily low detail the capabilities of the PC-Engine & its sound hardware.  (ie: the things reminded above)   https://www.youtube.com/user/wwwchrismcovellcom/videos

I absolutely love your disection of different game's usage of the PSG.

I assume setting the TIMER to 6991Khz is meant to lock in a particular clock for the timer.

Yes, the problem that is being discussed is (AFAIK) how to play samples and music at the same time, and how to be able to define certain "instruments" and "effects" as one that play a 6991Hz sample instead of using the PSG's 32-byte waveform.

So the timer would be locked at 6991Hz (it's maximum rate).

If I set the down counter to 120 (for 120 beats per minute), I will get timer irqs at the 'clock' frequency. If I decrement the down count, and call the psg driver when the counter hits 0, how do I do 32'nd notes? There are 32 of those per beat, and I only get 1 call.

If someone were to implement that kind of scheme, then you'd get as many calls as you like ... it's just a case of defining your tempo as something that's an integer multiple of 1/6991 seconds.

But while you can say that you *need* fine tempo adjustment for some reason ... most of the old games were done without it.

And ... what's the fuss with 1/32 notes (a demi-semi-quaver)?

Doesn't the System Card Player already limit you to 1/16 notes (a semi-quaver)?

From what I can see, it defines time as a multiplier of 60Hz ticks per 1/16 note.

That matches up with the calculations that I did a long time ago ...

Code: [Select]

BPM in terms of 1/4 note lengths.

TEMPO1          EQU     5                       ;clk note TEMPO CONTROL (180 bpm)
DSQ1            EQU     TEMPO1/2                ;    1/32 DEMI-SEMI-QUAVER
SQ1             EQU     TEMPO1                  ;  5 1/16 SEMI-QUAVER
QV1             EQU     SQ1*2                   ; 10 1/8  QUAVER
DQV1            EQU     QV1+SQ4                 ; 15 3/16 DOTTED QUAVER
CR1             EQU     QV1*2                   ; 20 1/4  CROTCHET
DCR1            EQU     CR1+QV4                 ; 30 3/8  DOTTED CROTCHET
MN1             EQU     CR1*2                   ; 40 1/2  MINIM
DMN1            EQU     MN1+CR4                 ; 60 3/4  DOTTED MINIM
SB1             EQU     MN1*2                   ; 80 1    SEMI-BREVE
DSB1            EQU     SB1+MN4                 ;120 3/2  DOTTED SEMI-BREVE

TEMPO2          EQU     6                       ;clk note TEMPO CONTROL (150 bpm)
DSQ2            EQU     TEMPO2/2                ;  3 1/32 DEMI-SEMI-QUAVER
SQ2             EQU     TEMPO2                  ;  6 1/16 SEMI-QUAVER
QV2             EQU     SQ2*2                   ; 12 1/8  QUAVER
DQV2            EQU     QV2+SQ2                 ; 18 3/16 DOTTED QUAVER
CR2             EQU     QV2*2                   ; 24 1/4  CROTCHET
DCR2            EQU     CR2+QV2                 ; 36 3/8  DOTTED CROTCHET
MN2             EQU     CR2*2                   ; 48 1/2  MINIM
DMN2            EQU     MN2+CR2                 ; 72 3/4  DOTTED MINIM
SB2             EQU     MN2*2                   ; 96 1    SEMI-BREVE
DSB2            EQU     SB2+MN2                 ;144 3/2  DOTTED SEMI-BREVE

TEMPO3          EQU     7                       ;clk note TEMPO CONTROL (128 bpm)
DSQ3            EQU     TEMPO3/2                ;    1/32 DEMI-SEMI-QUAVER
SQ3             EQU     TEMPO3                  ;  7 1/16 SEMI-QUAVER
QV3             EQU     SQ3*2                   ; 14 1/8  QUAVER
DQV3            EQU     QV3+SQ3                 ; 21 3/16 DOTTED QUAVER
CR3             EQU     QV3*2                   ; 28 1/4  CROTCHET
DCR3            EQU     CR3+QV3                 ; 42 3/8  DOTTED CROTCHET
MN3             EQU     CR3*2                   ; 56 1/2  MINIM
DMN3            EQU     MN3+CR3                 ; 84 3/4  DOTTED MINIM
SB3             EQU     MN3*2                   ;112 1    SEMI-BREVE
DSB3            EQU     SB3+MN3                 ;168 3/2  DOTTED SEMI-BREVE

TEMPO4          EQU     8                       ;clk note TEMPO CONTROL (112 bpm)
DSQ4            EQU     TEMPO4/2                ;  4 1/32 DEMI-SEMI-QUAVER
SQ4             EQU     TEMPO4                  ;  8 1/16 SEMI-QUAVER
QV4             EQU     SQ4*2                   ; 16 1/8  QUAVER
DQV4            EQU     QV4+SQ3                 ; 24 3/16 DOTTED QUAVER
CR4             EQU     QV4*2                   ; 32 1/4  CROTCHET
DCR4            EQU     CR4+QV3                 ; 48 3/8  DOTTED CROTCHET
MN4             EQU     CR4*2                   ; 64 1/2  MINIM
DMN4            EQU     MN4+CR3                 ; 96 3/4  DOTTED MINIM
SB4             EQU     MN4*2                   ;128 1    SEMI-BREVE
DSB4            EQU     SB4+MN3                 ;192 3/2  DOTTED SEMI-BREVE

I can see that it should work, but it's not obvious (to me, anyway) how it would be implemented.

It's easy-enough with counters and branches ... but it slows down every single timer interrupt by 8 cycles for a decrement-zero-page, branch-if-zero.

That's 928 cycles per frame, 2+ scanlines, just to have a finely-adjustable tempo that is rarely (if ever) needed.

It's certainly possible, but it seems like a very high cost to allow both samples and a finely-adjustable tempo, and I really don't see the point.

the waveforms operate as the instrument being used.  This is completely normal. This is straight out of PC98/MSX MML usage.  You use @# to specify what voice to use for playback. 

What your describing is how you might define some sort of sampling drumkit, and I've already considered that, as it would lend itself well to how percussion is already handled with Squirrel.

Sure, aren't instruments normally defined as both a waveform and an associated volume envelope?

Defining 7KHz samples as just an extension to the drum kit makes a lot of sense from a "music production" standpoint.

 This sounds easy, but timing has to be precise. If run off the TIRQ instead of the H-int routine, it's mean super tight code for H-int as not to delay TIRQ by too much. Thankfully, with one channel being off (available for 32byte data update), it's only the turning on of one and off of the other, that actually matters in the time domain. I'd probably even buffer in two extra samples (bytes) - so assume 30 bytes/samples per update (bringing it down to 52khz for the base frequency), and allowing any delay time to be covered by the last two samples (last two of 32).

 Does that make sense? tl;dr - wall of text: you should in theory be able to use 32byte buffer method to play high rate samples on the original PCE without pops on the DAC, and have hardware mix multiple sample streams via high rate interleaving, but it requires using two hardware channels. Btw - some Amiga games/demo do this; the faster models can output up to 56khz, so they interleave sample data to extend the 4 channels into 8 channels.

It's very clever and nice that that can be done! 

But, practically, I sure wouldn't want to interleave 2 samples together in realtime on the PCE while I'm trying to run a game, and also lose both the individual panning and volume envelopes on each sample.

And "yes" ... I know that you can get the volume envelope capability back with another multiply ... but doing so slows things down again.

Using the technique for a single-channel sample might make some sense, although I'm not sure that a lot of musicians would be happy to lose 2 channels (temporarily) in order to gain the single sample channel. 

[Bonknuts]

But, practically, I sure wouldn't want to interleave 2 samples together in realtime on the PCE while I'm trying to run a game, and also lose both the individual panning and volume envelopes on each sample.

And "yes" ... I know that you can get the volume envelope capability back with another multiply ... but doing so slows things down again.

Using the technique for a single-channel sample might make some sense, although I'm not sure that a lot of musicians would be happy to lose 2 channels (temporarily) in order to gain the single sample channel. 

 Volume can be implemented via a look up table. I would never use multiplication in real time for soft(ware) volume.  I mean it's as simple as ldx $0000 and lda vol_table,x. An extra 5 cycles per sample to handle volume over not using it. I usually implement this as self modifying code, and just adjust the table position in the array on a fame basis because it doesn't need to be done on a per sample basis (volume envelope changes happen on a low frequency basis.. like 60hz or lower). If you mixed 4channels at 5bit depth for 14khz output, that's 1% cpu resource per channel to do software volume on. Yeah, nothing's free - but that's pretty good.

Interleaving two or more streams really isn't any harder than handling a stream independently. It's actually really nice because it means no adding of any samples, and no translation tables to convert it into 10bit output for paired channel playback. I think that's pretty good.

 From what I've seen of PCE games that do use samples, a good 90% don't even use hardware volume control for DDA playback - they leave it fixed (no envelopes). Things like drumkit samples are usually a fixed volume state, as well as sound FX samples. Some Genesis games mix up to four samples for the DAC, and never use any volume control on the individual streams.

 Maybe there's some confusion here in how one would use samples. If you're using it as a musical instrument, with loop points, then I can see the need for volume envelopes. But most of the time, samples are just drumkits, one off sounds such as orchestra hits, and sound FX. Volume rarely plays a role in those types of samples. I mean, it can but it's not needed and isn't a big deal if absent. Yeah, panning goes out the window.. but look at what you gain. You have panning on the rest of the channels anyway, so it's not like you completely lost panning FX. And if you really need volume, eat the 1% overhead per stream. Heh - you'd probably gawk at my 4 channel@8bit 15khz player resource requirement. Everything has trade offs. Just like Arkhan wanting Timer resolution tempo control. If you're willing to accept the performance requirement, then you gain whatever additional ability.

 I guess I should of mentioned that my post with the 32byte buffer thing, wasn't meant as something to add to MML or whatever. It's just a technique. And as Arkhan was exploring with it, it can be used to do some things on the PCE that's above and beyond what any devs were doing back in the day. I was just presenting how the concept could work and a relative example of it working. That is, if taken outside of the PSG bios player.

[esteban]

Here's an extreme example of using the 32byte waveform ram as a "buffer" on the SGX:
http://www.pcedev.net/6280a/sgx_dump.wav

Damn. That sounds great.

[TheOldMan]

*** WARNING: Wall of text below. If you're not interested in technical arguements, or have not been avidly following ths thread, you may ignore this post ***

Quote from: TheOldMan on Today at 12:38:03 AM

    If I set the down counter to 120 (for 120 beats per minute), I will get timer irqs at the 'clock' frequency. If I decrement the down count, and call the psg driver when the counter hits 0, how do I do 32'nd notes? There are 32 of those per beat, and I only get 1 call.

If someone were to implement that kind of scheme, then you'd get as many calls as you like ... it's just a case of defining your tempo as something that's an integer multiple of 1/6991 seconds.

I can't define the tempo. Tempo is how fast the song plays (not how fast the irq tick is). If a song is at 120 BPM ( a popular tempo),
that means it plays 120 whole notes in 1 minute. Or 20 in 1 second.

I -can- define how  many down counts are used before the psg player is called. So yes, in 1 second I can get as many calls as
needed. But I still only get 1 call per group of counts.
In order to change the *tempo*, I have to change the counter limit, which the psg player does, by changing the timer interval. I understand
it *can* be done, but it's a bit more complicated than just "do this".
How would you deal with interrupts in such a situation? (Remember we are getting 6991 of them every second) There's no guarantee that
an irq won't occur while the player is updating. Do those interrupts count towards the next psg call?
And at 6991 timer irqs / sec, do we even have enough time to handle this? And run a game? At 60 fps?

Those are the things I don't understand about how this would work. (And keep in mind, irq problems are a real thing, as rovers problem shows)

But while you can say that you *need* fine tempo adjustment for some reason ... most of the old games were done without it.

You never played a game where the boss attacked faster as you did damage?
Listen closely; the music usually speeds up, too.

And ... what's the fuss with 1/32 notes (a demi-semi-quaver)?
Doesn't the System Card Player already limit you to 1/16 notes (a semi-quaver)?

I'm not sure if the system card limits you or not, but that wasn't the point of the 1/32 note question.
*IF* you are limited to -only- vsync, 1/32nd notes are impossible. They require a fraction of a frame.
But, if you use the timer irq, you can update at  less than 1 frame. That was the point.
So the timer -is- needed. And without using the timer, There's no way to get 1/32 notes.

(And. as an aside, 1/32 notes are possible to play in the player. They just take 1 tick, instead of the 1.5 they should be,
causing them to de-sync. Which is probably why they aren't supported. And how we found the trick below, thanks to
a bug in squirrel during development.)

However, with the timer, we can use the following trick: Write the 32nd notes as 16th notes. Double all the other
note times. And run the song at double the tempo. Sounds exactly the same.
And you can do 64th notes by doubling again. Makes for some smoother arepeggios, and doesn't do too bad
as a slide. (something the psg player is lacking in)

And before anyone asks, you can change the tempo before a measure, double the note length for just that measure,
and then re-set the tempo. Provided you have a fixed tempo (ie, you don't call the psg setTempo() function to speed
the whole song up)

It's certainly possible, but it seems like a very high cost to allow both samples and a finely-adjustable tempo, and I really don't see the point....

This sounds easy, but timing has to be precise. If run off the TIRQ instead of the H-int routine, it's mean super tight code for H-int as not to delay TIRQ by too much

Which is part of the reason I was asking about running it from HSync.
*IF* it can run off of hsync...
1) you could do a quick sample update  (lda  [samples],x / sta )
2) it would be at a decent rate (15 Khz, right?)
3) It could be hooked in via the user hsync hook.

I'm not at all sure it would work, and would require a channle just for samples. But it's interesting to think about....
I'll give you one more thing to think about, too. The psg player keeps a bit-mapped byte to indicate which channels are in use.
It should be possible (though not necessarily quick) to check the byte and find an available channel

The question is ... is the System Card Player, and the IRQ handling in both the System Card and HuC smart enough to handle not only timer-followed-by-vblank, but also vblank-follow-by-timer???

For the player, it is. Once the player starts processing, it locks itself out from further calls until it is done.

[elmer]

Folks, can we all get on the same page with music-theory? 

Tempo is the basic timing for a tune, it says how often a "beat" happens per second.

A "note length" is just a way of specifying relative (and not absolute) timings for events, so a note, a 1/2 note, a 1/4 note, or the wonderful British names, a semibreve, a minim and a crotchet.

These are further modified by having "dotted" notes that adds another fraction of the note to the lengths.

See https://en.wikipedia.org/wiki/Note_value
See https://en.wikipedia.org/wiki/Tempo

The point is ... the note lengths specify time relative to other note lengths, and NOT in terms of absolute fractions of a second.

It is the time-signature and tempo that define the link between the note length and absolute time in beats-per-minute (BPM).

A "beat" is commonly defined as 1/4 note (especially in videogames), but that isn't an absolute rule.

But I'll use that 1/4 note = 1 beat convention for the rest of this.

Once you realize that note length are just a notation for relative time, you can see that changing the tempo (BPM) is just another way of saying that you're changing how long a 1/4 note is.

Here are the common "conventional" timings for running a music-driver on a console/old-computer ...

NTSC

Base Tempo = 5/60s per 1/16th  = 20/60s per 1/4 note  = 180.0 bpm  (60 * 60/20)
Base Tempo = 6/60s per 1/16th  = 24/60s per 1/4 note  = 150.0 bpm  (60 * 60/24)
Base Tempo = 7/60s per 1/16th  = 28/60s per 1/4 note  = 128.6 bpm  (60 * 60/28)
Base Tempo = 8/60s per 1/16th  = 32/60s per 1/4 note  = 112.5 bpm  (60 * 60/32)
Base Tempo = 9/60s per 1/16th  = 36/60s per 1/4 note  = 100.0 bpm  (60 * 60/36)

PAL50

Base Tempo = 4/50s per 1/16th  = 16/50s per 1/4 note  = 187.5 bpm  (60 * 50/16)
Base Tempo = 5/50s per 1/16th  = 20/50s per 1/4 note  = 150.0 bpm  (60 * 50/20)
Base Tempo = 6/50s per 1/16th  = 24/50s per 1/4 note  = 125.0 bpm  (60 * 50/24)
Base Tempo = 7/50s per 1/16th  = 28/50s per 1/4 note  = 107.1 bpm  (60 * 50/28)
Base Tempo = 8/50s per 1/16th  = 32/50s per 1/4 note  =  93.8 bpm  (60 * 50/32)


The table above shows that you can achieve a number of different "tempo" settings and still run your music driver in the vsync interrupt.

It also shows that speeding-up a tune (i.e. in a boss-attack) just involves changing the delay-per-quarter-note.

That's how games used to do it ... not by changing the number of times-per-second that the music driver was called!!! 

***************************

Now, practically, in videogame music-drivers, the programmer has to make a decision about how to encode the note-lengths.


The simplest choice is just to use the tune's BPM to calculate the length of a note (in terms of 1/60s aka the number of "calls" to the music-driver) when you build the game.

For example, on an NTSC console (i.e. America/Japan and the PC Engine), if your tune is playing back at 128 BPM (which is your closest approximation for 120 BPM), then you'd store the length of a quarter-note as "28", meaning that you call the music-driver 28 times before the next note (see the table above).

That's the fastest-to-process when playing back the music, but it means that you can't easily change the tempo during playback.

Once the timing is baked into the tune data like that, the only way to change the tempo is to change how often the music-driver itself is called per second.

Now, most games do NOT change the tempo during playback, and so that's a common way to store the note-lengths.

The System Card Player can store tune data in this way, and it calls it the "Direct" length mode.

This appears to be the method that Arkhan and TheOldMan have chosen to use for Squirrel, and it's why they can't change the tempo of a song without changing how often the Squirrel Player is called per second.

It is not the only way to encode tune data, and it is not even the only way that the System Card Player supports.


Another way to store the length of a note is to store it in the original terms, for-example the length as a number 1..16 in terms of 1/16th notes, or the number 1..32 in terms of 1/32nd notes.

If you do things this way, then you can trivially change the tempo during playback by changing the length of 1/16th note from being 7/60s (a delay of 7 calls to the music-driver), to 5/60s or 8/60s.

The System Card Player can also store tune data in this way, and it calls it the "Time Base" length mode.

This is how most games work that change the tempo during playback.

This is also effectively how most trackers work, if they allow the musician to set the delay-time for each row/line in the pattern.

If you consider each row/line as the time of 1/32nd note, then you can get all of those 4, 5, 6, 7, etc 1/60s timings just by changing the delay times of even and odd rows/lines.

Deflemask does this, for example, when you to set the "Speed" to 4 & 3 ticks for the even/odd rows, resulting in 4+3=7 1/60s ticks per 1/16th note ... for 112.5 BPM (close-enough to a nominal 120 BPM).

One issue with using the System Card Player in this way is that it only stores notes in multiples of 1/16th note, which means that it cannot play 1/32nd notes without resorting to doubling the tempo and calling the driver twice-as-often (i.e. 120 times-per-second).

That's a limitation of the System Card Player's encoding of the tune data ... trackers don't have the same issue.


The System Card Player supports one one final way of storing the tune data, and that is to store the note length in terms of multiples of 1/64th of a note, then multiplied by 3. It calls this the "Tempo Method" length data. For this to work, the System Card Player *must* be called from a timer interrupt where the driver changes the length of the timer depending upon what BPM tempo you want to play back the music at.

The downside of this is that the more times you call the music-driver per second, the more CPU-time you're throwing away.


Hopefully that's all reasonably clear. 

[elmer]

So if the BPM is based on down count of 3 (1/60 ticks), when that expires refill the downcount to 3-1, then on expire back to 3 - and repeat. You'd think this would get you 'warbly' sounds, but it doesn't. It gets you a BPM that's in between a 3 tick and a 2 tick. In MOD or XM files, you can set the tick on every pattern line, and a pattern line is read once the tick down count reaches 0. So it's not uncommon to see something like tick defines as 3,2,3,2,3,2,3,2 going all the way down the pattern - etc. Of course, you could do this on the player side too.

OK, that makes sense, for a while I thought that you were talking about changing the timing every "frame" (i.e. 1/60s or 1/30s)!

Changing it on pattern rows/lines make sense.

As I showed above, that 3 & 2 alternation is there to give 5/60s per 1/16th note -> 180.0 BPM.

Also, I recall now (and OldMan reminded me), that Squirrel with vsync doesn't support tempo changing because it was a PITA, and the timer mode was not. 

vsync has a fixed tempo, so you must set note durations accordingly.   It kind of sucks, and I forgot about it until all of this came up.

Nope, with the System Card Player, vsync does support changing the tempo. You've just got to encode the note length data in the "Time Base" length mode.

Doing so comes with the limitation that you can't specify 1/32nd notes, but that wasn't seen as a show-stopper problem by the programmer that wrote the driver, or by Hudson apparently.

Now, if your Squirrel compiler doesn't support that mode, then that's your choice.

60 Hz is always going to be 125 BPM in a tracker, so I would avoid creating modules in other tempos.

As bonknuts said, and my calculations above show ... at 60Hz, it's 128.6 or 112.5 BPM, and not 125.

It's only a fixed tempo if your tracker doesn't let you change the timing for the rows/lines.

If that's the case, then I can only suggest that you use a better tracker.

[Bonknuts]

And at 6991 timer irqs / sec, do we even have enough time to handle this? And run a game? At 60 fps?

To play a sample via writing to a single DDA channel, at 6991 calls per second, takes 11% cpu resource. It's 5% if no sample is playing (just down counting).

11% is not a lot when it comes to assembly. It's not exactly free, but unless you're really close to the edge in HuC, it shouldn't break the bank. So 5% no sample playing, 11% while sample playing.


Here's what the code could look like:

Code: [Select]




TIMER
      stz $1403                           ;5
      BBS0 <in_progres, TIMER_BUSY        ;6
      inc <in_progress                    ;6
      cli
      pha                                 ;3
      BBR0 <DDA_state, TIMER_RETURN       ;8                   
      jmp PlaySample                      ; -2, +4
                                          ;30cycles
TIMER_RETURN

      dec <counter                        ;6
      beq TIMER_RTN                       ;4
                                          ;10cycles     
     
      lda counter_refill                  ; -2,+5
      sta <counter                        ;4

        ;PHP                                ;3
        ;lda PSG_PLAYER                     ;5
        ;pha                                ;3
        ;lda PSG_PLAYER+1                   ;5
        ;pha                                ;3
         
      jsr PSG_PLAYER                      ;7         


TIMER_RTN
      pla                                 ;4
     
TIMER_BUSY
      stz <in_progress                    ;4
  rti                                     ;7
                                          ;14cycles                                         

PlaySample
      tma #$04                            ;4
      pha                                 ;3
      lda <sample_bank                    ;4
      tam #$04                            ;5
      stz $800                            ;5
      lda [sample]                        ;7
      bmi .EOF                            ;2
      sta $806                            ;5
      inc <sample                         ;6
      bcs .msb                            ;2
.out
      pla                                 ;4
      tam #$04                            ;5
      jmp TIMER_RETURN                    ;4
 
                                          ;56 cycles
     
.EOF
      stz <DDA_state
      bra .out

.msb
      lda <sample+1
      inc a
      and #$1f
      ora #$80
      sta <sample+1
      bcc .out
      inc <sample_bank
      bra .out   


Those are the things I don't understand about how this would work. (And keep in mind, irq problems are a real thing, as rovers problem shows)

His issue sounds like an edge case scenario. That he needs to move his scroll() handling routines sooner up the chain so handle such delays. If you know what scanline number scroll() routine sorts the data and builds the RCR calls, you can work around this. If it's not doing it on the first active scanline, or a few scanlines right before first displayable line, I would change it so that scroll sort routine does this at this point in time.

That's why I said anchor the TIMER unit with a resync on V-int, and use the timer intervals to make something fixed like 120hz or 240hz system. When you can predict where code is going to happen every time, it's easier to deal with. But would require making some serious modification to the PSG player code or make a new engine. But meh - enough with the broken record of the opposition

However, with the timer, we can use the following trick: Write the 32nd notes as 16th notes. Double all the other
note times. And run the song at double the tempo. Sounds exactly the same.

That's an old MOD/tracker trick!

PS: I like the wall of text


 EDIT: Forgot the CLI in the code ;>_>