Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maximum "burden" / exe playback issues #2

Open
armak opened this issue Aug 14, 2018 · 1 comment
Open

Maximum "burden" / exe playback issues #2

armak opened this issue Aug 14, 2018 · 1 comment

Comments

@armak
Copy link

armak commented Aug 14, 2018

Is there some "de facto" maximum complexity a song can have? Everything works perfectly in Renoise and the converter reports no issues, but at a certain "burden" value (somewhere between 1217319 and 1434107, lower value works, upper doesn't) the exe player is unable to play the track correctly, suffering from issues such as missing instruments, incorrect instrument parameters and extremely distorted sound.

This issue is somewhat urgent as it concerns an entry targeting Evoke.

@askeksa
Copy link
Owner

askeksa commented Aug 24, 2018

Thank you for the bug report.

As I explained in a separate email, the limiting factor here is not burden as such, rather it is the total memory needed for sample precalculation for the instrument. This memory usage is proportional to the number of notes times the length of the longest note (i.e. the last two factors of the four that constitute the burden).

The version of nasm that is included in the distribution as part of the easy_exe setup has a bug that makes it unable to reserve more than 256MB of uninitialized space in a single declaration. When a larger size is requested, only the bottom 28 bits of the size in bytes are used. A sufficiently large sample precalculation buffer will hit this bug, causing the sample precalculation to overwrite other buffers, resulting in broken sound.

The bug can be worked around by splitting the declaration of the sample buffer into more declarations with smaller sizes. But I would rather just upgrade the included nasm (don't know why I put such an old version in the first place) and then change the declaration in oidos.asm to use reso. This is what makes most sense anyway (allocating a number of 16-byte units) and has the side effect of requiring a nasm which is new enough not to have the bug. ;)

Some action items:

  • Change reservation directive to use reso.
  • Update the included nasmw.exe (on next release).
  • Clarify sample generation process (all tones at maximum note length) in the documentation.
  • Output memory usage from the converter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants