Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - saga

Pages: [1] 2 3 ... 86
XMPlay / Re: Suggestions for 3.9
« on: 13 Jul '17 - 17:08 »
1) Is there a way to get time to read 90:00.0 (minutes-seconds) instead of 1:30:00.0 (hour-minutes-seconds)?
Options & Stuff -> Appearance -> Time (in the lower-right corner) -> Uncheck Hours.

XMPlay / Re: Suggestions for 3.9
« on: 12 Jul '17 - 14:07 »
For S3M files with AdLib instruments (sample type >= 2), XMPlay should probably warn the user that they might be missing parts of the module. For example, the "Format" could be changed from "ScreamTracker 3.20" to "ScreamTracker 3.20 (AdLib)" if such instruments are present.

Here's an update that should do that:
Seems to work just fine, thanks. :)

BASS / Re: Memory v File
« on: 10 Jul '17 - 16:28 »
It depends on a lot of things that you have to answer yourself first:
* Is the increased memory consumption acceptable? It may not sound much on a modern computer but maybe you plan to support handheld devices or old computers, where the difference might be more critical.
* Is the increased load time acceptable? If it takes too long to load initially, your users might become impatient and not play your game.
* What kind of storage systems do you plan to support? For example, if you expect everyone to use an SSD, the effects would be practically loaded within no time. Slow laptop hard drives might be a different story, especially if they go to sleep while there is no I/O access happening for a while.

As an outcome of answering these questions, you could for example come to the conclusion that the most often used effects should be pre-loaded, while rarely-used ones should be loaded on demand. None of this is directly related to BASS, though: You should probably try it yourself to understand your own problem and needs better, preferrably on more than one device.

XMPlay / Re: Suggestions for 3.9
« on: 6 Jul '17 - 14:16 »
For S3M files with AdLib instruments (sample type >= 2), XMPlay should probably warn the user that they might be missing parts of the module. For example, the "Format" could be changed from "ScreamTracker 3.20" to "ScreamTracker 3.20 (AdLib)" if such instruments are present.

BASS / Re: BASS_ATTRIB_VOL internals
« on: 5 Jul '17 - 23:38 »
The precision of the mixer has nothing to do with the precision of the volume control. A 64-bit mixer will still sound good even if your volume control has a lower resolution. The precision of the volume control only expressed how many different levels of setting the volume are, and even with a 32-bit volume control, there are already way more levels than a human ear can distinguish. Anyone trying to convince you of something different is talking audiophile nonsense.

2017-07-02: xmp-openmpt version 0.2-beta25 released!

This is another small update which mostly brings some decoding improvements for a couple of formats:
- PT36: Enable VBlank timing as specified in file and read song comment.
- M15: Loosen heuristics to allow a few more semi-damaged files to play.
- MT2: If there were instruments with both sample and plugin assignments, sample data was not read correctly.

Additionally, beta24 (which I forgot to announce here) fixed the following issues:
- Improvements to seeking: Channel panning was not always updated from instruments / samples when seeking, and out-of-range global volume was not applied correctly in some formats.
- Work-around for reading MIDI macros and plugin settings in some malformed IT files written by old UNMO3 versions.
- Improve tracker detection in IT format.

See for further details.

xmp-openmpt for CPUs with SSE2 instruction set - that's pretty much any x86 CPU made in the last ten years. Any 64-bit CPU automatically supports this.
xmp-openmpt for old CPUs without SSE2 instruction set

xmp-openmpt website:

BASS / Re: How can i know the sound status ?
« on: 19 Jun '17 - 16:26 »
You need to state which language you are working in because working with pointers don't look the same everywhere.

BASS / Re: How can i know the sound status ?
« on: 18 Jun '17 - 21:57 »
Read the documentation for BASS_ChannelGetAttribute. The return value just indicates successs of the attribute retrieval.
You need to supply the variable that should receive the actual value of the attribute as a pointer in the third parameter. Currently you provide a null-pointer there.

XMPlay / Re: Playlist shows empty rows, library borked?
« on: 12 Jun '17 - 22:45 »
Every other plugin I have shows file extensions except those two. Is that.. a problem?
No, it's not a problem and this fact itself is not related to the issue (but of course the plugins may still be responsible for some of the issues, that can never be ruled out).
A plugin can optionally report which file extensions it supports, but XMPlay will try all plugins until it finds one that can decode a file. Neither XMPlay nor most plugins blindly trust file extensions.
The "problem" with Delix in particular is that the player engines it uses for decoding do not really report any file extensions (I think), or the module formats they support do not have a file extension to begin with.

Question - I am using the default buffer size (750ms). Why did you warn against using a very large buffer? Is there any benefit to it?
It effectively means that up to 750ms of already queued-up audio will "get lost" when pausing playback. Of course it's up to you to decide whether that's an issue for you, it might be specially annoying if you just pause playback for a few seconds or so. However, there is probably no reason to use such a huge buffer size these days - even with a buffer of, say, 200ms you should practically never experience dropouts.

XMPlay / Re: Playlist shows empty rows, library borked?
« on: 10 Jun '17 - 17:05 »
I have 32Gb RAM on this box.
That doesn't matter since XMPlay is a 32-bit application. Its memory consumption is capped at either 2GB (without high address aware flag) or 4GB.
Are those screenshots taken while the entries are being added/scanned? As I said it might have been a problem while this was being done, and not when reloading the library afterwards.

Even so, is there any way to just fully force a library refresh/rescan?
Did you try my suggestion with "Refresh info from file"? Are those "empty" playlist entries actually still associated with a file or are they really empty? You can verify this by right-clicking them and choosing "Track info".

I still saw a stack of .SPC files in there despite not having anything that played them anymore.
XMPlay only knows if it can play a file after it has been scanned. If it cannot be played, it will be drawn with a strike-through line. Until the scan is completed, the file just remains "potentially playable".

Anyway, at this point it's probably only Ian who can give any further recommendations

XMPlay / Re: Playlist shows empty rows, library borked?
« on: 10 Jun '17 - 13:58 »
Just to be sure, maybe check XMPlay's memory usage while adding/scanning the files. 190,000 files doesn't sound like it should be a problem for XMPlay itself but maybe some memory is being leaked (e.g. by plugins) and it eventually fails to allocate memory for all playlist entries.
For refreshing, have you tried "Refresh info from file" when right-clicking a playlist entry (or a selection of entries)?

BASS / Re: MOD Instrument callback? DELPHI
« on: 1 Jun '17 - 22:52 »
See the documentation BASS_ChannelSetSync. You probably want to sync on BASS_SYNC_MUSICINST.

XMPlay / Re: Suggestions for 3.9
« on: 1 Jun '17 - 14:01 »
For the next package update, it would be great to include all of the "official" un4seen input plugins. This will offer a better out-of-the-box experience for everyone just getting into the software, and if someone really needs to get rid of unused plugins, they can still delete them. After all, xmp-wma is still shipped with the player by default even though it's probably not used that much nowadays (and I'd rather have XMPlay ship with xmp-flac than xmp-wma, but maybe that's just me ;D), so could just as well put a few more plugins into the package.
Given the tiny size of those plugins, it would hardly bloat the distribution, and still load very quickly.

XMPlay / Re: Title encoding
« on: 1 Jun '17 - 12:41 »
As long as the files don't use old ID3v1 tags (but rather ID3v2 tags), the encoding of the titles should be well-defined and XMPlay should have no problem displaying them correctly. Have you tried verifying that the titles are actually stored correctly by e.g. opening the same file in MP3Tag?

XMPlay / Re: Title encoding
« on: 28 May '17 - 14:08 »
What format are those songs in? Some audio formats do not deffine the encoding that is used to save text metadata, but many others do, so it should not matter what locale your system uses. You can also edit wrongly formatted track titles in the XMPlay library.

XMPlay / Re: 3.8 reports, queries and bugs
« on: 20 May '17 - 16:40 »
Attached is a very simple MOD... apparently too simple for the auto-normalization! ;D
Using pretty much normal MOD playback settings (with 50:50 pan sep), the playback is distorted on the left channel.

Not trying to be funny, but realistic:
Have you seen Rubberband being added to BASS_FX in the last 2.5 years? No, so most likely no work has been done.
Would it take a lot of time to integrate yourself? No, the Rubberband API is not complicated. Getting audio out of the BASS mixer and feeding it into the processing function of Rubberband (after a bit of API setup) and then putting it back into BASS won't be a lot of code to write, while you make it sound like it would be a terribly complex job. There is a full example (the Rubberband command-line tool) demonstrating large parts of the API. It may look like a lot of code at first but you can probably ignore most as you will most likely only use a fraction of the API.

Well, noone has apparently done it before, so you could be the one to implement it and then publish your results so that other people don't have to do it again. ;)

You could... just use Rubberband? It's not like it's impossible to use without an official BASS add-on.

MO3 / Re: Old UNMO3 IT header issues
« on: 5 May '17 - 16:56 »
Okay, I think with this information I can now build fairly reliable fingerprinting of IT files saved with UNMO3, and automatically fix IT files saved with UNMO3 older than ("stuff" update from January 2011). They are probably rare but they do exist here and there.

For anyone else trying to identify IT files saved with UNMO3, here's the fingerprint (feel free to correct if anything is wrong :)):
- cwtv and cmwt are both 0x0214
- row highlights are both 0
- pwd is 0
- reserved is 0
- MIDI pitch controller and MIDI config flags are never set
- edit history has a length of 0

The only applications I am aware of that are similar to this fingerprint are:
- CheeseTracker, but it always seems to write non-zero row highlights
- IT 2.14 without any patches, but it always writes a non-empty edit history (and is unlikely to write a reserved value of 0)

In addition to this fingerprint, for detecting old (broken) UNMO3 versions:
- If instrument mode is disabled but 4*smpNum zero bytes follow after the pattern parapointers, an UNMO3 version older than was used.
- If only the "message" extra bit is set and two zero bytes are read after the parapointers, an UNMO3 version older than was used.

MO3 / Re: Old UNMO3 IT header issues
« on: 5 May '17 - 14:18 »
Looking at various UNMO3-ed files, the difference does not seem to come from different UNMO3 version, but probably from different module settings.
Using UNMO3 2.4 from April 2008, I do not see those four extra bytes (i.e. only two zero bytes in front of the FX00 chunk) when converting codename_silver.mo3 to IT, but they are present when decoding the two MO3 files found in the attachment (the decoded IT files are also in the archive for convenience).

EDIT: I think I figured it out! Even in sample mode, UNMO3 2.4 from 2008 seems to reserve some space for instrument parapointers in the header (as many as there are samples). This is where the extra four zeros come from. It doesn't actually write out any instrument parapointers, so there are 4 * smpNum zero bytes after the pattern parapointers. Since Codename Silver is in instrument mode, I cannot see the extra bytes there.
Having written my own MO3 decoder I can somehow see where this is coming from (the MO3 file still contains instrument headers for each sample), but if you still have the source code for that old version, it would be good if you can confirm that this is indeed what UNMO3 was doing wrong.

MO3 / Old UNMO3 IT header issues
« on: 5 May '17 - 00:29 »
This is kind of a follow-up to a thread from a few years back...

What I observed back then: UNMO3, at the time, wrote the number of edit history entries (which was 0, since it didn't write an actual edit history), even though the "embed edit history" special flag 0x02 was not set. The only data following the edit history are MIDI macros (Edit: and possible MPT extensions), so this is only relevant when the original file contained any non-standard macros or plugin stuff (which would then not be read correctly).

I no longer have this specific version of UNMO3, so I tried to reproduce this with an older version from April 2008, and - surprise! - that older version writes the "embed edit history" flag, and it writes 6 extra zero bytes before the MIDI macros! Given the low number of IT files that have non-standard MIDI macros, combined with the low number of IT files that have been uncompressed using UNMO3, I am not entirely sure if this would be worth a workaround, but it surely could be used for fingerprinting such files as UNMO3-made files.

So, now for the interesting part: When did this behaviour change from writing those extra bytes and the edit history flags to writing a few less extra bytes and not setting the history flag? Can you dig up an UNMO3 version from between 2008 and 2011 that would show the behaviour from my original post? Do you still have the old source code that could possibly explain why UNMO3 wrote those 6 (or 4, depending on how you look at it) extra bytes?

BASS / Re: ASIO device list
« on: 2 May '17 - 21:11 »
Audacity does not actually ship with an ASIO interface (it would violate its GPL license). This would mean that your user compiled Audacity by themselves. This is naturally something that only very few users do, so something seems fishy here. You should probably ask them if they are really 100% positive that they use an ASIO driver in Audacity or if it's actually a different driver they're using.

XMPlay / Re: adjusting playback speed of a MOD
« on: 30 Apr '17 - 20:22 »
The built-in module player cannot do this, but xmp-openmpt features four user-assignable shortcuts to increase and decrease the tempo and pitch of a module independently from each other, just like in the old ModPlug Player. To make the plugin play those module types that are normally handled by XMPlay, you have to add their file extensions to the "priority file types" list for that plugin (The full list would be: mod xm s3m it mtm umx mptm).

Pages: [1] 2 3 ... 86