[mpt] Accept files malformed due to a bug in the original tracker.
That would break compatibility. Having the 40 character ATASCII restriction in the Tags, file names and folder names is a good thing. ´That's why I keep a 2nd file with Unicode mappings (and more) of the composers. So maybe for a start, could we have something like the lookup searching for "STIL*.txt"? Then I can play around the generating STIL without harming the manually edited file.
[relocate] Play modules with low loading address by relocating.
[test] Relocation.
[test] Test conversion to SAP, from SAP, to XEX.
[examples] Add example files.
I can confirm that it is fixed for me.
We cannot have unicode inside SAP. Why not? Long time ago, Jakub Husak proposed changing the whole SAP header to UTF-8.
[cleanup] Fix MSVC warnings.
[test] Update test/benchmark.
[cleanup] Remove test/disasm.
I originally opted for STIL information in SAP files as extra tags. Ok, then I understood this differently/wrong: https://asma.scene.pl/wiki/StilVsExtraSapTags I thought, you were against adding that information to SAP in first place. A huge benefit I see in having separate file/files is that they can support unicode (which is something we already use a log in the STIL.txt). We cannot have unicode inside SAP. Other than that, I'd find self-contained files the optimum. Base on my experience of the...
I originally opted for STIL information in SAP files as extra tags. Ok, then I understood this different/wrong: https://asma.scene.pl/wiki/StilVsExtraSapTags I though you were against adding that information to SAP in first place. A huge benefit I see in having separate file/files is that they can support unicode (which is something we already use a log in the STIL.txt). We cannot have unicode inside SAP. Other than that I'd find self-contained files the optimum. Base on my experience of the past...
Support STIL information in ".stil" co-files
I originally opted for STIL information in SAP files as extra tags. Ramos (RIP) wanted a plain text file, like HVSC did. 1) 2) I don't see what's the issue? You can mass-import to temporary storage, then merge to STIL.txt 3) tools/validate-stil.bat in ASMA repo checks if the filepaths reference to actual files
Support STIL information in ".stil" co-files
`make check` fails with `No rule to make target '../Acid800/out/Release/AcidSAP/standalone'`
Acid800 tests are now skipped if not in place.
[test] Shorten the test invocation.
[test] Explain the expected failures.
[test] sf bug #37 Skip Acid800 if not present.
[android] Revert subsong number in MediaMetadata.
[android] Show subsong number in notification.
Check added with https://github.com/asma-atari-org/asma.atari.org/commit/7a65eee0e617c576ffbd0a276207ddd2fa4eb670
I only asked, because the STIL spec actually does not state anything about the path length explicitly. Only the tags ( "COMMENT: ") which are all 9 characters and the values (which are at most 90 characters) are mentioned. Effectively, the HVSC STIL uses 78 characters per line. I also didn't mean to change the limit, but add instead a check on my side, if there is a defined limit. I've added the details to https://asma.scene.pl/wiki/StilVsExtraSapTags How about "Anschuetz_E_and_Weisgerber_J_and_Anschuetz_R"...
I only asked, because the STIL spec actually does not state anything about the path length explicitly. Only the tags ( "COMMENT: ") which are all 9 characters and the values (which are at most 90 characters) are mentioned. Effectively, the HVSC STIL uses 78 characters per line. I also didn't mean to change the limit, but add instead a check on my side, if there is a defined limit. I've added the details to https://asma.scene.pl/wiki/StilVsExtraSapTags How about "Anschuetz_E_and_Weisgerber_J_and_Anschuetz_R"...
I only asked because the STIL spec actually does not state anything about the path length. Only the tags ( "COMMENT: ") which are all 9 characters and the values (which are at most 90 characters) are mentioned. Effectively, the HVSC STIL uses 78 characters per line. I also didn't mean to change the limit, but add instead a check on my side, if there is a defined limit. I've added the details to https://asma.scene.pl/wiki/StilVsExtraSapTags How about "Anschuetz_E_and_Weisgerber_J_and_Anschuetz_R"...
STIL Length Restriction?
astil.c limits the number of characters per line to 100. I'm pretty sure the official spec (https://www.hvsc.de/download/C64Music/DOCUMENTS/STIL.faq) posed this limit (probably even stricter, at 80 or 90 characters), but I can't find it now for the filename lines (nor all lines). I'm against lifting it. By using paths this long, we can hit the 256 path limit on Windows. How about "Anschuetz_E_and_Weisgerber_J_and_Anschuetz_R" ?
STIL Length Restriction?
[cleanup] Simplify POKEY writes.
[seek] Don't unmute on rewind.
Revert "[seek] Don't unmute on rewind."
Tortoise Diff: The file C:\TEMP\Rock_1.sap-rev798.svn001.tmp.sap is not a valid text file!
The problem is fixed with ASAP 8.00. You can close this ticket.
I've tested and works great.
I've tested both, the ZIP and the installer and it all works perfectly.
I've test both the ZIP and the installer and it all works perfectly.
Hi Fox, I lot has happend since I last posted on this. Since then I effectively took over the RMT 1.3x maintenance and am in the process of understanding how the sound generation and file exports there work. As opposed to when I thought when I posted this, today's XEX output fo RMT 1.34 (that is the VU Player) is based on LZSS but this LZSS is still generated by the emulated 6502 running a special modified version of the RMT Player (Patch 16, by default). So my aim for RMT 1.3x is to enable an RMT...
Hi Fox, I lot has append since I last posted on this. Since then I effectively took over the RMT 1.3x maintenance and am in the process of understanding how the sound generation and file exports there work. As opposed to when I thought when I posted this, today's XEX output fo RMT 1.34 (that is the VU Player) is based on LZSS but this LZSS is still generated by the emulated 6502 running a special modified version of the RMT Player (Patch 16, by default). So my aim for RMT 1.3x is to enable an RMT...
Can you give me an executive summary so I don't have to read 21 pages of https://forums.atariage.com/topic/328790-release-raster-music-tracker-v13400/ or 100s of GitHub commits? I see: https://github.com/VinsCool/RASTER-Music-Tracker https://github.com/raster-atari-org/RASTER-Music-Tracker (no master branch, just "1.35", "1.29", "1.30", "1.34.00-stable", "1.34.00" branches?) What's "VU-Player" ?
[fu] Remove range types.
Fix confirmed. ASMA is updated.
[release] 8.0.0.
[osx] Don't wait for notarization.
ASAP 8.0.0 released
[d15] Enable in BASS, Winamp, XMPlay, Windows Explorer, setup.
[doc] No more ZIPs on Android.
[doc] Update credits.
[doc] No wildcards on Windows.
[doc] Document the WAV to D15/D8 conversion.
[setup] Shorten labels to available space.
[setup] Narrow the associations for AIMP.
[setup] "Open with".
[seek] Don't unmute on rewind.
[shellex] Fix installer error 1603.
[setup] Associate SAP with foobar2000.
[swift] Fix "Fatal error: Negative value is not representable".
[swift] Enable color diagnostics.
[doc] Update for win64 packages.
[shellex] sf feature #16 Handle all registry entries and propdesc registration from DLL (un)registration.
[opencl] Add progress messages.
I still don't understand your preference for regsvr32 over an installer, but here it is: https://asap.sourceforge.net/asap-8.0.0-ALPHA1-win64.zip The Explorer plugin is ASAPShellEx.dll + ASAPShellEx.propdesc which must live next to one another. regsvr32 error 80004005 means no admin priviledges, 80070002 means no propdesc file.
Have 64-bit Windows download as .zip
I still don't understand your preference for regsvr32 over an installer, but here it is: asap.sourceforge.net/asap-8.0.0-ALPHA1-win64.zip The Explorer plugin is ASAPShellEx.dll + ASAPShellEx.propdesc which must live next to one another. regsvr32 error 80004005 means no admin priviledges, 80070002 means no propdesc file.
[opencl] Free resources early.
Revert "[opencl] Refactor with CL_Buffer."
[opencl] Refactor with CL_Buffer.
[opencl] Refactor std::string -> std::vector<char>.
[opencl] Convert in parallel.
[opencl] Convert all subsongs.
C:\jac\system\Windows\Programming\Repositories\RASTER-Music-Tracker\src\asap.c(2813,24): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data system\Windows\Programming\Repositories\RASTER-Music-Tracker\src\asap.c(4448,22): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss o Fixed now.
[fu] sf bug #46 Avoid MSVC warnings.
[wasap] Fix WM_COPYDATA return value per doc.
[wasap] Handle media keys.
Strange. Are the .SAP files in C:\TEMP identical to the source files?
C:\jac\system\Windows\Programming\Repositories\RASTER-Music-Tracker\src\asap.c(2813,24): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data system\Windows\Programming\Repositories\RASTER-Music-Tracker\src\asap.c(4448,22): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss o I will handle these. For now, just don't pass filenames consisting of over two billion characters. ;) C:\jac\system\Windows\Programming\Repositories\RASTER-Music-Tracker\src\asap.c(3991,10):...
That's my preference from the 80s. Single user computer, so TEMP is not somewhere in the user profile, but there. Environment variables are set up like this: TEMP=C:\TEMP TMP=C:\TEMP When I trigger the diff, two .sap files are created there. But they are .SAP files, not text files,
I've added the _CRT_SECURE_NO_WARNINGS; define the project and the "unsafe" warnings are gone. But these two are still there and look valid to me: C:\jac\system\Windows\Programming\Repositories\RASTER-Music-Tracker\src\asap.c(2813,24): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data 1>C:\jac\system\Windows\Programming\Repositories\RASTER-Music-Tracker\src\asap.c(3991,10): warning C4996: 'strdup': The POSIX name for this item is deprecated. Instead, use the...
warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead.
Ok, I fixed some buffer overflows with malicious long filenames. MSVC may still complain about "unsafe" functions, but I don't care.
[wasap] sf bug #46 Fix buffer overflows with very long filenames.
[wasap] Remove UNICODE support.
[doc] Credit the STIMER bug report.
warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead.