Main Menu

Recent posts

#1
Quote from: Saga Musix on Today at 10:26:54But this won't be a realtime generator or anything like that, it simply creates a normal sample which is then saved to you module file.
Yes, I thinking about this too, when "shaded patterns" (abandoned unused patterns) using as pre-rendered samples (right click for context menu over pattern and item "render to sample", as example): In this case we can make rhythmics without periodical notes in each pattern in order, but with using one sample at the start of each pattern. 8)

P.S.: I'm not musician, but with my hobby (programming) I thinking in the "program pattern", when I need for amazing sound or melody for something.
And "coding the music" - just easy in something cases vs rearrange lots of pattern.
#2
If you want to have this feature in OpenMPT, write it as a VST plugin. Then you can use it in any other VST-capable DAW, too. OpenMPT is simply the wrong tool for size-restricted sample generation.

OpenMPT will probably get a sample generator at some point if the scripting support ever gets finished. But this won't be a realtime generator or anything like that, it simply creates a normal sample which is then saved to you module file.
#3
Well, along with the sample editor through mouse and pen tool in MPT, I thinking (since 2010) about simple expression for mathematical drawing any sample in the editor.

In the web can looking for:
P.S.: Just, like "nightly release" - for experiment, in OpenMPT is possible to add this feature? ::)
Like goal - powerful OpenMPT Studio with integrated sample generator without any side utilities.
(I'm 15 years waiting for it. ;D )
#4
Development Corner / Re: OpenMpt accessibility disc...
Last post by Saga Musix - Yesterday at 18:44:21
Quote from: GoemonIshikawa on June 30, 2025, 04:13:16Another 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.
#5
Development Corner / Re: OpenMpt accessibility disc...
Last post by Saga Musix - Yesterday at 17:13:54
Quote from: GoemonIshikawa on June 30, 2025, 04:13:16The 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.

Quote from: GoemonIshikawa on June 30, 2025, 04:13:16Another 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.
 
Quote from: GoemonIshikawa on June 30, 2025, 04:13:16I'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".
#6
Development Corner / Re: ByteBeat as sample/instrum...
Last post by Saga Musix - Yesterday at 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.
#7
Help and Questions / Re: Virus alert in v1.32.01
Last post by Saga Musix - Yesterday at 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.
#8
Development Corner / ByteBeat as sample/instrument
Last post by Alikberov - Yesterday at 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. ;D
#9
Help and Questions / Re: Virus alert in v1.32.01
Last post by Helix751 - Yesterday at 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.
#10
Help and Questions / Re: Sample Volume is lower in ...
Last post by Saga Musix - Yesterday at 11:01:39
Yeah I was just going to suggest that you may have toggled that setting.

Quote from: leonard on Yesterday at 10:56:08(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.