Development status, 2016 edition

[Saga Musix]

The new year is now about a month old, and there hasn't been a development update post on the forum in a long while, partly also because it was not necessary most of the time. However, I'm afraid that this year's status update will be very much the opposite of the 2010 status update.
First and foremost, OpenMPT is still alive and will stay so for the forseeable future. However, sadly manx had to leave the development team, which means a fundamental decrease in knowledge as well as commit activity. This decision was made based on real-life circumstances and is not definite; hopefully he will return to the team rather sooner than later. This also means that all features he was working on during the last year will remain unfinished for the forseeable future.
So this means that I'm currently on my own again regarding the OpenMPT project. On my side, I haven't really had a lot of motivation to do great changes to OpenMPT in the last few weeks, but this is slowly returning now, and I am working on some structural changes that are probably going to be important in the future, but will not bring any new features for the time being. OpenMPT 1.26 will appear in April or May most likely, depending on how fast I can progress with what I have in mind for this version.
What will happen after that remains to be seen; I will soon be in my last university at semester and while I definitely want to continue working on OpenMPT after graduation in late 2016, I have no idea how much time and motivation will be left.

While all of this might not sound very good, I'm still excited about what 1.26 will bring and about possible future improvements to OpenMPT that I'm still dreaming about, such as scripting and networking support. Maybe 2016 is the year to make them happen.

Happy tracking, and thanks for using OpenMPT.

[Harbinger]

We are so lucky to have you still with us after all these years. How many others have started and dropped off the dev team, but you still keep trying to make this old software better.
And I understand about motivation. Sometimes you have such good ideas, and then you get sidetracked by other inspirations, and it's hard to go back to a project which you set aside. And yes, we should be worried about your graduation, because soon it'll be about making money, and time will not be so available for open source concerns.

So on that note, and at the risk of coming off as ungrateful, I would like to see you attack the "batch" functions I have requested over the years. These would help me and other old-school composers to transfer what we wrote on paper into the tracker format as easily as possible.
As a case in point, I'm currently working on a symphonic suite, which I notated on paper, and have even entered into Musescore (an open-source score notation application). I'm having a hard time getting motivated to enter it into Modplug because it will take forever to set up all the instruments and channels. This is why I made these Feature Requests:

Ultimate Channel Manager
Sample-Instruments Manager
Last Note view

They would all help me enter and then revise the score to its best realization.
I've waited patiently for you to be inspired to see the good in these ideas, and I know you're capable of implementing these, but like every artist (that's right, you're a "code artist" ), you just need to be inspired to get working on it. So I'm hoping you'll pay attention to these in the near future, as you figure out what you want to work on next...

Other than that, I think we would all be interested in some ideas that have caught your fancy though. Can you tell us what features you're interested in adding? And which you think will be the hardest to implement?

Godspeed in the New Year!;)

[Saga Musix]

So on that note, and at the risk of coming off as ungrateful, I would like to see you attack the "batch" functions I have requested over the years.

My main problem with the first two is that there are better ways of realizing them, but I have no time for those either. An important thing about creating usable interfaces is to not implement what the user tells you but figuring out what they actually need - because most of the time, they don't even know the best solution to their actual problem.

Other than that, I think we would all be interested in some ideas that have caught your fancy though. Can you tell us what features you're interested in adding? And which you think will be the hardest to implement?

The things I really want to see (and which are also hard / a lot of work to implement) are, as already said, modular routing, scripting and networking capabilities. I have drafts and partially working code here and there, but it's still a long way to go. In between those large goals, there are also several smaller ones here and there which might not be directly visible to the user, but are important to me nevertheless - like the recently added support for DigiBooster's Echo DSP in .DBM files, which was finally made possible after some heavy refactoring last week.