Recent posts

#21

Development Corner / Re: OpenMpt accessibility disc...

Last post by Saga Musix - July 04, 2025, 18:44:21

Another example is in the pattern editor if Ctrl+Shift+Tab is pushed to move to the other view with the order list and then via pushing Shift+Tab to move to the pattern toolbar, you'll be able to move rite to a checkbox for example the VU-Meters. If you'll uncheck it via SpaceBar you'll note that you're back in the pattern view, and if you want to rechek the box you'll have to go back to the toolbar to do so.
In this event the controls aren't being properly respected, as checking a box or entering an option shouldn't push you from the pattern controls, as user may want to change other options before properly exiting the controls via the escape key or Ctrl+Shift+Tab.

I think I now have a workaround that should make everyone happy. Depending on whether the last received input event is a keyboard or mouse event, interactions with controls in the "upper" editor now won't return the focus to the "lower" editor. So for mouse users everything should stay as it was before, and if a button was activated through the keyboard, the focus will stay on that button. This will also end up in the next OpenMPT release.

#22

Development Corner / Re: OpenMpt accessibility disc...

Last post by Saga Musix - July 04, 2025, 17:13:54

The only problem regarding the keyboard is in certain controls like the keyboard list, where the control state isn't properly respected, for example in the list after the category combo box the list doesn't display the first option unless the user presses down once or twice, so it makes it look like the options aren't before the user.

Whoops, it looks like there is a bug with the list item selection; by default the first command should be chosen from the list but it currently isn't. This will be fixed in the next release.

Another example is in the pattern editor if Ctrl+Shift+Tab is pushed to move to the other view with the order list and then via pushing Shift+Tab to move to the pattern toolbar, you'll be able to move rite to a checkbox for example the VU-Meters. If you'll uncheck it via SpaceBar you'll note that you're back in the pattern view, and if you want to rechek the box you'll have to go back to the toolbar to do so.
In this event the controls aren't being properly respected, as checking a box or entering an option shouldn't push you from the pattern controls, as user may want to change other options before properly exiting the controls via the escape key or Ctrl+Shift+Tab.

This is an unfortunate clash between usability with the mouse and accessibility. It is impossible to tell whether a checkbox or button was clicked with the mouse or activated by a keypress, and in this case OpenMPT favors the use of the mouse and immediately returns the focus to the pattern editor, because this is what mouse users would typically expect.
Unfortunately we never found a good solution for that which would work both for mouse users and keyboard users. However, I suppose that for most users that rely on keyboard navigation, assigning these actions to a keyboard shortcut would make much more sense than following through a long tab chain every time they want to toggle those options.

Edit: I believe that I might have a workable solution for this. I will work on this.
 

I'm trying to close the issue, but I get this message.
"APPLICATION ERROR #24
Resolution "fixed" is not allowed for status "new"."

I closed it now. MantisBT is a bit clunky in that regard, you always need to provide a status and resolution, and they need to be consistent. An issue cannot be both new and fixed at the same time, the status needs to be either "closed" or "resolved" in order for the resolution to be "fixed".

#23

Development Corner / Re: ByteBeat as sample/instrum...

Last post by Saga Musix - July 04, 2025, 17:04:57

Adding the OpenMPT playback engine to any project already adds 1 to 2 megabytes (depending on the platform and exact configuration) to that project, which kind of makes the usage of bytebeats completely moot. Ironically, adding an interpreter for a bytebeat language would increase that size even further.

OpenMPT is the wrong tool for this.

#24

Help and Questions / Re: Virus alert in v1.32.01

Last post by Saga Musix - July 04, 2025, 17:02:21

Good to hear that it's gone with the latest version. Malware detection is a completely intransparent process that involves tons of heuristics. To be honest it's outrageous that the difference in having a code-signing certificate attached to an executable or not changes a program from supposedly being some random nondescript trojan to being 100% clean with many virus scanners. And even when we do sign our executables, there's still random generic detections going off every now and then. The whole anti-malware industry is a giant shitshow to be honest, and as mentioned in previous threads about the same topic we as OpenMPT developers simply do not have the time and resources to constantly fight against these mis-detections (I'm sure you would rather prefer me spending an hour on improving OpenMPT rather than spending an hour sending emails to random companies after every release and then hoping something about their detection heuristics changes).
This is where you, the community, can help us, by reporting these false positives to your antivirus vendor. I hope it's obvious to you that I would never put my codesigning certificate, which is bound to my name, on an application containing malware. If you download a signed exectuable from openmpt.org, you can be confident it's safe and any malware detection is a false positive.

#25

Development Corner / ByteBeat as sample/instrument

Last post by Alikberov - July 04, 2025, 16:00:02

May be now is time (old request) to use ByteBeat formulas as any sample (integrated is engine/player)?
This is way to the new features with complex sounds and tiny size.

• Pre-rendered samples before play
• Real-time sampling with more features

Respect.

#26

Help and Questions / Re: Virus alert in v1.32.01

Last post by Helix751 - July 04, 2025, 12:48:18

Thanks for replying anyway.

Whatever the cause of the false positive issue was, it got fixed in the 1.32.02 update.

#27

Help and Questions / Re: Sample Volume is lower in ...

Last post by Saga Musix - July 04, 2025, 11:01:39

Yeah I was just going to suggest that you may have toggled that setting.

(Still no idea why Vol is listed as "40" in the image above though!)

The thing you pointed out in the status bar is the channel volume, which is expressed in hexadecimal (64 decimal = 40 hexadecimal), because it represents the parameter of the Mxx command, and parameters of the effect column are always expressed in hex.

#28

Help and Questions / Re: Sample Volume is lower in ...

Last post by leonard - July 04, 2025, 10:56:08

Oh, I think I've figured it out!
I seem to have disabled the "No loud sample preview" option in the setup general tab.
Enabling it again synced up the volume between all the different pages. 
Sorry for the trouble, but thank you for letting me bounce the problem here while going through it!
(Still no idea why Vol is listed as "40" in the image above though!)

#29

Help and Questions / Re: Sample Volume is lower in ...

Last post by leonard - July 04, 2025, 10:35:15

Hey, thank you for the welcome and advice! 
I checked and made sure there was a v64 command next to my note, but it still sounds lower than it did in the sample editor (and it sounds lower in the instruments tab as well).
I did notice a small line of text at the bottom that I think implies the channel volume may be only at 40, though. I wonder if this is the issue? But when I check the channel settings in both the general tab and the channel itself, it does say it's set to 64.


Perhaps I accidentally messed with some presets somewhere?
I'll attach the IT. file in case it could be of use. Really appreciate the help!

https://mega.nz/file/llFSjZJJ#grGNkz8SMo6qXOuCfbBtwNaYJAWnKuAnj6FWw89ayK8

#30

Help and Questions / Re: Sample Volume is lower in ...

Last post by Saga Musix - July 04, 2025, 10:11:53

Welcome to the forums!
When you preview a sample in the sample editor, it is always played with the maximum volume (as if there was a v64 command next to a note in the pattern). In the instrument and pattern editor, the sample is played at its default volume instead. So it sounds like you have specified a default volume for your sample which is lower than 64. If this wasn't intentional, you can change it to 64 and it will sound the same when previewed anywhere.