Recent posts

#41

Development Corner / Re: Any plans adding buffers f...

Last post by manx - November 05, 2024, 09:12:53

I already asked about 5 years ago, if there any plans to add buffers for each channel so we tracker player programmers could finally add cool visualisation stuff (like oscilloscopes) when using libopenmpt.
This ticket here is from 2017 and it´s still marked as new:
https://bugs.openmpt.org/view.php?id=1042

It's still planned, but (at least for me) somewhat low priority at the moment.

Any relevant updates will be discussed in the issue you linked.

I don´t know the internals of the library, but could it be possible to add this feature without changing the current mixing routines? Just some kind of extra data, which could be added additionally. It would be enough to add the first 100-200 bytes of each channel into a new bufferlist or something like that.

In addition to forcing a somewhat slower rendering path (because we currently render and mix a channel at the same time, if no plugins are involved, using separate buffers will significantly increase cache pressure and hurt older systems), the most difficult thing is designing the API, for the reasons outlined in the issue: channels can be grouped and routed through plugins, so the waveform per channel will not be what is finally be heard from that channel, and the waveform per-plugin might contain multiple channels. It's also difficult to design the API somewhat future prove regarding even more complex audio routing graphs which might get added sometime.

I would prefer to move further discussion to the issue tracker.

#42

General Chatter / Re: why are mid sized open sou...

Last post by manx - November 05, 2024, 08:51:30

I was here offering my design services and being shot down... yes I was just one designer and frankly being shat on for the general UI improvements pretty much entirely focused on ease of use has made me fuck right off.

Can you provide an example link?

And frankly your qualifications towards design are irrelevant.

Why? Why is yours or anyone elses not? This makes no sense.

Your focus is programming, and has been for long enough to take your focus away from art.

Wrong. Do not make assumptions about me.
Also, I would really not consider user interface design an art at all. It's more engineering and craftsmanship. I agree that graphics design is art, but that is really not what is lacking in OpenMPT, IMHO.

I have music and art, I take my inspirations for those from all around me, games, movies, television, etc - the inspirations for these things are conveniently clustered... both are pure creation and aesthetics. You have at least programming on top of that which depending on the languages you have delved into could be infinitely massive with rabbit holes of information.

Similarly you supposedly have design on top of that. There is a really big difference between experiencing design and being able to create design. The latter is also "on top" of the former.

So dont even pretend that spending an afternoon, a month, a year, even a decade playing around in graphic software can make you compare to a graphic designer who has devoted his / her entire life and career to it.

Again, you are making assumptions about me which are outright wrong. Just stop doing that, it really does not support your argument at all.

Also, to make things absolutely clear here: I was never talking about graphic design at all here. This is not something that OpenMPT needs, frankly at all. There are 3.5 distinct assets that even require it at all in OpenMPT: Application Icon, File Icon, Project Logo, and maybe the styling of the pattern view (however, see https://bugs.openmpt.org/view.php?id=1114 - that code is an utter mess of spaghetti code at the moment).
What OpenMPT likely needs is user interface design. However, given the UI toolkit that OpenMPT currently uses (MFC), and the way user interface code is still deeply interlocked with logic code in our code base, a user interface designer alone will never be able to do any user interface design work on OpenMPT in its current form. It would require at least an additional dedicated user interface programmer to even be able to implement any user interface changes at all. Decoupling the application logic from user interface code is something that I have been working on constantly since starting working on OpenMPT - because it is a necessary precondition to even be able to attack some user interface problems in the first place - because I always knew it was necessary - and it's a very slow process.

It stands to reason that any designer volunteering time to help with this project will have at least a divided attention between music making and designing. The focus and obsession in OMPT is obviously functionality, and that is great, but it needs some people to join the team who are listened to and not brushed off who are obsessed with and focus almost exclusively on the design and user experience

As just explained, purely focusing on design will not be able to work with the current OpenMPT code base. It will inevitably require the existing programmers to devote time to implement such changes, in a code base where this takes more time than it would take in a cleaner code base. The code base needs to get cleaned up further nonetheless anyway though. So, implementing big user interface design changes NOW, results in double the work. Given how small the OpenMPT project is, investing double the time is not something that makes all too much sense, IMHO. The current user interface design and code is somewhat of a dead end, and we have been knowing that for years (see https://bugs.openmpt.org/view.php?id=783 and related issues for discussion of some aspects of that). Investing significant amounts of time into the current interface to improve it would stall other development in OpenMPT and libopenmpt, and probably also burn out people who have to implement the changes. That is maybe something a pure design-only person will have difficulties to understand, but that is frankly just the situation of the current user interface code.

which would take some severe restructuring of how things on this collection of websites, specifically the issue tracker.

We have been bitten by big hosters failing more than once in the past, which significantly slowed down development for a couple of weeks, which is why we probably will continue to host our own services. Changing that, even if only migrating to the big ones, would require a lot of administrative work for migrating existing information.

Your opinion on the usefulness of my criticisms here are also irrelevant. These are things that need to be said, over and over again, because the message is never received and crucially acted upon.

My opinion is kind of important because I am 1 of the 2 maintainers of OpenMPT and libopenmpt. If you cannot convince me and keep repeating wrong statements, you are wasting our time, and thereby actively hurting the project.
Please at least try to be constructive.

#43

General Chatter / Re: why are mid sized open sou...

Last post by n0cturn - November 05, 2024, 08:32:57

I think your communication skills need a little work. Being confrontational NEVER gets the results you want.

#44

General Chatter / Re: why are mid sized open sou...

Last post by Exhale - November 05, 2024, 07:01:46

I guess you should reconsider your assessment of our qualification. You frankly do not know our education and background, so please stop assuming things and accusing us of random things. You are not constructive AT ALL here.

You are saying OpenMPT needs a "design team" (quite a claim for a currently 2 person project), yet you provide no suggestion at all on how to get one. And you also offer no alternative. What's your point, really? We already know that the OpenMPT user interface can be improved in various aspect. Rambling around and reiterating that fact is not exactly helpful.

I was here offering my design services and being shot down... yes I was just one designer and frankly being shat on for the general UI improvements pretty much entirely focused on ease of use has made me fuck right off. 2 volunteer designers who love the software for what it does but have clear ideas of where it could go is all that would be needed to steer the design language of this project.
And frankly your qualifications towards design are irrelevant.
Your focus is programming, and has been for long enough to take your focus away from art. That is the reality of the homage jack of all traits and master of none... the more you divide your time among other focuses the less qualified you are for the ones you have.
I have music and art, I take my inspirations for those from all around me, games, movies, television, etc - the inspirations for these things are conveniently clustered... both are pure creation and aesthetics. You have at least programming on top of that which depending on the languages you have delved into could be infinitely massive with rabbit holes of information. And that is not counting the real life stuff we both do - all of which steer our minds away from our capacity with our primary qualifications.
Scientifically none of us can multitask - this is fact. It is always divided attention.
So dont even pretend that spending an afternoon, a month, a year, even a decade playing around in graphic software can make you compare to a graphic designer who has devoted his / her entire life and career to it.

EDIT :
So yes, all our attention is divided, thus it is entirely about obsession. It stands to reason that any designer volunteering time to help with this project will have at least a divided attention between music making and designing. The focus and obsession in OMPT is obviously functionality, and that is great, but it needs some people to join the team who are listened to and not brushed off who are obsessed with and focus almost exclusively on the design and user experience - which would take some severe restructuring of how things on this collection of websites, specifically the issue tracker.

Your opinion on the usefulness of my criticisms here are also irrelevant. These are things that need to be said, over and over again, because the message is never received and crucially acted upon.

#45

Help and Questions / Re: Cannot download from Firef...

Last post by acrouzet - November 05, 2024, 00:34:26

Looks like it could be a problem with my ISP? "Advanced" shows the following text:

Code Select Expand

Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for download.openmpt.org. The certificate is only valid for low-xdns.xfinity.com.
 
Error code: SSL_ERROR_BAD_CERT_DOMAIN

I tried clicking the link with a VPN on, and it downloads.

#46

Development Corner / Any plans adding buffers for e...

Last post by bass - November 04, 2024, 21:21:53

I already asked about 5 years ago, if there any plans to add buffers for each channel so we tracker player programmers could finally add cool visualisation stuff (like oscilloscopes) when using libopenmpt.
This ticket here is from 2017 and it´s still marked as new:
https://bugs.openmpt.org/view.php?id=1042

I don´t know the internals of the library, but could it be possible to add this feature without changing the current mixing routines? Just some kind of extra data, which could be added additionally. It would be enough to add the first 100-200 bytes of each channel into a new bufferlist or something like that.
Are there any plans? The only reason I don't use libopenmpt is the lack of this feature. So I´m still waiting for this :-(
Thx!

#47

Help and Questions / Re: Cannot download from Firef...

Last post by Saga Musix - November 04, 2024, 19:32:14

I am able to connect to https://download.openmpt.org/ with Firefox just fine here. The fact that you were able to connect to the main website and this forum shows that it might have just been a temporary hiccup, but if the problem persists, please press the "Advanced..." button and take a screenshot of the additional information presented there. Also click on the "Show certificate" button you should be seeing there, and take a screenshot of that as well.

#48

Help and Questions / Cannot download from Firefox.

Last post by acrouzet - November 04, 2024, 19:02:21

Trying to go to the main stable release download link on the site results in this warning from Firefox:

Any ideas on how to possibly fix/bypass this?

#49

General Chatter / Re: why are mid sized open sou...

Last post by manx - November 04, 2024, 15:35:28

I guess you should reconsider your assessment of our qualification. You frankly do not know our education and background, so please stop assuming things and accusing us of random things. You are not constructive AT ALL here.

You are saying OpenMPT needs a "design team" (quite a claim for a currently 2 person project), yet you provide no suggestion at all on how to get one. And you also offer no alternative. What's your point, really? We already know that the OpenMPT user interface can be improved in various aspect. Rambling around and reiterating that fact is not exactly helpful.

#50

General Chatter / Re: why are mid sized open sou...

Last post by Exhale - November 04, 2024, 15:17:41

Do you have anything tangible to propose here, or is this just you rambling around?


There is no razor-sharp distinction between user interface design and programming as you might make it sound. OpenMPT is a very old code base, and a lot of ancient (and arguably bad) user interface design decisions cannot "just be changed" at the blink of an eye, but are baked in deeply into the code structure. At places this requires a lot of programming work (we are talking months here) to even be changeable at all. We are fully aware that there are areas where the user interface can be improved, but it is always a tradeoff between that, and working on other aspects of OpenMPT/libopenmpt (or even other projects). We do not have infinite time.
And frankly, exactly this trap of baked-in interface design decisions can arguably be seen rather well in Photoshop and Premiere, IMHO. They also keep ancient decisions, even if they are objectively bad under some criteria.

In the past ~12 years that I have been working on OpenMPT and libopenmpt, we were only once approached by a designer (and a graphics designer at that, not a user interface designer), who did re-design the OpenMPT logo. As far as I can tell, we neither alienated them, nor any other designers, as you make it sound.

"Just add a huge team of user interface designers" does not "just work". We cannot just conjure them out of thin air; and we also cannot buy them.

I am saying OMPT needs a design team, every project needs one. And the purely design focused team needs to be listened to very carefully. Preferably qualified designers.

oh and just because you decree their is no "razor sharp distinction" doesnt make it so.
Yes some programmers dip their feet into design, yes, some designers dip their feet into programming. I dipped a toe myself. But I am still a distinctly design minded person and I could only go so far in programming before my eyes began to glaze over and I no longer understood. From the other side the problem is worse because you can THINK you understand a design concept without actually having any idea what you are talking about.
The dunning kruger is strong when it comes to programmers who think they can fucking design.
Yes... I am on a rant here.
Yes... I have bloody good reasons to be - connected to this project specifically and in plenty of other world interactions.
and YES I am being blunt and giving this project the bloody medicine it needs to ingest eventually. If not today, tomorrow, or long after I am dead, then one day I can only hope that OMPT wakes up to what it is doing to its users from the design side.

The overlap is that the designers and programmers have to work closely together... the moment the programmers expect the designers to become programmers, or think they can do the design work themselves you get the problem the majority of open source programs have, the one ompt sits in too.