PCE PCM

[elmer]

Hahah my new favorite term

For channel volume, it's 1.5 dB drop per integer. For pan, it's 3.0 dB drop per integer. For main channel volume, 0 is -infinity but that's not true for pan! 0 for pan is not true silence.

 Here's a chart I made for Amiga/XM linear to PCE: http://www.pcedev.net/blog/files/XM_volume_tables.txt

Thanks! 

[touko]

Your English is far better than my French! 

Easy, but thanks 

[TurboXray]

Just looking through your code touko:

stz   $804               ; // Son à 0 sur la voix 1 
^- I wouldn't do this. If you're trying to silence the channel in DDA mode, simply don't write anything to it (also, writing the same sample value over and over in a row also have the same effect as silence). Otherwise this is going to give you a pop/click on the DAC at the end of a sample, on non SGX systems. It might not be noticeable in loud samples (that have a large amplitude pattern at the end), but ones that end with a built in fade (ending with a soft part) will make this pop/click more noticeable.

EDIT
Ok, I understand your compression scheme now. I hadn't seen that one before. It's pretty decent. A nice trade off between size and speed.

[TurboXray]

Ok. So I mapped out your routine, hopefully with no errors, and I came up with this:

Reload takes 168 cycles -> first sample
Second sample takes 86 cycles
Third sample takes 102 cycles

There is ~116 calls per frame. And there are three phases to each sample: the lengths shown above. Each phase is a complete path from interrupt call, to output sample, to exit routine.
                                    
38.667 = 1/3rd. So 6,496 + 3,325 + 3,944 = 13,765 cycles.
or 11.5% cpu resource. That's not bad.

 There's a different compression scheme that's a little tighter: it's 5 bytes long. First byte is the MSbit of all 5bit samples. Next 4bytes are pairs of 4bit samples.

 Your scheme does 3 samples per every 2 bytes - with a 1 bit throw away, which is a division of 1.5. So 7000 samples, or 1 second, is 4,666bytes in length. The above compression scheme is 8 samples for 5bytes, which is a division of 1.6. So 7,000 samples or 1 second is 4,375bytes. Saves about 291bytes a second over the 3/2 method.

 Is it faster or slower? I rewrote your decompression routine from scratch, using the same idea but just that I did a buffer of six samples instead of 3, and the total resource was 9.4%. Not really much lower than yours. So, just to be clear - I didn't use any long double buffer system. Just buffered 6 samples instead of 3, every 6th call.

 For the alt compression scheme, 8 samples to 5 bytes, I did a sample buffer of 8 samples. So every 8th call in the TIMER would have to refill it. That ended up being 9.6% cpu resource. So 0.2% slower, but a slightly better compression ratio.


 If I have time, I'll see how a double buffer system stacks up to those numbers.

[elmer]

Ok. So I mapped out your routine, hopefully with no errors, and I came up with this:

Reload takes 168 cycles -> first sample
Second sample takes 86 cycles
Third sample takes 102 cycles

There is ~116 calls per frame. And there are three phases to each sample: the lengths shown above. Each phase is a complete path from interrupt call, to output sample, to exit routine.
                                    
38.667 = 1/3rd. So 6,496 + 3,325 + 3,944 = 13,765 cycles.
or 11.5% cpu resource. That's not bad.

OK, I've had time to look at the problem now.

First, it's just my personal opinion, but while the 8x1+8x4 (5 byte) scheme that bonknuts mentioned is very clever, it's not worth the tiny 1/16 space-savings, and the complication that it adds, particularly when dealing with the end-of-sample condition.

From there, it's back to Touko's code ...

Mapping stuff into TAM #4 isn't needed, because Touko is already relying on his sample data being aligned on an even boundary, so I removed it, and got rid of the X and Y registers which were wasting cycles.

Then I rearranged the data format a bit to pack the current-state flags into the sample cache for a bit more speed, and used an end-of-sample marker in bit 15 of the sample word, which could also be used for sample-looping ...

... and the result is a 30% speed improvement where the banking takes an insignificant amount of the overall time.

; Three 5-bit Samples in 2-bytes (packet located on an even address boundary)
;
; 2-Byte Packed Data Format Packet + 0  : E332 2222 (sample 3 hi-bits)
; 2-Byte Packed Data Format Packet + 1  : 3331 1111 (sample 3 lo-bits)
;
; E = 1 if end-of-sample.
;
; Timing for sample 1 (122 cycles) if page-overflow
; Timing for sample 1 (110 cycles) if normal
; Timing for sample 2 ( 67 cycles)
; Timing for sample 3 ( 73 cycles)
;
; Time (normal 1 channel): 122 *   1 calls +
;                          110 *  38 calls +
;                           67 *  39 calls +
;                           73 *  39 calls = 9762 cycles (8.2%)

Here's the code, but be warned ... it takes some concentration to follow the data flow and see that it should work ...

Code Select Expand

; ****************************************************************************
; ****************************************************************************
;
; Three 5-bit Samples in 2-bytes (packet located on an even address boundary)
;
; 2-Byte Packed Data Format Packet + 0  : E332 2222 (sample 3 hi-bits)
; 2-Byte Packed Data Format Packet + 1  : 3331 1111 (sample 3 lo-bits)
;
; E = 1 if end-of-sample.
;
; Timing for sample 1 (122 cycles) if page-overflow
; Timing for sample 1 (110 cycles) if normal
; Timing for sample 2 ( 67 cycles)
; Timing for sample 3 ( 73 cycles)
;
; Time (normal 1 channel): 122 *   1 calls +
;                          110 *  38 calls +
;                           67 *  39 calls +
;                           73 *  39 calls = 9762 cycles (8.2%)
;
; Maximum hsync delay:     122 cycles
;

User_Timer_Irq:                                 ; 8
        stz     $1403                           ; 5 RAZ TIMER
        pha                                     ; 3

        lda     #VOIX_DDA1                      ; 2 Choix de la voix DDA 1
        sta     $800                            ; 5

;       stz     $804                            ; - Son à 0 sur la voix 1

        lda     <cache_memory_voix1 + 0         ; 4 Bit 7 is set if we need to
        bpl     .byte2                          ; 2 refill the cache.

.byte1: tma3                                    ; 4
        pha                                     ; 3

        lda     <sample_bank_voix1              ; 4
        tam3                                    ; 5

        lda     [ sample_base_voix1 ]           ; 7 Read byte 0 of packed data.
        sta     <cache_memory_voix1 + 0         ; 4
        bmi     .end                            ; 2 Test "E" bit for end-of-sample.

        inc     <sample_base_voix1              ; 6
        lda     [ sample_base_voix1 ]           ; 7 Read byte 1 of packed data.
        sta     $806                            ; 5 Write sample #1.
        lsr     a                               ; 2 Clr bit 7 of byte 1, A=%0333xxxx.
        sta     <cache_memory_voix1 + 1         ; 4

        inc     <sample_base_voix1              ; 6 Deal with overflow to next page.
        beq     .page                           ; 2

.end:   pla                                     ; 4
        tam3                                    ; 5
        pla                                     ; 4
        rti                                     ; 7

.byte2: lda     <cache_memory_voix1 + 1         ; 4 Test bit 7 of byte 1.
        bmi     .byte3                          ; 2

        lsr     a                               ; 2
        sec                                     ; 2
        ror     a                               ; 2
        sta     <cache_memory_voix1 + 1         ; 4 Set bit 7 of byte 1, A=%100333xx.

        lda     <cache_memory_voix1 + 0         ; 4 Write sample #2.
        sta     $806                            ; 5

        pla                                     ; 4
        rti                                     ; 7

.byte3: lda     <cache_memory_voix1 + 0         ; 4 A=%033xxxxx
        and     #$60                            ; 2 A=%03300000
        ora     <cache_memory_voix1 + 1         ; 4 A=%133333xx
        sta     <cache_memory_voix1 + 0         ; 4 Set bit 7 to reload data next time.
        lsr     a                               ; 2
        lsr     a                               ; 2
        sta     $806                            ; 5

        pla                                     ; 4
        rti                                     ; 7

.page:  inc     <sample_base_voix1 + 1          ; 6 Deal with bank overflow.
        bpl     .end                            ; 4

.bank:  inc     <sample_bank_voix1              ; 6
        lda     #$60                            ; 2
        sta     <sample_base_voix1 + 1          ; 4

        pla                                     ; 4
        tam3                                    ; 5
        pla                                     ; 4
        rti                                     ; 7


[touko]

I wouldn't do this. If you're trying to silence the channel in DDA mode, simply don't write anything to it (also, writing the same sample value over and over in a row also have the same effect as silence). Otherwise this is going to give you a pop/click on the DAC at the end of a sample, on non SGX systems. It might not be noticeable in loud samples (that have a large amplitude pattern at the end), but ones that end with a built in fade (ending with a soft part) will make this pop/click more noticeable.

Yes i know, but i have not tested on a real PCE, only SGX,and i hesitate with muting balance (i don't know if pop is present with balance )

Ok, I understand your compression scheme now. I hadn't seen that one before. It's pretty decent. A nice trade off between size and speed.

Oh, I thought it was obvious to do like that .. 
It's organised like that

Classic bytes organisation,you loose 3 bits/sample
AAAAA000  ; sample 1 => byte 1
BBBBB000  ; sample 2 => byte 2
CCCCC000 ; sample 3 => byte 3

you loose 1 bit for 3 samples
AAAAACCC ; byte 1
BBBBBCC0; byte 2

sampe A & B are send without any treatment,only sample C is shifted to a correct 5 bits sample .
It's fast (30 cycles) with a compression of 33%.

Mapping stuff into TAM #4 isn't needed, because Touko is already relying on his sample data being aligned on an even boundary, so I removed it, and got rid of the X and Y registers which were wasting cycles.

Hum i see the trick, but it's more complicated to see if you have reached the end of your sample .

I didn't use any long double buffer system. Just buffered 6 samples instead of 3, every 6th call.

Of course,long buffer is not my goal too and out of question, a 6 bytes can be descent, but no more .

Then I rearranged the data format a bit to pack the current-state flags into the sample cache for a bit more speed, and used an end-of-sample marker in bit 15 of the sample word, which could also be used for sample-looping ...

Clever ,and your bank overflow deal is clever too ..

Timing for sample 1 (122 cycles) if page-overflow
; Timing for sample 1 (110 cycles) if normal
; Timing for sample 2 ( 67 cycles)
; Timing for sample 3 ( 73 cycles)

The bonknut's results and yours show that i said
A little buffer decrease the need of mapping and by the way the average of CPU cycles ..

; Time (normal 1 channel): 122 *   1 calls +
;                          110 *  38 calls +
;                           67 *  39 calls +
;                           73 *  39 calls = 9762 cycles (8.2%)

8.2% is really good, and there are some good ideas here to improve sample playing.

EDIT: I modified my PCM routine a little bit, now the sample finish with the bit 7 of the second byte (if 1), the mapping is now only on MPR3, and remap if a page overflow occur .
Thanks elmer, it's mush faster now ;-)

User_Timer_Irq:   
      stz    $1403                  ; // RAZ TIMER      
      pha                  
      
   ; // Evite de désactiver la voix si pas de sample
      bbs      #7 , <test_octet_voix1 , .fin_sample_voix1      
      
      lda      #VOIX_DDA1            ; // Choix de la voix DDA 1
      sta      $800          
      
      bbs      #0 , <test_octet_voix1 , .prep_octets_voix1      
      
   ; // On Met en cache 3 samples(2 octets) pour la voix 1 et on lit le premier sample
     .fin_comp1:
      tma     #3
      pha
                    
      lda     <sample_bank_voix1             
      tam     #3
            
      lda     [ sample_base_voix1 ] 
      sta      <cache_memory_voix1   
      
      sta      $806            ; // On joue le sample 1 voix 1
      
      inc      <sample_base_voix1   
      lda      [ sample_base_voix1 ]
      bmi      .voix_1_off      ; // Si bit 7 = 1 alors fin sample on sort
      
      sta      <cache_memory_voix1 + 1   
   ; // On restaure l'ancienne bank
      pla
      tam    #3
                
      lda      #3
      sta    <test_octet_voix1
                  
      inc      <sample_base_voix1      
      bne      .fin_sample_voix1
      inc      <sample_base_voix1 + 1
      bpl      .fin_sample_voix1
      
      lda      #$60
      sta      <sample_base_voix1 + 1
      inc      <sample_bank_voix1   
      
      bra      .fin_sample_voix1
      
     .voix_1_off:
   ; // On restaure l'ancienne bank
      pla
      tam    #3      
      
      stz      $804               ; // Son à 0 sur la voix 1                     
      smb      #7 , <test_octet_voix1  ; // On déactive la lecture des sample pour la voix 1
      
      bra      .fin_sample_voix1
      
   ; // On lit le second sample
     .prep_octets_voix1:      
      lda      <cache_memory_voix1 + 1
   
   ; // On decale le compteur de sample pour la voix 1
      lsr      <test_octet_voix1
   ; // Si second sample lu, on décompresse le sample 3      
      bne      .transfert_data_sample_voix1
      and    #$60      
      lsr    A
      lsr    A      
      sta      <cache_memory_voix1 + 1
      lda    <cache_memory_voix1   
      lsr    A
      lsr    A
      lsr    A
      lsr    A
      lsr    A
      ora      <cache_memory_voix1 + 1   
   
     .transfert_data_sample_voix1:      
      sta       $806                                    
         
     .fin_sample_voix1:    
              pla
              rti

[TurboXray]

OK, I've had time to look at the problem now.

First, it's just my personal opinion, but while the 8x1+8x4 (5 byte) scheme that bonknuts mentioned is very clever, it's not worth the tiny 1/16 space-savings, and the complication that it adds, particularly when dealing with the end-of-sample condition.

I found a few hucards games doing it, but specifically Street Fighter 2 (does it for two sample channels). It's faster than normal bitpacked sample that other PCE games tend to use. I've never seen the scheme touko used.

 End of sample is convenient if you have the free bit for it, but it's not necessary. But that is awesome that you fitted it in there. I still like the padded end of sample block method (whatever that block is - 116 samples is the block in this case), where you check in vsync int.

 I honestly thought the SF2 method would be faster. It looks simpler IMO (less steps/shifts).

Mapping stuff into TAM #4 isn't needed, because Touko is already relying on his sample data being aligned on an even boundary, so I removed it, and got rid of the X and Y registers which were wasting cycles.

I didn't catch that he was doing that. I shaved the 6 sample buffer method down to 8.9%, but buffer difference isn't big enough for the overhead (have a pointer of playback buffer) to over come the non pointer method you did with a 3 sample cache system.

Here's the code, but be warned ... it takes some concentration to follow the data flow and see that it should work ...

A block comment in assembly! I never seen anyone do that - haha. Your code is clean, clear, and and easy to understand. And fast. I'm impressed

[TurboXray]

Touko: Do you need compression? Or are you just using compression on the samples because it's a waste not to? In other words, you expressed interest in the soft mix player I made - the only with 4 channels on two PCE channels. That wouldn't use any compression, because the sample depth is higher than 5bit. Would that mean you're not interested in it?

[elmer]

Thanks elmer, it's mush faster now ;-)

I'm glad to have helped! 

I calculated the timings for your code vs mine and it comes out as ...

; Timing for sample 1 (130 cycles) if page-overflow
; Timing for sample 1 (122 cycles) if normal
; Timing for sample 2 ( 67 cycles)
; Timing for sample 3 ( 93 cycles)
;
; Timing for finished ( 35 cycles)
;
; Time (normal 1 channel): 130 *   1 calls +
;                          122 *  38 calls +
;                           67 *  39 calls +
;                           93 *  39 calls = 11006 cycles (9.2%)

So you're 1244 cycles-per-frame slower than me, but your code is a bit clearer to follow.

Hum i see the trick, but it's more complicated to see if you have reached the end of your sample .

My point was that you don't need to waste 6 cycles by doing a test for sample-still-playing at the start of every one of the 116/117 interrupts ... it wastes 696/702 cycles-per-frame during normal playback.

It's easy to change my code to set a flag that your main loop can test ...

        ...
        lda     [ sample_base_voix1 ]           ; 7 Read byte 0 of packed data.
        sta     <cache_memory_voix1 + 0         ; 4
        bmi     .finish                         ; 2 Test "E" bit for end-of-sample.
        ...


.finish:stz     <sample_playing                 ; 4

        pla                                     ; 4
        tam3                                    ; 5
        pla                                     ; 4
        rti                                     ; 7


While it looks like my code wastes a lot of time re-reading the end-of-sample marker ... the point is that it doesn't matter in practice!

It takes no more time to do that than it does to actually play the sample ... which you already have to allow for in your game design.

The important thing to do, however you play back the sample, is to disable the timer interrupt entirely if you're not playing back any samples at all.

Of course,long buffer is not my goal too and out of question, a 6 bytes can be descent, but no more .

It would save you a few more cycles in the banking, but you may lose a lot of the time-savings in the extra code/branches to figure out which sample to output.

[TurboXray]

It takes no more time to do that than it does to actually play the sample ... which you already have to allow for in your game design.

^This. Worst case is what matters. Specifically when the occurrence is kinda random (you'd don't know when you're going to play a sample), so any resource in between 0 and expected ceiling - doesn't matter much IMO. Only the ceiling.

[elmer]

I found a few hucards games doing it, but specifically Street Fighter 2 (does it for two sample channels). It's faster than normal bitpacked sample that other PCE games tend to use. I've never seen the scheme touko used.

 End of sample is convenient if you have the free bit for it, but it's not necessary. But that is awesome that you fitted it in there. I still like the padded end of sample block method (whatever that block is - 116 samples is the block in this case), where you check in vsync int.

 I honestly thought the SF2 method would be faster. It looks simpler IMO (less steps/shifts).

Does SF2 do the unpacking during the TIRQ, of does it buffer up an entire 116-byte frame? 

One of the things that I liked about the 3-in-2-bytes scheme was that it avoided the need to check for bank-overflow in the middle of a packet. With 8-samples-in-5-bytes, I don't think that you can do that.

That's not a problem if you're mapping in 2 banks to build the 116-byte buffer during vblank, but it's expensive to do in a TIRQ.

Plus ... I kinda like having that bit in there to mark the end-of-sample, or to signal a loop-point. 

Your double-buffered scheme is something that I'll need to look at seriously and compare the timings.

Mapping stuff into TAM #4 isn't needed, because Touko is already relying on his sample data being aligned on an even boundary, so I removed it, and got rid of the X and Y registers which were wasting cycles.

I didn't catch that he was doing that. I shaved the 6 sample buffer method down to 8.9%, but buffer difference isn't big enough for the overhead (have a pointer of playback buffer) to over come the non pointer method you did with a 3 sample cache system.

Ahhh ... I missed that you'd already tried the 6-sample-at-once method.

Yep, I was afraid that the overhead from keeping track of which sample you're playing would outweigh the savings in the bank switching.

A block comment in assembly! I never seen anyone do that - haha. Your code is clean, clear, and and easy to understand. And fast. I'm impressed

Thanks, that means something, coming from you! 

And Touko was right ... the overhead of the banking for every sample in the simple playback code that I posted earlier really *was* significant.

I'm very surprised to see it, but the packed playback code is actually a tiny bit faster than simple playback code.

Now I'm not sure if that will extend to multi-channel playback, but the idea of getting a 30% space-savings on sample size for no CPU playback cost is pretty amazing!

In other words, you expressed interest in the soft mix player I made - the only with 4 channels on two PCE channels. That wouldn't use any compression, because the sample depth is higher than 5bit. Would that mean you're not interested in it?

Well, *I'm* certainly interested in seeing the code. 

Having a high-quality sample alternative for use on Title Screens and places like that would be nice.

It all depends upon the CPU and memory costs.

The only thing that I don't overly like it losing stereo panning.

Having a drum-roll pan across the stereo field, or having a effect come from the left or right, are both common occurrences in games.

[Arkhan Asylum]

You could also just limit it to three channels or so, and let the user pick based off their own needs, really.

Id likely only need one channel for drum samples, leaving another noise channel open for crunchy sfx.   i cant imagine needing to tie both noise channels up.  Three channels of sampled percussion seems excessive, since even Amiga tunes dont really do that. 

it would be easy to throw errors at compile time if there is a non possible configuration.

The reason we suggest five and six is that they already support mode switching. 

I wouldnt use channel one, because its the only channel that supports lfo, as useless as some say it is.

Again, this is why maybe supporting three, and letting users pick is best.

Personally, the way  i set tunes up, i like putting rhythm at the bottom, or far right, depending on if were talking mml, piano rolls, or trackers.

Sticking drums in the middle of a piano roll setup or a tracker tune column thing bugs me personally, lol

[Arkhan Asylum]

A block comment in assembly! I never seen anyone do that - haha. Your code is clean, clear, and and easy to understand. And fast. I'm impressed

Really? ....  block comments are... pretty normal lol.  Im surprised youve not seen them in asm code before...

 Theyre all over Atlantean, Inferno, and Squirrel stuff!

I guess that might be the difference between professional backgrounds, and tinkering backgrounds.

They used Apple 2 assembly on screen for Terminator, lol.   You can see like floppy drive code. 

[Windcharger]

Windcharger: Maybe I should make page 3 of the PCE Cribsheets; audio stuffs. Sometimes it's a lot to keep track of, especially if you're not always working with the hardware directly.

Yep, that would be useful.

Sorry for late response.  Holidays in full swing.   

[touko]

Touko: Do you need compression?

Not really!

Or are you just using compression on the samples because it's a waste not to?

Yes, i think 33% lesser with only 30 cycles is not negligible 
Of course, without compression, the code is faster and well suited IMO for SCD-rom .

Would that mean you're not interested in it?

for now i have only hucard project, this why space is important, but i'll try with no compression to see how fast it is vs compression.

but your code is a bit clearer to follow.

Yes 

My point was that you don't need to waste 6 cycles by doing a test for sample-still-playing at the start of every one of the 116/117 interrupts ... it wastes 696/702 cycles-per-frame during normal playback.

It's a first try, i'll see now with a better code organisation if i can do it better .
May be without compression .

[elmer]

You could also just limit it to three channels or so, and let the user pick based off their own needs, really.

Id likely only need one channel for drum samples, leaving another noise channel open for crunchy sfx.   i cant imagine needing to tie both noise channels up.  Three channels of sampled percussion seems excessive, since even Amiga tunes dont really do that.

Yeah, I can't really see the practical *need* for more than 3 channels of samples, and honestly, 2 would probably be enough.

What you're saying is why I was suggesting putting the samples on channels 4 & 5, and leaving channel 6 open for regular PSG-drums or PSG-sfx.

The question is mainly one of "freedom", and programmers don't like it ... flexibility costs CPU cycles.

The sound driver itself doesn't care, and I suppose that it would be possible to provide a couple of different interrupt handlers for different channel selections.

Really? ....  block comments are... pretty normal lol.  Im surprised youve not seen them in asm code before...

Theyre all over Atlantean, Inferno, and Squirrel stuff!

Yep, I'm originally used to them from things like the FigForth source code and the Atari 400/800 ROM listings.

I don't always put them in my own code when I'm just hacking something up, but it's important (IMHO) to document utility code and functions that might be used by someone else, or that you expect to use for a long time (because you'll forget how it works and why you made certain choices).

So, for these "public" displays of code, which is something that I'd like to see more of here, I believe that it's good to take a bit of extra time.

for now i have only hucard project, this why space is important, but i'll try with no compression to see how fast it is vs compression.

...

It's a first try, i'll see now with a better code organisation if i can do it better .
May be without compression.

I look forward to seeing your results! 

If you drop that initial test, and optimize the flow for the most-common case, then I suspect that you'll get to very-close-to or faster-than my example.

[Arkhan Asylum]

I always put block comments.  They make me hard.


Id see about just letting users define which channels.   Im not sure how youll be writing it, but you should be able to make it a bit dynamic and error out if someone sets up 4+ sample channels.

[touko]

Error .., i solved my sound problem 

[touko]

The clicking, if you play the second example, is just me not initializing the driver before sending anything to it (I just haven't got around to it).

How really avoiding the clicking ??

[Michirin9801]

Umm, sorry for butting in the conversation of experts, a lot of what you've said went way over my head but let me see how much I understand:
You're taking 2 of the PCE's hardware channels, which are 5 bit, and putting them together to get a single 10 bit PCM, right?
And then you're soft-mixing 4 8 bit samples into that single 10 bit channel...
But apparently, the PCE can't natively do different pitches for the same sample, right?
But those examples you've shown have the PCE doing different sampled notes...
First question: Are those different notes all different samples or are they pitch-shifted notes? And if the latter is the case, how much freedom do you have for pitch-shifting?

When I fire up one of your example ROMs I see the names "XM file" and "MilkyTracker" so apparently I could use OpenMPT to make music for this sound driver, I mean, OpenMPT is XM compatible, in fact, that's the format I use by default because that's the format I can export SNES samples to...
Second question: Do you have any idea of when and how will I be able to make music for this sound driver and take advantage of all 8 sound channels? I mean, just the thought of having 8 channels on the PCE already fills me with ideas!
I know I'll have my sample-usage limited because of the low memory and all, but Batman did sampled bass, orch-hits and drums on a HuCard, and I'd want to have at least those things sampled, the rest of the instruments can be (and would probably be better off as) regular wavetables, but having a deeper and more dynamic bass sampled from FM playing alongside 2 channels of good'ol sampled drums to make more interesting drums, and still have 4 channels worth of wavetables to compose my melody and harmony and one more PCM for sound effects on top of that would be very welcome!

[TurboXray]

The rom link that shows XM and milkytracker; that's playing modified XM files. In those files, you have full note range from octave 0 to octave 6, and fine-stepping of 32 units in between each note (XM files only do 16 IIRC). The fine-steps are linear, not period base, so they are the same "weight" regardless of the octave (the opposite case is something that always bothered me with period based systems; nes, pce (native), amiga, etc).

 So yeah. It's doing frequency scaling in software, and not a set of prescaled notes. Think SNES, but nearest neighbor instead of filtered. And at 7kz (or 14khz, or 16khz.. depending on the driver). The demo roms that show "xm", are not 8bit samples mixed in 10bit mode. They are just normal 5bit samples. I haven't made a public mixture for the 10bit mode one that does realtime frequency scaling. heh - I worked on this stuff at my leisure because I know the probably of people using the PCM driver, in support of their own music engine or homebrew stuff.. is about null. 

 The "driver" just gives a programmer an interface/capability to a pseudo hardware function. It's not the music engine itself. The example roms with music, is just a quick hack job to play XM files (it only supports a few FX) - to demo the driver.

 What you were trying to do with wave-form phasing, you could just do normally like in an XM file, on the PCE with this driver. But like I stated earlier in the thread; there are different flavors and versions of the driver. The fastest version is the 5bit version @7khz. The 5bit @ 14khz didn't really improve much at all over the 7khz version. So I'm working on setting up a 8bit @ 7khz version (4 channels mixed into 10bit output.. but all those channels will be mono).

[Michirin9801]

The rom link that shows XM and milkytracker; that's playing modified XM files. In those files, you have full note range from octave 0 to octave 6, and fine-stepping of 32 units in between each note (XM files only do 16 IIRC). The fine-steps are linear, not period base, so they are the same "weight" regardless of the octave (the opposite case is something that always bothered me with period based systems; nes, pce (native), amiga, etc).

 So yeah. It's doing frequency scaling in software, and not a set of prescaled notes. Think SNES, but nearest neighbor instead of filtered. And at 7kz (or 14khz, or 16khz.. depending on the driver). The demo roms that show "xm", are not 8bit samples mixed in 10bit mode. They are just normal 5bit samples. I haven't made a public mixture for the 10bit mode one that does realtime frequency scaling. heh - I worked on this stuff at my leisure because I know the probably of people using the PCM driver, in support of their own music engine or homebrew stuff.. is about null. 

 The "driver" just gives a programmer an interface/capability to a pseudo hardware function. It's not the music engine itself. The example roms with music, is just a quick hack job to play XM files (it only supports a few FX) - to demo the driver.

 What you were trying to do with wave-form phasing, you could just do normally like in an XM file, on the PCE with this driver. But like I stated earlier in the thread; there are different flavors and versions of the driver. The fastest version is the 5bit version @7khz. The 5bit @ 14khz didn't really improve much at all over the 7khz version. So I'm working on setting up a 8bit @ 7khz version (4 channels mixed into 10bit output.. but all those channels will be mono).

Oh I see... Being 5 bit explains why the samples sound so delightfully scratchy, kinda like they came from the GBA or something, (which is something I've been wanting actually)
And honestly, I'd rather have Mono than the Amiga-style hard-panning... (Btw, was that a limitation or was it intentional?)

To be honest, if I were to make a soundtrack for a real PCE game I wouldn't really use any samples... Well actually, I'd have 2 versions of the soundtrack, one for the regular PCE/TG16 units without the CD add-on, with just the 6 regular channels and wave + noise percussion, and the other for the units with the CD add-on, which would play sampled drums on the ADPCM channel of the CD unit (on a HuCard game btw) and free up an extra channel to play something like another chord note or a delay/reverb effect...
I'd want the music to take as little CPU time as possible so that more of it would be available to cram as much parallax scrolling on the backgrounds as humanly possible! ;3

But still, I'd love to use this driver when it's 'ready' to see just how much I can get out of the PC engine's sound, heck, I'd totally port over some GBA songs to the system using the PCM channels to emulate the GBA's direct audio and the remaining wavetable channels to emulate the Game Boy soundchip! Or something like that... If anything, this driver could be used to make a really awesome demo kinda like the ones people do for the C64 and stuff!

[TurboXray]

Oh I see... Being 5 bit explains why the samples sound so delightfully scratchy, kinda like they came from the GBA or something, (which is something I've been wanting actually)
And honestly, I'd rather have Mono than the Amiga-style hard-panning... (Btw, was that a limitation or was it intentional?)

Honestly, it was kind of an experiment to see what kind of samples sounded fine in 5bit. Some sound great, and some not so great. The hard panning was just from the songs I pulled; 5bit sample mode has full stereo space as normal PCE channels. There's a trick that can clean up some "lead" style samples in 5bit mode though - pairing the sample with a normal PCE channel helps mask the lower resolution artifacts. The human ear can't hear "noise" artifacts in loud sounds like it can in lower amplitude waveforms (one of the reasons why old telephone systems would use non linear compression for audio over lines; analog versions a-law and u-law). Blazing Lazers samples for voices on power ups sound horrible by themselves (4bit audio), but in game while the music is playing - they sound more clear. Loudness is key.

I'd want the music to take as little CPU time as possible so that more of it would be available to cram as much parallax scrolling on the backgrounds as humanly possible! ;3

Who's doing the programming? Parallax tricks, in assembly, aren't very cpu resource hungry if done right. I could see maybe if you're going to extreme ends for parallax (wasting 50% cpu or more for insane stuffs), but I doubt it'd have much impact on a typical PCE game, in assembly, with samples. The HuPCM driver is customizable: if you only need 1 or 2 channels with "frequency scaling" (aka sample-based synth), then the rest as fixed frequency (1 or 2) won't eat up as much as doing all 4 using software sample-based synth. Stuff like that.

 I just want an expansion of the PCE sound. I don't want to necessarily replace the PCE sound, but something that works with it. 8bit mixing allows some bass to the PCE (thump/bump), and software samplebased synth gives it much more range with bass style instruments - as well as others (imagine using that orch hit in batman, but at any note/octave).

 To give an idea on the 5bit sample-based synth one:

The original one, if you played all 4 XM channels AND 2 regular sample channels (6 total) all at the same time - it would take 35.7% cpu resource.

Air Zonk sound engine takes up 30% and that's just one sample. So 6% more, and you have all 6 channels playing samples (4 with frequency scaling!). The less channels you want to do for sample-based synth, the less cpu resource you would need.

[Michirin9801]

I'd want the music to take as little CPU time as possible so that more of it would be available to cram as much parallax scrolling on the backgrounds as humanly possible! ;3

Who's doing the programming? Parallax tricks, in assembly, aren't very cpu resource hungry if done right. I could see maybe if you're going to extreme ends for parallax (wasting 50% cpu or more for insane stuffs), but I doubt it'd have much impact on a typical PCE game, in assembly, with samples. The HuPCM driver is customizable: if you only need 1 or 2 channels with "frequency scaling" (aka sample-based synth), then the rest as fixed frequency (1 or 2) won't eat up as much as doing all 4 using software sample-based synth. Stuff like that.

Umm, nobody, It's a hypothetical situation in case I'd end up working on a PCE game >w>
Which I really want to, but first I need to finish this Mega Drive game that I've started before I got into PCE music, after that I have no further plans to work on the MD, it took a really long time to get the system sounding the way I want to, and now that I did get it sounding the way I like I can't change the songs that were already done because the programmer doesn't want them to change...
Oh well, all of my future ideas are for the PC engine, the Super Nintendo and the PC-98, but the PC-98 has pretty much no English-speaking market and even fewer dedicated devs than the PCE, so I'll probably end up making just a regular PC game that runs at 640 x 400 at 16 colours and has an OPN/OPNA soundtrack...
(Btw, I'm also the one doing the grafx and the level design...)

I just want an expansion of the PCE sound. I don't want to necessarily replace the PCE sound, but something that works with it.

So do I!
I'd never want to replace the PCE sound, I couldn't live without dem 5 bit waves~
But I welcome the idea of expansion, especially if it means that I can use sampled basses, drums and orch hits!

[Arkhan Asylum]

Paula is hard panned L/R out of stupidity, kind of like how they voluntarily picked that shit tier palette for the C64.  They chose those colors willingly.    Someone sat down and said "yes, we need two shades of olive, and 3 shades of gray.  that is what will make this fucker look great!"



Amiga music with headphones SUCKED:

What kind of MD game are you making?  That sounds interesting.

I don't even think the PC-98 really has a Japanese speaking market for anything other than music, last I checked.  I think people just realize you could do a PC game, as you've mentioned.  It's kind of like trying to make a DOS game now.  Just pretend.  It's all supposed to be compatible (ish)

There's PC 6001 stuff, and MSX, though.

I can't imagine you'd want to make PC-6001 tunes.    Maybe MSX, though.   

There's trackers on MSX

Suck on that shit, Amiga. 

lol.

[Michirin9801]

Paula is hard panned L/R out of stupidity, kind of like how they voluntarily picked that shit tier palette for the C64.  They chose those colors willingly.    Someone sat down and said "yes, we need two shades of olive, and 3 shades of gray.  that is what will make this fucker look great!"



Amiga music with headphones SUCKED:  https://youtu.be/K0FaAs4M3d0

Agreed, it just seems like Commodore had a habit of making s*** design choices for their computers, even if the computers themselves turned out good in the end... Kinda like how the Nintendo had technically 64 colours in its palette, but 10 of them are black and 2 shades of grey and white are pretty hard to distinguish from one another, and thus could have been replaced with different colours (Maybe more yellows?)

But to some people those s*** design choices are what gives the respective systems their charm, which I understand even if I don't agree... (Seriously, I hate that hard-panning on the Amiga)

What kind of MD game are you making?  That sounds interesting.

I'll talk about it when I have something more presentable to show...
I'm currently in the process of remaking all the background graphics pretty much from scratch in order to squeeze some very needed extra colour and detail out of the limited palettes on the MD...
But since I'm too lazy and get distracted too easily _{and grow more of a distaste for the MD the more I work with it} I'm doing PC engine music, playing Galaxy Fraulein Yuna and drawing fanart of Yuna on my 3DS instead of actually working on the game... Shame on me I guess...

[TailChao]

I just want an expansion of the PCE sound. I don't want to necessarily replace the PCE sound, but something that works with it. 8bit mixing allows some bass to the PCE (thump/bump), and software samplebased synth gives it much more range with bass style instruments - as well as others (imagine using that orch hit in batman, but at any note/octave).

The AUDIO_IN pin is ready whenever you are.

[elmer]

I just want an expansion of the PCE sound.

The AUDIO_IN pin is ready whenever you are.

Wow ... bonknuts is going to make a Yamaha FM add-on for the PCE, and you heard it here, first!     

<edit>

C'mon ... you can get a YMF262 OPL3 FM chip + YAC512 DAC for $1.60 on fleabay ... we could totally blow-away all of those scummy MSX and Genesis guys!   

[Michirin9801]

C'mon ... you can get a YMF262 OPL3 FM chip + YAC512 DAC for $1.60 on fleabay ... we could totally blow-away all of those scummy MSX and Genesis guys!   

Oh I think we'll already blow them away by turning the PCE into a sampler without any extra hardware ;3

[Arkhan Asylum]

You're not turning the PCE into a sampler without any extra hardware.  It already is one, and always has been, lol.   I don't imagine this will really blow away MSX users.   Genesis maybe, but probably not.

I get that Elmer's remark was a bit tongue in cheek but, really, MSX's secret weapon is the ability to combine PSG, SCC, and FM together, assuming you want to be that mental and support 3 sound chips simultaneously.   Easy with an emulator, but doing a real game requires an SCC cartridge (and SCC chips if you want to make a real cartridge), and the assumption (a fair one) that users have FM.

 

It's pretty great, and offers a kind of sound PCE can't get to.  Micro Cabin's use of FM+PSG confuses me.  Their MSX soundtracks were better than the PCE ones, even though PCE was using CD audio for alot of it.

I've not heard anyone else ever replicate what they did. 

[Michirin9801]

You're not turning the PCE into a sampler without any extra hardware.  It already is one, and always has been, lol.   I don't imagine this will really blow away MSX users.   Genesis maybe, but probably not.

Well, I think the ability to play PCM samples doesn't exactly make the system a 'sampler', when I say "Sampler" I mean something more along the lines of the Super Nintendo, with sample looping and pitch-shifting and all, which the PCE cannot do natively (as far as I'm aware at least), but Bonkonuts pulled off in software which is really amazing!
Yeah I know Batman pulled off sample looping in software too, but not pitch-shifting, much less software mixing of 4 sampler channels on 2 hardware channels, it had a different sample for each note of the bass and the orch hits...

[Arkhan Asylum]

side note: speaking technically here, a "sampler" is the thing that grabs the samples and creates them.   Like the goony thing I used to plug into my Amiga to get samples onto it.

I can't say I've heard the term applied to the actual act of sample based synthesis.

It's cool that there's a thing happening to mix/shift/loop samples, but, these sort of things just drive the sound away from sounding like a PCE (assuming you do 6 channels of random shit you sampled).

losing PCE style leads sucks even if the thing replacing it is technically more advanced/better.    That's something to always be careful of when getting excited about having something do something it doesn't typically get used for.     That's why I'd personally ever only use sampling for percussion, or orchestra hits maybe.   



lol "Bonkonuts".   another great typo.   There's also been "Bonknauts".

[CrackTiger]

I think that full sample shifting bgms should be restricted to stuff like a title screen, menu or stage select screen. It would sound best mixed with chip sounds like many arcades were doing at the time. 4 sample shifting channels with 2 chip sound channels could still sound great and authentic if done right. I think that the key is only using samples, whether pitch shifted or not, for the right kinds of instruments.

[elmer]

C'mon ... you can get a YMF262 OPL3 FM chip + YAC512 DAC for $1.60 on fleabay ... we could totally blow-away all of those scummy MSX and Genesis guys!   

Well, on 2nd look, I think that we'd actually need a YMF289B OPL3 FM chip + YAC513 DAC, in order to meet the fast memory access timings of the PCE, and those cost a little bit more ... approx $6 per pair. 

Oh I think we'll already blow them away by turning the PCE into a sampler without any extra hardware ;3

Errr ... not at that CPU-cost, you won't! 

You're just creating a CPU-pumped soft-synth rompler, in the same way that you can on any old hardware that supports a DAC output and a reasonable memory layout for the samples.

It could be done on an Amiga just as well.

Now ... as I've said, the 4-channel fixed-rate playback into a 10-bit output using 2 PSG channels ... *that* interests me. That may well be practical for in-game usage.

Either way, whatever the cost/performance tradeoff a particular developer/musician team is willing to make, it should be easy to modify Huzak so that it'll use the Deflemask data for whichever channels you wish, and let some other code handle the mixing for the other channels ... or just build the capability into Huzak itself as optional choices at build-time.

The whole point is to have the dmf2pce converter and the driver itself both be Open Source so that anyone can abuse them as much as they desire.

I get that Elmer's remark was a bit tongue in cheek but, really, MSX's secret weapon is the ability to combine PSG, SCC, and FM together, assuming you want to be that mental and support 3 sound chips simultaneously.

Yep, totally tongue-in-cheek. 

I can't see anyone being interested-enough to produce an FM HuCard, even though it would (theoretically) be a fairly easy thing to do on a DUO/SuperCDROM.

From my personal POV, the MSX's base AY-3-8910 PSG is a total piece-of-sh*t (I've used it before), and Konami's SCC is pretty-close to our PCE PSG, so the only real extra that the MSX has (if you buy the add-on) is the Yamaha 8950 9-channel, 2-operator OPL1 FM chip.

So, if we added a Yamaha 289B 18-channel, 4-operator OPL3 FM chip, then we'd totally blow-away the MSX hardware, and actually beat the Sharp X68000's 8-channel, 4-operator YM2151 (which, yes, was also available as an MSX add-on)! 

BTW ... I absolutely *love* the sound of Yamaha's 4-operator FM synths. 

[elmer]

Well, I think the ability to play PCM samples doesn't exactly make the system a 'sampler', when I say "Sampler" I mean something more along the lines of the Super Nintendo, with sample looping and pitch-shifting and all, which the PCE cannot do natively (as far as I'm aware at least), but Bonkonuts pulled off in software which is really amazing!

Well, the sample-looping part is totally trivial.

I have absolutely no idea why Deflemask doesn't support it.

It's only a few lines of extra code, and has no noticeable CPU cost.

Heck ... an attack-sustain-release sample isn't much more code, and still has negligible cost.

It's the frequency-scaling, and then mixing that adds the cost (and the need for buffering).

[Arkhan Asylum]

The way you can combine the chips on MSX is what makes it particularly nice.  You don't get the OPL4 sound, but what you get is still nice.

[Michirin9801]

Now ... as I've said, the 4-channel fixed-rate playback into a 10-bit output using 2 PSG channels ... *that* interests me. That may well be practical for in-game usage.

That's exactly what I'm talking about! Giving the PC engine 8 channels, 4 of which are soft-mixed PCM onto 2 hardware channels playing pitch-shifting samples!

It's cool that there's a thing happening to mix/shift/loop samples, but, these sort of things just drive the sound away from sounding like a PCE (assuming you do 6 channels of random shit you sampled).

losing PCE style leads sucks even if the thing replacing it is technically more advanced/better.    That's something to always be careful of when getting excited about having something do something it doesn't typically get used for.     That's why I'd personally ever only use sampling for percussion, or orchestra hits maybe.   

Which is why my idea is to use the sampler channels for a sampled bass, percussion and maybe orch hits and strings, and play the lead and harmonic support in the remaining 4 hardware channels! We could use this driver to combine a sampled MD-style FM bass with SNES style drums, strings and orch hits and the PCE style leads! BLAM! Tenouttaten Tenouttaten Best Sound Best Sound!

Either way, whatever the cost/performance tradeoff a particular developer/musician team is willing to make, it should be easy to modify Huzak so that it'll use the Deflemask data for whichever channels you wish, and let some other code handle the mixing for the other channels ... or just build the capability into Huzak itself as optional choices at build-time.

Here's a suggestion, If Huzak is gonna support Bonknuts' PCM driver that you said you're interested in, why not support both the .dmf and .xi formats? I mean, he can already play .xi files on the PC engine with what he's currently got, and assuming you'll be able to use 4 sampler channels and 4 PSG channels at once you could load the two files and put out a single .hes or .pce file with the song using all 8 channels!
As for figuring out which two channels you're gonna soft-mix, well, I suggest channels 3 and 4 so that anyone wanting to use noise mode on channels 5 and 6 would be free to do so, and anyone who would be mental enough to use the hardware LFO would also be free to do so... (I mean no offense to LFO users, but seriously, that thing is useless)

The way I see it working is to use Deflemask for the 4 PSG channels (1, 2, 5 and 6) and then OpenMPT (or whichever mod tracker you prefer) with a 4 channel .xi file... Yeah it would be complicated on the musicians, but at least they'd be able to do 'something' with this driver...

But don't worry too much about that right now, one thing at a time, you first need to get Huzak running and doing its thing right?

Well, the sample-looping part is totally trivial.

I have absolutely no idea why Deflemask doesn't support it.

It's only a few lines of extra code, and has no noticeable CPU cost.

Heck ... an attack-sustain-release sample isn't much more code, and still has negligible cost.

It's the frequency-scaling, and then mixing that adds the cost (and the need for buffering).

At this point they might as well completely rewrite the way they handle samples on the PC engine...

[Arkhan Asylum]

I'm not sure SNES style echo-percussion (TM), and a shitty sampled FM bass will really be best-sound-best-sound.. lol

I have some stuff that would probably make nice samples though. 

A Roland or Yamaha drum machine from the 80s has some pretty good percussion samples that would fit in well with PCE style music.

[elmer]

That's exactly what I'm talking about! Giving the PC engine 8 channels, 4 of which are soft-mixed PCM onto 2 hardware channels playing pitch-shifting samples!

Avoiding any pitch-shifting is precisely what I'd want to do! 

But ... once you've got a version of the driver and IRQ code that uses a sample buffer, then it's trivial (from a driver POV) to choose whether you allow pitch-shifting or not, and see exactly what the cost is.

It's the UI and getting the musician's data into the right format that's the real PITA.

But don't worry too much about that right now, one thing at a time, you first need to get Huzak running and doing its thing right?

Yes, that is a rather important first-step, before any kind of sample-playback becomes relevant, or anyone gets too excited.

[Michirin9801]

I'm not sure SNES style echo-percussion (TM), and a shitty sampled FM bass will really be best-sound-best-sound.. lol

I have some stuff that would probably make nice samples though. 

A Roland or Yamaha drum machine from the 80s has some pretty good percussion samples that would fit in well with PCE style music.

We'll see about that when we actually get to using the sound driver, but for my taste, FM makes the best basses, samples make the best drums, orch hits and strings, and the PCE PSG makes the best leads ;3

[Arkhan Asylum]

Yes, but FM synth style bass, when sampled, won't sound quite as good as it should, as we've already discussed multiple times. 

For *my* taste, I want the synth style bass to actually sound right.   Retriggering is probably going to make it sound off, to me.

[TurboXray]

Well, screw you haters haha. There's potential in the "sampler" driver. I'm just going to refer to it as that, because I'm sick of typing out sample based synth. "Samplers" is the word used to describe sample based standalone synths in the 90s. So it works for me.


 I don't get this whole "for title screens and menus" mentality. If it was that bad, I would even bother (maybe..lol). What NES did with 25% (actually closer to 20% because of the sprite metatile decoding the NES has to do for smaller sprites) is pretty damn good. SMB3 totally plays like a 16bit game. The current driver with all 6 channel eating 36% is nothing! Leaving 64% for game stuffs. Tile screen my ass ;>_> Even if it got fancy or whatever -> went up to 60% cpu resource. That still has potential way beyond "title screens". Maybe not for HuC, but assembly (and for games, not demos) - it's doable. RPGs with SNES sampler style string leads on the PCE? Not interested? I am. 

 What's with all this MSX stuff? I thought this was a PCE forum. I like MSX as much as I like Speccy - from a distance. It's great fun to watch all the achievements on the systems, but beyond that I don't care. It's a curiosity to me and nothing more.

[Michirin9801]

Yes, but FM synth style bass, when sampled, won't sound quite as good as it should, as we've already discussed multiple times. 

For *my* taste, I want the synth style bass to actually sound right.   Retriggering is probably going to make it sound off, to me.

I know it won't sound 'as good' but that doesn't mean it won't sound 'good'...
I've sampled an FM bass to use with famitracker on the DPCM channel, kinda like what Sunsoft did with some of their games, and the DPCM is 1 bit whereas the PCE PCM is 5 bit and doesn't support sample looping (not to a useful extent at least), but at least you can pitch-shift the samples in hardware, but you can only down-pitch them at uneven intervals so you need 5 samples with different notes (A#, B, C, C# and D) to get the full scale of notes...
All that said, the sampled FM bass sounded pretty good! Albeit too loud, the triangle channel can't even be heard while it plays... Yeah the Triangle sucks for basses, but put together with the Noise channel it can make some pretty good drums! It's all a matter of me editing the samples so that they can be quieter and then re-importing them and remaking the instrument, which I'm too lazy to do and too busy making PCE music instead, which is much better...

[elmer]

Well, screw you haters haha. There's potential in the "sampler" driver. I'm just going to refer to it as that, because I'm sick of typing out sample based synth. "Samplers" is the word used to describe sample based standalone synths in the 90s. So it works for me.

Sure ... you're right, and Akai pretty-much had the market cornered with them, BITD.

The terminology doesn't worry me, in the least.

Maybe not for HuC, but assembly (and for games, not demos) - it's doable. RPGs with SNES sampler style string leads on the PCE? Not interested? I am.

Then do it! 

You've found a musician who's raring to go ... get on with it! 

Let's all stop the "talking", and start more of the "doing" around here ... that's what I've been acting as the sand in the oyster and irritating folks for, for a while now ... 

Show us how darned good it can sound! 

What's with all this MSX stuff? I thought this was a PCE forum.

'cmon, you know it's not possible to talk to Arkhan about music for more than 60 seconds without the superiority of the MSX coming up. 

(But ... I really do like the sound of Yamaha FM synths, I've certainly bought enough of them.)

[Arkhan Asylum]

The terminology doesn't worry me, in the least.

lol.  this is a first.

Let's all stop the "talking", and start more of the "doing" around here ... that's what I've been acting as the sand in the oyster and irritating folks for, for a while now ... 

Agreed.  Though, often, the doing tends to taper off and then more talking comes, and then, you get the idea.   

'cmon, you know it's not possible to talk to Arkhan about music for more than 60 seconds without the superiority of the MSX coming up. 

(But ... I really do like the sound of Yamaha FM synths, I've certainly bought enough of them.)

You're the knob that brought it up, lol.   

I also don't think it's really superior.   It's just different, and has something PCE doesn't, which is 3 different main chips to work with.

But, everyone over there is actually quite jealous that the PCE can pan the fuckin' sound.   SCC can't do that.    At all.

and, to be fair, it's a completely relevant topic in this thread.  Why single out and bitch about the MSX when MD and SNES are also coming up in this thread?

and Amiga.

just because you, Bonknuts, don't care about it, doesn't mean it's taboo.

We're talking about sound sampling, while comparing and contrasting stuff.   Seems OK to me.



I'm genuinely curious if we can get a good FM synth bass sample that is convincing.   I have doubts.  So, if someone else can get one that doesn't make me go "yeahno", show me.

[TurboXray]

just because you, Bonknuts, don't care about it, doesn't mean it's taboo.

We're talking about sound sampling, while comparing and contrasting stuff.   Seems OK to me.

Dude. I'm just giving you some shit. No worries. It's like, every time MSX is mentioned - it's always by arkhan lol. It's more weird to mention it here on PCE forums because its user base seems to have a pretty big disconnect from PCE (and everything else; it's its own thing).

[Michirin9801]

The thing about the MSX is that it needs expansion soundchips to really sound 'good'...
Don't get me wrong the MSX PSG can put out good music if used right (USAS anyone?) But that's some "Not as good as NES" kind of good, and I'm the kind of person who doesn't even think the NES is THAT good... (Game Boy though is MUCH better because DAC)
In my personal opinion, expansion soundchips cheapen the value of the soundtrack while at the same time making the game more expensive... Yeah, the soundtrack is gonna be better with an expansion, but the system couldn't do that soundtrack without the expansion...

Personally, I'm more interested in what the system can do out of the box, which is why one of my Famitracker rules is "No expansions! Raw NES only!" and I'm all for pushing the limits of the system which is why I'm such a big fan of the Sunsoft DPCM bass and why I'm that much more impressed when I see parallax scrolling on the PC engine, the NES and the GB/GBC than when I see it on the SNES or on the MD for example... Those systems already have 2 or more BG layers out of the box, parallax for them is like, no sweat, in fact, all the more reason to be disappointed with them when they don't do it (except on top-down games, those don't really need parallax other than some very specific instances)
And that's also why I asked about wave-phasing, that was meant to be an easy-on-the-CPU way to get sample-like instruments on the PC engine! (Kind of)

With all that in mind it's no wonder I'm so excited about Bonknuts' sampler driver, it's gonna pretty much break the limits of the PCE without the need for any expansions!
Now don't get me wrong, it's not like there aren't any exceptions, I was the one wanting to use the CD ADPCM to play percussion samples and free up a PSG channel to play something else on a HuCard game, and I've made it no secret that I'm a huge fan of the SNES, and the system uses a f***ton of expansion chips!
(But you know, none of them are 'sound expansions', the SNES didn't need any sound expansions because it already sounds better than real life ;3)

Maybe not for HuC, but assembly (and for games, not demos) - it's doable. RPGs with SNES sampler style string leads on the PCE? Not interested? I am.

Then do it! 

You've found a musician who's raring to go ... get on with it! 

If you're talking about me, you're absolutely correct ;3
I am VERY interested...
(But first I gotta finish dat gaem...)

P.S. I also make Grafx in case someone didn't catch it, check out this example I did within the MD's limitations:

There's 3 overlapping layers, the tree in the middle layer is a sprite, I think you get how it works from just looking...

[Arkhan Asylum]

Msx2+ has onboard fm, and FM is part of the MSX standard, so, its not really an expansion at that point.

A large portion of the library uses it.   So, calling it an expansion is a bit limp.

Are you coding the MD game, or just art and tunes?

@bonknuts, oh, couldnt tell.

The msx scene has a good handle on PCE, though.   They just dont come here. 

Dunno why its weird to mention it here.   No wierder than any other computer.   Like Amiga, lol.

[Michirin9801]

Msx2+ has onboard fm, and FM is part of the MSX standard, so, its not really an expansion at that point.

A large portion of the library uses it.   So, calling it an expansion is a bit limp.

Yeah I get your point, but still, it 'was' an expansion at one point...

Are you coding the MD game, or just art and tunes?

I can't code for s***, I'm strictly an artist >w>';
I'm having help from 2 programmers, and we're making the game for the PC first, 'after' the PC version is completed THEN the MD version will be made...
That said though, we're thoroughly respecting the limitations of the MD on the PC version (with the exception of sprite flickering, not like there's gonna be much of it) so both versions should be pretty much identical (hopefully)

[TailChao]

C'mon ... you can get a YMF262 OPL3 FM chip + YAC512 DAC for $1.60 on fleabay ... we could totally blow-away all of those scummy MSX and Genesis guys!   

Well, on 2nd look, I think that we'd actually need a YMF289B OPL3 FM chip + YAC513 DAC, in order to meet the fast memory access timings of the PCE, and those cost a little bit more ... approx $6 per pair. 

You also need an oscillator and will only get mono audio anyway.

Those great 5V ARM microcontrollers from Cypress you brought up over a year ago are still the best solution here. Analog out is included, and if you add some sort of bidirectional comms in a mapper you can use it as a Cypress FX.

I ended up going with the FM3 family for my current project (specifically the MB9BF524K) and ported over my Windows softsynth without any huge issues. But this is a full music player, and I think in the case of the PCE it would be more useful to just complement what's already in the box.

BTW ... I absolutely *love* the sound of Yamaha's 4-operator FM synths. 

Fantastic sound, whole OPN family is really cool.

Although if you're just looking for chips to mess with the YM2608 is pretty well rounded compared to the others. I did start building a HuCard with an MC-Genjin + YM2612 on it a few years ago but never finished it for the sourcing reasons above.

RPGs with SNES sampler style string leads on the PCE? Not interested? I am.

If it works with the style of the game, why not?