Recent Posts

Pages: [1] 2 3 ... 10

I use Celemony Melodyne to analyze an aeolian harp sample. You get to see and hear the result of their "direct note access" though an aeolian harp sample is a special case since most of what you hear are harmonics of the note the string is tuned to. You may find it an interesting exercise, I did so I thought I'd share.
Added OpenMPT build variant comparison table to the original post.
Since r6999 (that number was pure coincidence :D) (2016-08-27, OpenMPT, OpenMPT and libopenmpt test builds are now made with VS2015.
Free Music Downloads / Re: Elephant in a Toaster - chiptune from Evoke 2016
« Last post by LPChip on August 26, 2016, 10:38:54 »
Oh, never thought about the mod limitations. Good point.
Free Music Downloads / Re: [Trance] Sunrise Express (mptm/ogg)
« Last post by Saga Musix on August 26, 2016, 10:17:03 »
I opened the program (OpenMPT) and preceded to find the plugins from their
Yeah, some of the plugins are no longer available from their original creators so the links on KvR are often dead.
Free Music Downloads / Re: Elephant in a Toaster - chiptune from Evoke 2016
« Last post by Saga Musix on August 26, 2016, 10:16:18 »
Tuning your samples never is difficult.
Yes it is, when you have to deal with the MOD format where loop start and loop end have to be divisible by two, you are constrained to a middle-C frequency of ~8kHz, have to use octaves 4 though 6 and thus have to use very short loops for chip samples.
Free Music Downloads / Re: Elephant in a Toaster - chiptune from Evoke 2016
« Last post by LPChip on August 25, 2016, 23:06:57 »
I actually thought I did :)

We'll see, maybe I will fix it later, but working with these samples is very difficult.

Tuning your samples never is difficult. Just make sure you have a perfect sine/triangle or square and tune all against that specific sine. Even the complex samples will resonate against a sine until you find the perfect center.
I actually thought I did :)

We'll see, maybe I will fix it later, but working with these samples is very difficult.
Just to add some more perspective to manx' post: Win32s (the 32-bit extension to Windows 3.11) support (if it ever worked, that is, I have no way to verify) and Windows 95 support were dropped probably as soon as OpenMPT was open-sourced, which was merely 9-10 years after Windows 95 was released. Nobody complained back then. Now we are dropping Windows 98 support sixteen years after it has been released, and so far the only persons complaining are people who do not actively use Windows 98. If you want to use a severely outdated operating system, then you will have to accept that you will have to use outdated software at some point too. There is almost no software being made today that still runs on Windows 98, and OpenMPT was one of very few exceptions to that - which was nice while it lasted, but it no longer makes sense to put a huge amount of effort into it.
As I said on the issue tracker, this is 2016, not 2006 - while in 2006 there were still plenty of Windows 98 users (I myself switched from 98 to XP as my main operating system in that year), today this number is practically zero, except for some retro-computing enthusiasts. I'm not claiming that there are no "real" users on those systems, but reality just shows that even without perfectly accurate statistics this number is still way lower than 1%.

Just do me a favor: make sure the last one I can use is as stable as can be gotten.
This is the case for every version, and then a year later I have a huge bug list of what was broken in the previous version. The only way to provide the most stable version ever is to wait ten years before releasing it and then only fixing bugs (not adding new features) during those ten years.

So even though you'll have to drop support because the rest of the world is at Windows 2020, I can still get my compositions done while I stay on XP.
And nobody will stop you from using whatever the last version to support Windows XP is going to be. Unless of course you want to pay me a yearly salary to keep sure that there will be a usable, up-to-date version for whatever outdated operating system - the demands go both ways, not only from user to developer.
You will have to understand that if you want to go with the times (i.e. use the latest and greatest software), then ultimately, you cannot just go with the times in one case and stay in the past in another case - it's either both or none.

Oh, and if someone is really interested in getting OpenMPT and some other software to run on Windows 98, they can always look into extending KernelEx - but even the developer of KernelEx seems to have lost interest in this project years ago, probably also because there was no real use for it anymore.

Just call it what it is: it's inconvenient for you and YOU want to stay with the latest builder.
If we just wanted to use the latest fad, we'd rewrite OpenMPT in pure JavaScript instead of C++11. ;) We're not even targetting the latest C++ standard, which would be C++14 and would remove support for even more compilers (but wouldn't make a difference in supported operating systems for OpenMPT, only for libopenmpt it would actually matter). OpenMPT/libopenmpt is a very extensive spare-time project for both manx and me, and as such everything that can help relieving unnecessary burden from us will help bringing OpenMPT forward.
As I've mentioned elsewhere, I came to Modplug on Windows 98 which was actually being emulated on my Mac 8.1 with VirtualPC. This was back in 2005. In 2008 I switched from Apple to Windows XP because of the sheer amount of software available (as a matter of fact, there's a world of good software I'm still finding). I still have the same computer and I have no intention of moving up from XP, because it does enough, and I don't wish to be on the internet at home.

The reason I respond to this thread with serious concern is that one day, probably sooner than I'd like, I will also be on this list of ModPlug moving away from me because I see no need to stay with the latest-and-greatest OS.

As already stated in the issue tracker, we have no intention at all to remove Windows XP support anytime soon.

Just do me a favor: make sure the last one I can use is as stable as can be gotten. So even though you'll have to drop support because the rest of the world is at Windows 2020, I can still get my compositions done while I stay on XP.  8)

This decision would have to be made when, in some speculative future time, dropping Windwos XP support would actually be on the table. Whether that would be feasable could depend on a whole lot of things, none of which anyone can predict right now.
With respect to the current case, we do not have any intention to continue providing further bug fixes for OpenMPT 1.26 once 1.27 is released.

One other thing: I wouldn't believe your magical update system — there are a lot of people who don't let you know what computer they're using, all for their own reasons. You have ZERO way of determining or even speculating how many computers are actually using ModPlug, and because of lack of accountability as well as randomity, Statistical Analysis is useless. It's the same problem with the internet as a whole — you don't know what's on the other end of the feed.

You are correct that we cannot reliably estimate the total number of OpenMPT users or their respective frequency of use.
However, in order to make any descision whatsoever at all, we must base that decision on the best available data that we have. Otherwise it would just be guessing everything.
You are guessing that the percentage of users not using the update mechanism is bigger on older systems than on newer systems. I do not question that, in fact I am expecting the same thing.
That question could be answered by collecting browser statistics on the download page (and mapping them to system versions), and correlating those with the statistics we see in OpenMPT installations using the update checker. However, as far as I know (Saga Musix may correct me on this), we are not collecting these.
I'm not even sure if we are collecting download count statistics at all. However, even if we did, this would not allow us to correlate this number to the percentage of users not enabling the update checker, because people might download OpenMPT from download sites other than itself. Downloading OpenMPT from other sites is totally fine by the OpenMPT license and we can neither actually change or prohibit that, nor do we want to do that.
Thus, we are left with what we have available, which is the count of OpenMPT installations having enabled the update checker as well as anonymous statistics (which both are enabled by default for new installs). In addition to the system statistics we gather when anonymous statistics are enabled by the user, we also get to know the version and build variant that does the update check (even without anonymous statistics, as this part is essential to the way the update check is currently implemented (and has been in the past)). Thus we can somewhat estimate whether users of the Win32old build variant tend to be more reluctant to enabling statistics. We are not seeing that - in fact it's the opposite if I am reading the numbers correctly. However that may also be due to old versions which did not make a distinction between Win32 and Win32old.
Anyway, if we do not want to trust the numbers that we are collecting, we could turn to other published statistics about desktop operating system use. Wikipedia has a whole article about these at Leaving aside what these statistics actually measure as well as their precise methodology, they also show that even Windows 2000 fell below 0.1% share more than 5 years ago.
Since I have been working on OpenMPT (which is about 3.5 years by now, I think), as far as I can remember, there has not been even a single bug report from any user on Windows 98 SE, Windows ME or Windows 2000, or any other indication at all that we have any actual users on these systems. OpenMPT was even broken and did not run at all for about half a year because we had missed that an UnRAR update had broken OpenMPT on these systems - again, noone complained at all.
I cannot imagine any stronger indication that we could require to back up our decision than the indications we have collected so far.
Frankly, even if we did see users on 98, ME or 2000, in my opinion the benefits of dropping pre Windows XP support would still outweight the harm done to users on these systems. I cannot tell where the turning point would be, but that question is simply nothing to think about currently, as we have the strongest indication possible of having no users on these systems.

Your other reasons for letting go of the older-OS users may be valid, but it's not because of how many end-users are using what OS. Just call it what it is: it's inconvenient for you and YOU want to stay with the latest builder.  >:(

Let me change the perspective here a bit. You are an OpenMPT user and want the OpenMPT developers to continue supporting OpenMPT on outdated systems. However, as current development tools do not allow targeting the outdated systems, the developers are forced to use outdated development tools which are not supported anymore and do not even run on modern systems at all, which means the developers are even forced to use outdated systems themselves.
OpenMPT users deserve to get the (questionable, in my opinion) benefits of old systems support but developers must suffer because they must stay with outdated systems themselves? I honestly do not think that expectation can be called fair by any reasonable measure. (Being forced to use C++98 instead of C++11 in 2016 could be compared to having to do mixing and arranging your music with 4 track tape machines instead of a DAW or tracker, let alone constantly having to repair the tape because it constantly tends to fructure and catch fire in surprising ways (akin to working around bugs in old compilers and systems) - the analogy is probably bad in a lot of aspects, but I tried to find something in the audio field)

I think you are also missing another important point: Supporting old systems is not only inconvenient for us developers but also for the users. As already stated before, we once again ran into a bug in Visual Studio 2008 while implementing a new feature. Now, I could myself take the burden and, even though I have the strongest possible indication that noone would care anyway, try working around the problem and determine why this ancient compiler just crashes, wasting an unknown amount of hours in the process which would be lost from other work on OpenMPT; - or I could simply remove that feature again and thereby hinder progress and hurt all other users on modern system; - or, we could finally remove the cumbersome support for outdated platforms just as planned. This isn't just some theoretical hypothetical situation - it's the situation right now.

As long as you allow users to open files of any age, which you've stated is your mission, I think your justifications are valid. ;)

Sure, that will not change of course. It's even more important for libopenmpt (and the primary goal of libopenmpt) than it is for OpenMPT itself (not saying that it's not important for OpenMPT also).
Pages: [1] 2 3 ... 10