You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the only way to copy stuff you created with VMPC2000XL to your MPC2000XL is by only using filenames of length 8.3 or less. Since VMPC2000XL does not enforce 8.3 (it enforces 16.3), this is a big issue for almost any user who is using VMPC2000XL in conjunction with a real 2000XL.
There is currently partial enforcement of 8.3: When VMPC2000XL reads a directory's contents, all files are renamed to 8.3. Therefor any WAV files you load from disk will result in a short sound name, since when you load a WAV, the soundname is derived directly from the filename.
For SNDs, the name is parsed from the contents of the SND file. So this is where 8.3 is not enforced.
When saving individual SND/WAV files, or when saving SND/WAV files indirectly by saving a PGM or APS, the sound's name is used to determine its filename. Sound names can be 16 characters, so this is another case where 8.3 is not enforced.
We propose the following solutions:
A mode in which 8.3 filenames are enforced
Implement an optional true Akai 16.3 FAT filesystem mode
Both solutions require rigorous refinement.
In 1) we have to consider at what stage the 8.3 policy is implemented when this mode is enabled:
On a case-by-case basis. When loading SNDs the data-derived name is automatically truncated to 8.3 or the user is prompted to provide a short name. When recording new sounds, creating new sounds via the TRIM -> Edit screens we could simply impose an 8 character rather than a 16 character limit. Or,
When saving SND, APS or PGM files, names are automatically truncated or the user can optionally get prompted to provide new names. Note that any renames must be taken into account in the PGM and APS soundnames section, and in the SND file's soundname section.
Is a much bigger feature, which was experimentally available in the abandoned Java incarnation of VMPC2000XL (called vMPC at the time). In this issue, we will only address 1) and a separate issue will be created for 2).
The text was updated successfully, but these errors were encountered:
Currently the only way to copy stuff you created with VMPC2000XL to your MPC2000XL is by only using filenames of length 8.3 or less. Since VMPC2000XL does not enforce 8.3 (it enforces 16.3), this is a big issue for almost any user who is using VMPC2000XL in conjunction with a real 2000XL.
There is currently partial enforcement of 8.3: When VMPC2000XL reads a directory's contents, all files are renamed to 8.3. Therefor any WAV files you load from disk will result in a short sound name, since when you load a WAV, the soundname is derived directly from the filename.
For SNDs, the name is parsed from the contents of the SND file. So this is where 8.3 is not enforced.
When saving individual SND/WAV files, or when saving SND/WAV files indirectly by saving a PGM or APS, the sound's name is used to determine its filename. Sound names can be 16 characters, so this is another case where 8.3 is not enforced.
We propose the following solutions:
Both solutions require rigorous refinement.
In 1) we have to consider at what stage the 8.3 policy is implemented when this mode is enabled:
On a case-by-case basis. When loading SNDs the data-derived name is automatically truncated to 8.3 or the user is prompted to provide a short name. When recording new sounds, creating new sounds via the
TRIM
->Edit
screens we could simply impose an 8 character rather than a 16 character limit. Or,When saving SND, APS or PGM files, names are automatically truncated or the user can optionally get prompted to provide new names. Note that any renames must be taken into account in the PGM and APS soundnames section, and in the SND file's soundname section.
The text was updated successfully, but these errors were encountered: