No.. It actually did save this module I attached in the Program Files folder (as opposed to the Virtual Store folder). Maybe it only affects PCE DMFs? I haven't checked.
I re-uploaded DefleMask with your track, I tried to open your file and a "module file error" poped up, so I also fixed this with the switch to PC-Engine done.
Here's a bug: after an instrument's volume envelope has reached the end, writing a value in the channel's volume column sets the volume to that value instead of calculating the relative volume.
That is not a bug, it is intentional. When an envelope finish it influence is gone, because I think thar it is very confusing having relative volumes on the 90% of the track.
Maybe it is a little different than Famitracker but it is not a bug.
Annoying for a user accustomed to FT :P, I prefer this way because it is more logical to have the volume column with abs values rather than relative values all the fucking time. The volume for a channel modified by the volume column ends up being almost a riddle in FT with his envelopes. xD
Maybe you misunderstood me then. If the envelope is done playing, inputting "C" in the volume column actually sets the volume to 12 instead of calculating what 13/16 of the envelope's final volume value would be.
Maybe you misunderstood me then. If the envelope is done playing, inputting "C" in the volume column actually sets the volume to 12 instead of calculating what 13/16 of the envelope's final volume value would be.
I do not misunderstood you:
... NO ENVELOPE [Volume Absolute]
C-3
... ENVELOPE RUNNING...[Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE DONE...... [Volume Absolute again]
... NO ENVELOPE........ [Volume Absolute again]
With looping:
... NO ENVELOPE [Volume Absolute]
C-3
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE LOOP...... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
... ENVELOPE RUNNING... [Volume relative to envelope]
I always hated that behavior in FT, because if you want to rise the final volume of the channel after an envelope you can not, the only way to do that is to create an envelope very large and much of them (very soundchip expensive), create another instrument with your desired volume of size 1 (sucks), or not even use envelopes and done your track of speed 1/1 (sucks more).
Maybe if you are an accustomed to FT user you will hate this (almost all users of this forum), but I think that this feature of FT is bad and all of you are accustomed to it. :P
Well, you could just put the envelope into a loop on the last value.
Yeah, that will be a solution!, unfortunately that is not recommended because it will send to the soundchip very rapid register writes for nothing.
The actual solution is to check the final envelope volume value that you created and use it as a reference!.
rainwarrior wrote:
In FamiTracker you could just play the same note on a blank instrument when your envelope is done to manually return to absolute volume, I suppose.
Yeah, but you are re-triggering the note only for change the volume!, that's not recommended, specially on Game Boy or FM soundchips, where the NOTE-ON call will clear some strange counters among other stuffs.
Well, I did say "in Famitracker", where there are no consequences for a new note.
On another note, is there really a problem with writing volume every frame? What kind of sounchip wouldn't handle that? Maybe it would bloat a VGM file, but you could probably strip redundant writes.