Extra GGsound Limitations

FrankenGraphics

FrankenGraphics

New member
Baking sustain levels and pitch changes into instruments is the typical modus for game oriented drivers. It's not much of a problem either, except that it bamboozles anyone used to the conveniences of the Famitracker driver. The silver lining is that envelopes are infinitely reusable between instruments, so it's not nearly as wasteful as it first might look - it might actually make for smaller song file sizes in the long run for a complete soundtrack = you can potentially fit in more songs in your dedicated song bank(s). On the other hand, not planning ahead can lead to the opposite.

The only ft effects i personally find worth bothering about when deciding on what driver to use are the ones that can't be achieved with envelopes. Looping/jumping, tempo, pattern cut, song stop, typically.

GGSound has loop. In fact, songs must end with the loop command. I'm not sure what actually happens if it isn't there - does it stop (that would actually be very elegant) or does it run into whatever data comes next? I need to try that out.

FamiTone2 has loop*, tempo, and pattern cut.

Pently has loop and tempo. Pently is a special case, because since it can't change pitch via its instruments, vibrato and portamento effects goes here too. Vibrato can't change speed, so it's actually a little less agile than GGs and FT2.

*loop for FamiTone2 is explicitly only backwards. I don't know about the others actually, i've never tried doing a forward reference. You can in famitracker, but i suppose this usage is not very common.
 
CutterCross

CutterCross

Active member
FrankenGraphics said:
Baking sustain levels and pitch changes into instruments is the typical modus for game oriented drivers. It's not much of a problem either, except that it bamboozles anyone used to the conveniences of the Famitracker driver. The silver lining is that envelopes are infinitely reusable between instruments, so it's not nearly as wasteful as it first might look - it might actually make for smaller song file sizes in the long run for a complete soundtrack = you can potentially fit in more songs in your dedicated song bank(s). On the other hand, not planning ahead can lead to the opposite.

The only ft effects i personally find worth bothering about when deciding on what driver to use are the ones that can't be achieved with envelopes. Looping/jumping, tempo, pattern cut, song stop, typically.

GGSound has loop. In fact, songs must end with the loop command. I'm not sure what actually happens if it isn't there - does it stop (that would actually be very elegant) or does it run into whatever data comes next? I need to try that out.

FamiTone2 has loop*, tempo, and pattern cut.

Pently has loop and tempo. Pently is a special case, because since it can't change pitch via its instruments, vibrato and portamento effects goes here too. Vibrato can't change speed, so it's actually a little less agile than GGs and FT2.

*loop for FamiTone2 is explicitly only backwards. I don't know about the others actually, i've never tried doing a forward reference. You can in famitracker, but i suppose this usage is not very common.
Click to expand...
In my tests, I couldn't get Bxx to work at all within NESmaker. It just completely ignores it in the compiled ROM.

Songs don't have to end with Bxx, at least not in NESmaker's use of GGsound. It just loops back to the beginning when the song ends.
 
FrankenGraphics

FrankenGraphics

New member
I concede that i haven't had the time to redeem my copy of NESmaker yet, so i wouldn't know if there are any differences... But did you place Bxx on the same step in each and every channel? That is a requirement in the original. (As a natural consequence, each pattern at the loop seam needs to be a unique occurrence).
 
CutterCross

CutterCross

Active member
FrankenGraphics said:
I concede that i haven't had the time to redeem my copy of NESmaker yet, so i wouldn't know if there are any differences... But did you place Bxx on the same step in each and every channel? That is a requirement in the original. (As a natural consequence, each pattern at the loop seam needs to be a unique occurrence).
Click to expand...
Yes, I did put Bxx in the same step of all 5 channels. The compiled ROM still ignores it.
 
FrankenGraphics

FrankenGraphics

New member
Hm... It almost sounds like the effect reading routine has been commented out, deleted or otherwise disabled in favour of automated looping. I haven't looked that closely at the source of ggsound, and definitely not looked at the asm source of nesmaker so i wouldn't actually know. Maybe the guys who do know will chime in.

But you could probably hack in an interception into the music update routine. For example, it is typical that the DPCM channel only uses one instrument (i use instrument 00 out of old habit, because that's what another driver expects explicitly). So, Intercepting an instrument usage on the DPCM stream that is other than 0 can be facilitated to call functions internal to GGsound. That can be used as a hacky range of master/"transport deck" control effects similar to those in famitracker. A safeguard in the DPCM playback routine(s) that ignores instruments 01 and upwards probably needs to be added too, to avoid undefined behaviour.

i'd first set up a beq branch around all the exceptions we might want to define, so that they are ignored as long as the last instrument used on DPCM was 0. Then we don't need to look for "effects", and performance is effectively unaffected.

within that branch, i'd load the instrument into x, dex, bne, and call some stuff.

So instrument 01 on the DPCM channel could jsr pause_song, which is a hacky way to stop a track dead. Except the player might be able to unpause it depending on if that's a thing in your game, so not the best generalized option. Just mentioning it for simplicitys' sake. The correct procedure would be, if i've gotten it right from my quick glance at the source, to tell each and every stream to stop, except the two sfx streams, i guess. This way one-shot songs and jingles can be achieved.

Looping to the beginning could be as easy as jsr play_song, if i'm not mistaken. Looping to a specific frame would require some counting and setting all music stream addresses accordingly. I'm not up to the task just yet. But the most valid point of a loop command is precicely to set it to something other than the first frame.

Setting the Delta Counter (effect Zxx) should be a dead easy hack. Add this to your driver library:
.proc Zxx
sta $4011
rts
.endproc

Then call it whenever by
LDA n
jsr Zxx

or just skip the subroutine call altogether by doing it directly:
LDA n
STA $4011

;where n should be a literal number between $00 and $7F. The eight bit is ignored, since the delta counter is 7-bit. That means values $80-$FF is just a mirror of $00-$7F

And then you'll have a shared master volume control over tri and noise. Just watch out for too big changes to the delta counter done instantaneously - they result in audible, unpleasant scratchy pop sounds. Incrementing or decrementing by a few levels (about 2-8) each tracker step is largely inaudible though, especially on real hardware, and the $00-$40 range is the most effective anyways so we don't need the whole range. I'd probably set it up so that there are two separate effects for incrementing or decrementing the delta counter by a fixed amount. Setting it directly is mostly useful in preparation of a song, so it needn't be part of some hacky command/effect scheme.

Okay, that became quite a bit of a tangent...

I might actually set out to work on a standardized hacked-on appendage to GGsound at some point if i can find the time to devote myself to unraveling it. Primarily looking to add Speed adjustments since that is the feature i'm missing the most personally.
 
CutterCross

CutterCross

Active member
FrankenGraphics said:
Hm... It almost sounds like the effect reading routine has been commented out, deleted or otherwise disabled in favour of automated looping. I haven't looked that closely at the source of ggsound, and definitely not looked at the asm source of nesmaker so i wouldn't actually know. Maybe the guys who do know will chime in.

But you could probably hack in an interception into the music update routine. For example, it is typical that the DPCM channel only uses one instrument (i use instrument 00 out of old habit, because that's what another driver expects explicitly). So, Intercepting an instrument usage on the DPCM stream that is other than 0 can be facilitated to call functions internal to GGsound. That can be used as a hacky range of master/"transport deck" control effects similar to those in famitracker. A safeguard in the DPCM playback routines that ignores instruments 01 and upwards probably needs to be added too, to avoid undefined behaviour.

i'd first set up a beq branch around all the exceptions we might want to define, so that they are ignored as long as the last instrument used on DPCM was 0. Then we don't need to look for "effects", and performance is effectively unaffected.

within that branch, i'd load the instrument into x, dex, bne, and call some stuff.

So instrument 01 on the DPCM channel could jsr pause_song, which is a hacky way to stop a track dead. Except the player might be able to unpause it depending on if that's a thing in your game, so not the best generalized option. Just mentioning it for simplicitys' sake. The correct procedure would be, if i've gotten it right from my quick glance at the source, to tell each and every stream to stop, except the two sfx streams, i guess. This way one-shot songs and jingles can be achieved.

Looping to the beginning could be as easy as jsr play_song, if i'm not mistaken. Looping to a specific frame would require some counting and setting all music stream addresses accordingly. I'm not up to the task just yet. But the most valid point of a loop command is precicely to set it to something other than the first frame.

Setting the Delta Counter (effect Zxx) should be a dead easy hack. Add this to your driver library:
.proc Zxx
sta $4011
rts
.endproc

Then call it whenever by
LDA n
jsr Zxx

or just skip the subroutine call altogether by doing it directly:
LDA n
STA $4011

;where n should be a literal number between $00 and $7F. The eight bit is ignored, since the delta counter is 7-bit. That means values $80-$FF is just a mirror of $00-$7F

And then you'll have a shared master volume control over tri and noise. Just watch out for too big changes to the delta counter done instantaneously - they result in audible, unpleasant scratchy pop sounds. Incrementing or decrementing by a few levels (about 2-8) each tracker step is largely inaudible though, especially on real hardware, and the $00-$40 range is the most effective anyways so we don't need the whole range. I'd probably set it up so that there are two separate effects for incrementing or decrementing the delta counter by a fixed amount. Setting it directly is mostly useful in preparation of a song, so it needn't be part of some hacky command/effect scheme.

Okay, that became quite a bit of a tangent...

I might actually set out to work on a standardized hacked-on appendage to GGsound at some point if i can find the time to devote myself to unraveling it. Primarily looking to add Speed adjustments since that is the feature i'm missing the most personally.
Click to expand...
If you have the ability to hack all that in, then by all means, be my guest!
I'm not really concerned about all that right now though, it's important to know what the vanilla sound engine can do in NESmaker first before trying to add anything on to it.
 
FrankenGraphics

FrankenGraphics

New member
Yeah it's not a priority for me either... i have two FamiTone2-using games to roll out the door first. Then finalizing my two GGsound soundtracks is my next priority, so it'd come naturally to have a look at it by then, which isn't soon.

I think the most important thing right now (for the sake of this discussion) is to get any minute differences between using vanilla ggsound and nesmaker documented/confirmed.
 
CutterCross

CutterCross

Active member
FrankenGraphics said:
Yeah it's not a priority for me either... i have two FamiTone2-using games to roll out the door first. Then finalizing my two GGsound soundtracks is my next priority, so it'd come naturally to have a look at it by then, which isn't soon.

I think the most important thing right now (for the sake of this discussion) is to get any minute differences between using vanilla ggsound and nesmaker documented/confirmed.
Click to expand...
That's what I've been trying to do! But of course, I'm not perfect and I may get some details wrong, so it's always good to have someone else working on this to catch any mistakes I make!
 
FrankenGraphics

FrankenGraphics

New member
Oh sorry! I somehow missed there was a whole second page of this thread and replied directly to the last post on the 1st page - I didn't mean to turn a blind eye to your previous efforts. :O
 
functionalform

functionalform

Member
from what i saw GG say about it, it's the importer .exe that's different.

so if we just compile the asm6 convertor from GGsound themselves, and drag the resulting exported FT txt into our project, will it link up?
 
FrankenGraphics

FrankenGraphics

New member
I think the crux is (for some users, in theory) that the original converter is not an executable, but a python script. Py is such a popular environment to have in handy in homebrew circles since the majority of the folks are programmers anyway. So all game oriented audio drivers currently use py scripts to convert text to assembly data. Requiring NESmaker users on the other hand to have python installed can be a tough sell given that it was supposed to be "no coding required" which extends to having to install a programming environment even if nothing is to be coded in it, so i think that's the rationale behind the custom executable converter.

Personally i think installing python is the better option, but agree that there should be a dependency free option for those who don't want to bother. There's also straightforward python to .exe containers, so there might be other reasons for making it custom that i don't know about. For example i'f they've decided to organize the song data differently to comply better with the rest of the overall structure of the game engine. If that's the case, some manual editing might be warranted when using the original py script.
 
functionalform

functionalform

Member
I'll compile a windows .exe from the original .py tomorrow and maybe shoot it off to cutter for testing?

i'm not well versed in famitracker, so i'd need someone to test it out for me.
just want to give composers a bit less strain.
 
drexegar

drexegar

Member
OK after fixing my complicated tracks I realized some things.

- Instruments can have spaces

- song names get shorten to 5 letters
There will be errors if more than 1 track name matches, and errors if a song name
begins with a space.

- songs can have frames over 09, but any channel cannot use more than 09 patterns.
A work around for longer music is make patterns bigger, so far 128 works for me.

- nesmaker hates empty patterns in songs, make a mute instrument and place it
anywhere in the pattern.


These are the things I had to fix when my complex music had errors in nesmaker.
 
V

vrbandwagon

Member
It will be interesting to see what the NESmaker music editor will offer. Will it be able to make Famitracker redundant in terms of effects for example.
 
D

darkhog

New member
drexegar said:
- song names get shorten to 5 letters
Click to expand...

I call BS on that one. In my project I have song DeepTrouble and name imported fine. However, if name has any space in it, everything after and including that space is dropped (earlier the song was called Deep Trouble and it imported as song_Deep).
 
D

darkhog

New member
vrbandwagon said:
It will be interesting to see what the NESmaker music editor will offer. Will it be able to make Famitracker redundant in terms of effects for example.
Click to expand...

I've heard it'll be piano roll. So probably closer to PxTone than FT. I'd rather have a tracker-like one with its own set of effects that can be imported properly, however, as I prefer trackers. I mean, FT import probably will remain as an option but yeah.
 
V

vrbandwagon

Member
darkhog said:
vrbandwagon said:
It will be interesting to see what the NESmaker music editor will offer. Will it be able to make Famitracker redundant in terms of effects for example.
Click to expand...

I've heard it'll be piano roll. So probably closer to PxTone than FT. I'd rather have a tracker-like one with its own set of effects that can be imported properly, however, as I prefer trackers. I mean, FT import probably will remain as an option but yeah.
Click to expand...

Yes, I spent countless days using Fast Tracker II when I was younger, so the transition to Famitracker was a breeze. It also has a piano roll so I’m wondering how the NESmaker team intends to implement effects through that without using a tracker interface.

It’s weird to me that conversion problems with Famitracker arise from the manually input effects in the tracker, as making individual instruments that each have their own effects seems harder to convert... But that must be just how GGsound engine works and there isn’t much we can do about it.
 
functionalform

functionalform

Member
vrbandwagon said:
Yes, I spent countless days using Fast Tracker II when I was younger, so the transition to Famitracker was a breeze. It also has a piano roll so I’m wondering how the NESmaker team intends to implement effects through that without using a tracker interface.
Click to expand...

funny enough, i started in screamtracker in 95' and over time got into actual daws and hardware, now i'm absolutely fuckin lost in trackers.
i gotta find that 16 portion of my brain again.
 
drexegar

drexegar

Member
darkhog said:
drexegar said:
- song names get shorten to 5 letters
Click to expand...

I call BS on that one. In my project I have song DeepTrouble and name imported fine. However, if name has any space in it, everything after and including that space is dropped (earlier the song was called Deep Trouble and it imported as song_Deep).
Click to expand...

Its not BS, nesmaker shortens you names to 5 letters when imported, I had BEACH1 and BEACH2 and it got imported to BEACH and BEACH thats when nesmaker got confused.

Yes you can name it as long as you want but if you end with two of the same name after it get cut down nesmaker will ignore the other copies and start playing the same track over and over again where the name matches.

SO if you have GARYSLIAR and GARYSHOUSE, it will import as GARYS and GARYS and then nes maker doesn't like the same name for tracks. So the first GARYS will play and the second GARYS will just play the first track again.
 
You must log in or register to reply here.
Top Bottom