@chupo_cro: I've tried your code, and it seems to fix the problem, thanks.

I don't remember how was Shiru's code before he fixed the tempo problem, but now we have both the correct tempo, and the songs won't halt after a while (the "bourrasque" tune lasts 2 minutes, until the end, after it loops, instead of 10 seconds before)

Like for the other engines, we can add a nice led for lighning during the beats:

if(drum_pulse_length)
    {
        --drum_pulse_length;
               digitalWrite(LED,HIGH);
    }

Hi, I am not aware how the code looked like before, I have downloaded it this night. Since the variable used in a while loop is 8 bit, the only change was to remove the delay. That is possible because parser_sync_enable is always zero when loading parser_sync_l and parser_sync_h. If that would not be the case cli() and sei() would have to be added before parser_sync_l and after parser_sync_h respectively to prevent an interrupt in between loading low and high byte.

As for the 'light show', I have this little nice ATmega128 board (a picture) which has two SMD LEDs connected to the lowest two bits of the PORTA so the nice effect can be done by:

if(n>=2&&n<128)  //drum sound
    {
        drum_data=(const unsigned char*)pgm_read_word(&(drum_sample_list[n-2]));

        drum_output=0;
        drum_pulse_length=0;
        drum_sync=0;
        drum_request=1;

        PORTA ^= 0x03;        // turn off one of the LEDs and turn on the other one
                
        ++pattern_ptr;
    }

For that to work I added:

// LEDs
DDRA = 0x03;        // PA0 & PA1 = output
PORTA = 0x01;        // light on one of the LEDs

The same code could be used with Arduino by changing the port (and maybe the pins) and connecting one more LED.

The positions to add 'light show' code are:

Phaser1:

else  //118..127 is a drum
{
    drum_ptr=0;
    PORTA ^= 0x03;        // turn off one of the LEDs and turn on the other one
    drum_sample=1<<(tag-118); //bit mask for the drum sample

    cli();
    parser_sync=MUSIC_FRAME*1;  //drum always take one tempo unit, so it normally followed by the wait command
    sei();
}

Octode:

if(n>=0xf0)
{
    click_drum=7-(n-0xf0);
    click_drum_len=128;
    PORTA ^= 0x03;        // turn off one of the LEDs and turn on the other one

    ++pattern;  //skip to the next byte
}

Qchan:

if(tag>=0x81) //a drum
{
    tag=(tag-128)<<1;
     
    click_drum_cnt_1=tag;
    click_drum_cnt_2=tag;
      
    click_drum_len=0;
    PORTA ^= 0x03;        // turn off one of the LEDs and turn on the other one
 
    ++pattern_ptr; 
}

Fuzzclick:

if(tag>=0x81&&tag<0x81+4)
{
    drum_data=(const unsigned char*)pgm_read_word(&(drum_sample_list[tag-0x81]));
                
    drum_output=0;
    drum_pulse_length=0;
    drum_request=1;       //interrupt handler will get changed in the next tone interrupt

    PORTA ^= 0x03;        // turn off one of the LEDs and turn on the other one
}

It is quite nice to watch the dot jumping on every drum beat, I might record a video.

I am BTW using this ATmega128 board only when developing because the programs can fit in the memory even with the disabled compiler optimizations which can sometimes be neccesarry and because I can use cheap JTAG. The PCBs which I like to use for final products are this one and this one. These are Dropbox links to picture albums, no need to register.

I don't remember how was Shiru's code before he fixed the tempo problem, but now we have both the correct tempo, and the songs won't halt after a while (the "bourrasque" tune lasts 2 minutes, until the end, after it loops, instead of 10 seconds before)

Like for the other engines, we can add a nice led for lighning during the beats:

if(drum_pulse_length)
    {
        --drum_pulse_length;
               digitalWrite(LED,HIGH);
    }

Interestingly, I noticed that while the COM monitor is active, the resetting stops, so it became a bit easier to debug.

Anyways. I think I found a fix for the player hanging. That's likely related to the way I was invoking the drums - by changing the interrupt handler pointer from the main thread. But that's AVR8, so this operation is not atom - it changes two bytes one by another, and there is a good chance (considering the high sample rate) that timer interrupt will occur in the middle of the change, calling the half-changed address of the handler function. I tried to fix it by changing the handler only in the timer interrupt handler, where it is guaranteed that another interrupt won't occur. Re-attached the code to the first post, please test.

Perhaps it's easier to disable auto-reset until you've found the culprit?

My Arduino works well with the external 5V power source plugged into USB. The problem is that I need to have it hooked up to PC in order to debug. Haven't found a suitable 9V adapter just yet ('minus outside' are rarity here, don't have spare ones to rewire either), hopefully it will fix the issue.

I've tested on another arduino (a dccduino clone), and it's the same, it stops at the same moment. But this moment seems rather random from one song to an other: I've isolated the part when I stopped, and removed all patterns before it. Then this time it won't stop there, but only after a while.

In the original "bourrasques" tune it stopped after 25 seconds, now with this abridged version, it's after 12 seconds, will it be enough for you to test? Here is the music_data as attachment.
I've put 2 files, one (v0) with the original data, only the part before the bug were removed, but the song last until the normal end. For the other one, I've removed the end, I've only kept the data until it stops + about 3 seconds, so it's supposed to stop after 15 seconds but will stop at 12 sec.
I've also tried to remove the loop (I chose exit instead before compilation) but it's the same, stop after 12 sec (the output data are identical)

Will your arduino reset as well if you plug it to a 5V phone charger, after you've uploaded the sketch?

I'll test it on another arduino, in case it's the one I use (official Arduino Uno) which has some limitations (but it doesn't stop like that with other engines). I've already encountered differences between arduino versions, for example a shield was working on a clone, but not on the official one, and not either on another clone.

I don't know what happened with the attached files. Here it is again. (edit: I know, I've just selected the file with the browser, but forgot to click on "add file")

(edit) I've quickly tested it, tempo is ok for the "bourrasque" tune, but it still stops during the replay. For the other "souvenirs", it doesn't stop at the beginning like before, but I haven't replayed it completely. I'll test more soon. Thanks again for the fix anyway.

Regarding the slower tempo, no, Arduino can handle crazy speeds, that's not the issue. That's seem to be just a misimplentation of the thread sync (row counters in beeper engines may work in tricky ways). Thinking how to fix it now.

Edit: made the tempo fix and replaced the test song with yours. The file attach replaced, please re-download.

Yet, I've found a few problems:

- I have a song with a very fast tempo of 19 (in the zip it's called music_data_bourrasque.h and the original from zx version can be heard there http://chipmusic.org/garvalf/music/bourrasques ). The arduino code doesn't handle that probably because it's too fast. The song is slowed down, with it seems some accelerations and decelerations (I guess it's not possible to fix this, which I can understand)

- on at least two of my songs, (music_data_souvenirs_tritone.h and music_data_snakecharmer.h) the arduino stops the music before the end, on the first one it's after just a few notes, on the second one it's a bit longer but not much. Probably there are some data which are confusing the engine...