View Issue Details

IDProjectCategoryView StatusLast Update
0001249OpenMPTFeature Requestpublic2019-08-12 17:58
ReporterFred57 Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Platformx86OSWindowsOS VersionXP
Product VersionOpenMPT 1.28.06.00 / libopenmpt 0.4.6 (upgrade first) 
Summary0001249: midi keyboard source / OPL instrument and 16 bits samples react differently with velocity of a MIDI keyboard
Description

Hi,
I am playing with an external keyboard (midi signal from a Yamaha tyros 4 for this test and View/setup/MIDI/"midi input device = Port midi SB live"). I can do the same test with a korg or a roland product if this could help but those keyboard have aftertouch, so this would be the same)

I am playing samples of the demo sound Pigu - Nightfall (left menu - samples) for this test but I saw the same problem with others modules too

When I am playing 16 bits samples "80s clap (external)" for example the sound is great (80% of the volume level for a normal play on the keyboard compare to the Q key of my keyboard for computer which seems to be at 127)
When I am playing OPL instrument I am at 20% of the volume of the instrument with a normal play on keyboard and if I want to play at 80% to be able to hear something I think I should use an hammer on my keyboard instead of my fingers. So this seems to be impossible to play on an external midi keyboard with OPL instruments whereas there is no problem with 16 bits samples.

Not really a bug, but a real problem for musicians, so I put that in private and not in public mode... So is this the consequence of the bad quality of the samples for OPL instruments which are not done at 0db or should you add an "input level knob" to allows people using a keyboard to be able to play on this kind of samples ?

An other thing : pitch bend from my keyboard and controller has got no effect on the sample ! so all the Midi messages are not transmitted to the software. (i will test with a roland product cause yamaha products and midi messages are allways a mystery for all people having this product...)

Best Regards,
Fred

PS : for the problem with 2nd time play of a song with no volume (fade out in module) with loop song activated, only put a request to 'PlayFromStart' function (if the name is like that) at the end of the song, this will work for all kind of song (mod, etc...) . I am a computer scientist too... not only a musician, if I can help, I will do my best cause I think this software is very great ! :)

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Activities

Saga Musix

Saga Musix

2019-08-12 17:56

administrator   ~0004002

Yes, OPL instruments have a different velocity curve (logarithmic rather than linear) than samples. This is how the OPL chip works, and due to the limited volume range it doesn't make sense to try to adjust for this (most importantly, Scream Tracker 3 doesn't do that so we would be breaking compatibility if we did that). This is documented in the manual: https://wiki.openmpt.org/Manual:_Samples#Volume

This could happen with any type of synthesized instrument too, e.g. if you use a VST instrument, it may or may also not behave the same way as samples if it uses a different velocity curve.

PS : for the problem with 2nd time play of a song with no volume (fade out in module) with loop song activated, only put a request to 'PlayFromStart' function (if the name is like that) at the end of the song, this will work for all kind of song (mod, etc...) . I am a computer scientist too... not only a musician, if I can help, I will do my best cause I think this software is very great ! :)

As said this is something that needs to be fixed in the module, not in the tracker. Composers need to take care that they reset the module state to its default if they want the module to be repeatable. There is no command to automatically do that for them, and adding one isn't going to solve any problem because the trackers OpenMPT emulates didn't have such a command, and we won't add even more incompatible hacks to those formats that are not going to be supported by any other players.

Saga Musix

Saga Musix

2019-08-12 17:58

administrator   ~0004003

Not really a bug, but a real problem for musicians, so I put that in private and not in public mode...

Please don't do that. Private issues are only meant for security-critical bugs. If you make an issue public, noone can see the issue, and in particular this means that other users or contributors cannot weigh in on the issue, or even provide a fix beyond what us developers can do.

Issue History

Date Modified Username Field Change
2019-08-12 11:44 Fred57 New Issue
2019-08-12 17:56 Saga Musix Note Added: 0004002
2019-08-12 17:56 Saga Musix Priority high => normal
2019-08-12 17:56 Saga Musix Severity major => minor
2019-08-12 17:56 Saga Musix Status new => closed
2019-08-12 17:56 Saga Musix Resolution open => no change required
2019-08-12 17:58 Saga Musix Note Added: 0004003
2019-08-12 17:58 Saga Musix View Status private => public