Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
I started to track again recently and I came upon this issue.
For example, let say that I have this volume for an instrument for the noise channel:
15 14 12 9 5 2 3 8 6 5 2 2 2 4 3 3 1 0
Then during tracking, I decide to adjust the volume again on the row. If the volume is high, everything is fine.
Let's say that we apply 3 on the row. I know, it's very low. Inside famitracker, it sounds like I expected, some notes are dropped or very low. When I convert it to an nsf on the other hand, the lower volumes will all become the same (maybe 1 or something) which now make one long note with the same volume, which I didn't want.
It is a normal behavior of famitracker or a bug? If it's normal, what is the better approach, make another instrument which simulate a very low volume for the same thing shown above?
I can always provide a sample later but the mml above should be able to simulate the problem.
Both should sound the same, so it is a bug. And the bug is actually in the tracker, as the volume is supposed to round up to 1 if the result is less then 1. The square channels behaves this way, both in the tracker and when exported to NSF.
I will fix it for the next version. Thanks for the report!
At first I sent you a PM on nesdev with a not so descriptive title but since I thought that the chances are that it's just another beginner error, I decided to post it to this forum instead and see what the community will say
So it was a bug after all. In the tracker, the sound was too low to really hear it but once I converted to NSF, it was obvious. For now, I made a temporary instrument to mimic how the instrument should sound like at this low volume. Since I'm using an older version (2.9) because I modified a little bit the driver, I won't be able to use the new version right away.
By the way, I don't think there is any document about the data structure of the music binary data? That could be useful (more for a programmer) to know how the data is saved so I can know what as an impact on size. I guess it's not the worry of many people thought
Seems I never got the message on nesdev for some reason.
The music data is currently undocumented (without reading the data generator or nsf code) but I'm working on documenting both that and the FTM format, as both has been asked for. However, the NSF exporter tells how much space each part of the exported file takes right now. Might help some in optimizing. I'm also experimenting some on new formats of storing the music patterns, but haven't come far with it yet unfortunately.
.png){kind=avatar}
