Initially when designing this, I imagined that any given pattern could be played back by any type of channel (square/wave/noise). Since patterns mostly specify instrument numbers directly, and a given instrument can only be used by one type of channel, there are a few spots in the code that are essentially worthless, as the editor will know at compile-time exactly what pattern will be played by what channel and can specialize the effect command to be tailored to that channel immediately instead of during runtime which costs precious cycles.

_quantize_channel4_note and set_chn3_vol come to mind. However! if patterns contain only note values/effects and no specific instrument, they could be used by any channel and therefore this code would actually come in handy.

Honestly I think this is probably fine to leave in, but it's worth a think.

sample_song.c is outdated and will not build: should be updated with a fresh export from latest hugeTracker

rgb2sdas.exe reports:

ERROR: Unsupported object file version! This version of rgb2sdas supports RGB9, revision 6 files. The provided file is RGB9, revision 7.

I can't seem to find any information about how to use the gbdk example on linux. if there's a way please add it to the README! thanks

Seems like hD has an issue with Note Delay (7xx) not working correctly.

Attached find an example which used Note Delay (701, 702, 703) at the end of the 1st order:
TR_Note-Delay-test-01.zip

Here is the result with a GBS using hD

And here is a result with a GBS using fortISSimO (which renders the 7xx commands correctly imho):

Videos where done with https://github.com/nununoisy/gb-presenter-rs which uses Sameboy for Audio rendering.

Would it be too difficult to allow the Game Boy Advance to play hUGETracker music?

GBT Player already allows it, so it should be possible at least.

When build the GBDK 4.1.0 example program I got the following error:

#Build the rom!
../../gbdk/bin/lcc -I../include -o output.gb gbdk_player_example.c hUGEDriver.obj.o sample_song.c
gbdk_player_example.c:
sample_song.c:
?ASlink-Warning-Conflicting sdcc options:
   "-msm83" in module "gbdk_player_example" and
   "-mgbz80" in module "hUGEDriver_obj".
make: *** [Makefile:10 : all] Erreur 1

This can be fix by changing the lien 593 of rgb2sdas.pas from

Writeln(F, 'O -mgbz80'); to Writeln(F, 'O -msm83');

With GDBK 4.1.0 there is an error with add_VBL(hUGE_dosound);

gbdk_player_example.c:
gbdk_player_example.c:25: error 78: incompatible types
from type 'void function ( ) __sdcccall(0) fixed'
  to type 'void function ( ) code* fixed'

The example program builds and works when calling hUGE_dosound(); in loop, before wait_vbl_done();, although this is less cool

Hi,

Thank you very much for making this great project! It's a really nice music driver for my favorite handheld console.

I wonder, is there any plan to support a loop flag to indicate whether to loop the sound, and is it possible to determine whether a sound is finished?

Thanks for your time!

You can implement a sort of swing rhythm in a song by using effect $Fxx and alternating between 2 tempos. We could probably build this in so it alternates between 2 (or even more) tick speeds automatically without hogging an effect channel doing it manually.

https://github.com/DevEd2/FXHammer-Disasm

FXHammer has two RAM registers (Ch2Flags, Ch4Flags) that it uses to see if CH2 or CH4 is currently used by the music driver.
It would be practical to use those, FXHammer doesn’t touch those channels when the least significant bit isn’t set.

Right now, _AUD3WAVERAM is loaded with a constant value and isn't updated when the instrument changes.

We only want to write to wave ram when the instrument changes on tick zero, so this probably needs an extra variable to track the old waveform address (not instrument number, as instruments can have the same waveform!)

Would it be too difficult to add in support for SGB-enhanced music like in Hercules and Animaniacs into HUGEDriver?

It's never been done before in homebrew, so maybe it is very difficult.

I used the sample_song.c found here without knowing the music name or the author so I couldn't give proper credits.

issue : give the name and author somewhere on this github.

Carillon Player allows to run from a special bank with a fixed jump table that can be used to call it:

• Player_Initialize at $4000
• Player_MusicStart at $4003
• Player_MusicStop at $4006
• Player_SongSelect at $400c
• Player_MusicUpdate at $4100

Being compatible with that would have two benefits:

• Roms that use Carillon Player could easily switch to hUGEDriver
• It could become an alternative solution for combining it with C functions without the need to translate the assembly

In my game, I have one music for the stage and one for the pause menu.
I just reload the corresponding music on (un)pause.

I want to restart the stage music where it was on pause, but the current music position is lost when loading another song. So how can I do that?

Two things:

1. I see there is no hUGE_Get_position or something similiar, but I suppose you can calculate that, but how?

also, is it possible to implement a hUGE_get_position()?

2. I see there is a hUGE_set_position(unsigned char pattern); in the header, but how to use that? what pattern refers to?

Thanks!

As it stands, the contents of patterns can be fairly repetitive and not benefit from any sort of compression.

There are a couple solutions I've been thinking about:

• Remove the restriction that patterns need to be 64 rows, and let patterns be any size, with some sort of terminator at the end to signify when it's over. This would allow musicians to write short phrases, and repeat them with only 2 bytes in the order table. Basslines and arps would benefit greatly from this sort of thing, and it's how AHX and Klystrack do it, I think. We could even just do pattern recognition/repetition logic in the tracker code itself so the user doesn't have to think about song size and can just focus on using it like a MOD tracker (4x64 patterns with lots of repetition)

• Leave the 64 row restriction in place and simply do pattern repetition recognition in the tracker code, then implement "loop points," similar to ProTracker's E6x command. There's a lot of unused note constant values, since only 71 are used and there's a range up to 255.

I'm partial to the first option since I don't really like the idea of having 2 "methods" of breaking up music (patterns/loop areas), and the second option would require some more logic to handle looping in each channel, whereas the first option fits pretty nicely in with the current structure of the code.

To be honest, this can probably be put off until after the first release or whatever since what currently exists is (afaik) better size-wise than everything out there already.

• Add a way to stop playing and reset track pointer back to beginning
• Add a way to pause music but continue on next time it's resumed
• Add a way to resume paused music
• Add a way to set whether the music loops
  If any of these are possible already, please let me know!

ERROR: Unsupported object file version! This version of rgb2sdas supports RGB9, revision 6 & 7 files. The provided file is RGB9, revision 8.