Recent Posts

Pages: 1 ... 8 9 [10]
91
Help and Questions / Re: can you export MIDI modulation wheel?
« Last post by biolizardshadow on October 04, 2020, 16:20:16 »
I didn't know that.
92
Help and Questions / Re: can you export MIDI modulation wheel?
« Last post by Saga Musix on October 04, 2020, 16:16:19 »
It means that the Mod Wheel simply has no pre-defined meaning in the MIDI world. You will find it to be assigned to some sort of vibrato effect in many cases, but it doesn't need to be that way, and it's undefined how deep or how fast that vibrato is. It all depends on the synthesizer. Hence OpenMPT has no concept of how to use the Mod Wheel in MIDI export or any other situation, because it's entirely up to the synthesizer that is going to interpret the MIDI data what it does with the Mod Wheel.
93
Help and Questions / Re: can you export MIDI modulation wheel?
« Last post by biolizardshadow on October 04, 2020, 16:13:15 »
What do you mean by "freely definable?"
94
Help and Questions / Re: channel management
« Last post by Saga Musix on October 04, 2020, 16:03:45 »
I have now added two new shortcuts ("Move Channels to Left" and "Move Channels to Right") which either move the current selection, or if there is none, the channel of the edit cursor. The dialog you proposed may still follow at a later point.
The new shortcuts have no default keys assigned at the moment.
95
Help and Questions / Re: can you export MIDI modulation wheel?
« Last post by Saga Musix on October 04, 2020, 10:32:45 »
The Mod Wheel is freely definable and as such as no "sound" that you could hear in OpenMPT. Granted, the most common use case is probably vibrato but there are tons of other ways to use the mod wheel in MIDI-capable synthesizers (e.g. to change the filter cutoff). Tracker vibrato semantics are also very different from how vibrato would work with a mod wheel so it's not possible to directly translate those commands to mod wheel commands. If you want to have identical playback between the tracker and MIDI export, you will have to work with an instrument plugin to begin with, e.g. a soundfont player like sforzando. Then you can have MIDI semantics in the tracker in the same way as they would be used in the exported MIDI file.
96
Help and Questions / Re: can you export MIDI modulation wheel?
« Last post by biolizardshadow on October 04, 2020, 03:49:37 »
I just wanted to know how I can get it to sound in the tracker and be able to export it properly. As of now I'm not sure what command to link it to since vibrato exports as pitchbend commands and that's the only thing I can think of when trying to emulate that command within the tracker.
97
Help and Questions / Re: openmpt123: Getting 16Bit WAV PCM on stdout
« Last post by Joker on October 03, 2020, 20:50:28 »
Quote
Is there any specific reason why you want to use 16bit PCM instead of the default 32bit float PCM? Module files can contain signals >0dBFs (either as intended for formats that specify absolute volume, or simply as rendered by libopenmpt) and floating point PCM provides better signal-to-noise ratio than 16bit PCM, which is particularly useful if you perform further processing (which is what I gather stereotool does (I am not familiar with stereotool though)).

The reason for 16bit PCM WAV is because, that's what stereo_tool accepted as input. There is a bit depth option but i didn't really see
something to accept float. I'll check the documentation a bit more to see if there's such an option.

Update:
Found the option for a full 32bit float chain. The bit option was "32f" while i falsely assumed only "32" works.
Sox is still required for "-t raw" to "-t wav" though, otherwise there's just noise:
openmpt123 --stdout <MOD>) | sox -t raw -b 32 -e float -c 2 -r 48000 - -t wav - | stereo_tool_cmd_64 --bitspersample 32f --quiet - -  | aplay --quiet
98
Help and Questions / Re: openmpt123: Getting 16Bit WAV PCM on stdout
« Last post by manx on October 03, 2020, 20:34:52 »
Quote from: Joker on October 03, 2020, 19:39:07
I'm trying to pipe 16bit PCM WAV into stereotool.
WAV is unsuitable for piping to stdout, because a WAV header needs to contain the length of the contained data, which cannot be known precisely before the file is finished. Updating the length later would require seeking, which is impossible for piped output. Do NOT try use WAV for pipe output.

Quote from: Joker on October 03, 2020, 19:39:07
I get the correct format with --no-float,
however when using "--output -" i only end up with 256 bytes of data which is probably
only the header.

This works:
openmpt123 --no-float --output tmpfile <mod>
cat tmpfile | stereo_tool_cmd_64 --quiet - - | aplay --quiet

This fails:
openmpt123 --no-float --output - <mod> | stereo_tool_cmd_64 --quiet - - | aplay --quiet

The reason it fails is because "openmpt123 --no-float --output - <mod> > file" only produces
256 bytes of data.

openmpt123 is clearly meant to accept "-" as stdout for --output, otherwise it would reject
"-" or create a file named "-" in the first place. Is this a bug i'm hitting?

No, this is not meant to work. openmpt123 passes the passed filename ("-") verbatim to the backend that writes the output. In the default case, this would be libsndfile for WAV (the default) output. Libsndfile apparently chooses to write to stdout, which may be a bug in libsndfile (I did not investigate this further). There sadly is absolutely nothing openmpt123 could do here. The correct behaviour would be to write to a file called "-".

Try
openmpt123 --stdout --samplerate 48000 --channels 2 --no-float SOMEFILE.MOD | aplay --quiet --rate=48000 --channels=2 --format=s16_le

Quote from: Joker on October 03, 2020, 19:39:07
The "--stdout" option seems to provide "too" raw output for further processing.
It would be helpful if someone knew what sox parameters could convert that
into the required 16bit PCM WAV format.
openmpt123 --stdout --samplerate 48000 --channels 2 --no-float SOMEFILE.MOD | sox -t raw -r 48k -e signed -b 16 -c 2 - output.wav
Also note: Always specify the full triplet of samplerate, sampleformat, and channels for headerless RAW output and input because defaults might change in future versions.

If you want to preserve metadata, I suggest roundtripping through a file instead of using stdout though, as openmpt123 currently does not support writing a metadata-supporting format to stdout:
openmpt123 --output output.wav SOMEFILE.MOD

Is there any specific reason why you want to use 16bit PCM instead of the default 32bit float PCM? Module files can contain signals >0dBFs (either as intended for formats that specify absolute volume, or simply as rendered by libopenmpt) and floating point PCM provides better signal-to-noise ratio than 16bit PCM, which is particularly useful if you perform further processing (which is what I gather stereotool does (I am not familiar with stereotool though)).
99
Help and Questions / openmpt123: Getting 16Bit WAV PCM on stdout
« Last post by Joker on October 03, 2020, 19:39:07 »
EDIT:
I've figured out the magic "sox" options. Still wondering why "--output -" produces only a header though.
openmpt123 --no-float --stdout <MOD> | sox -t raw -b 16 -e signed -c 2 -r 48000 - -t wav - | stereo_tool_cmd_64 --quiet - -  | aplay --quiet

I'm playing with the "Maximizer - MOD Files (ProTracker).sts" from the following URL if anyone is wondering:
https://forums.stereotool.com/viewtopic.php?t=3831


I'm trying to pipe 16bit PCM WAV into stereotool. I get the correct format with --no-float,
however when using "--output -" i only end up with 256 bytes of data which is probably
only the header.

This works:
openmpt123 --no-float --output tmpfile <mod>
cat tmpfile | stereo_tool_cmd_64 --quiet - - | aplay --quiet

This fails:
openmpt123 --no-float --output - <mod> | stereo_tool_cmd_64 --quiet - - | aplay --quiet

The reason it fails is because "openmpt123 --no-float --output - <mod> > file" only produces
256 bytes of data.

The "--stdout" option seems to provide "too" raw output for further processing.
It would be helpful if someone knew what sox parameters could convert that
into the required 16bit PCM WAV format.

openmpt123 is clearly meant to accept "-" as stdout for --output, otherwise it would reject
"-" or create a file named "-" in the first place. Is this a bug i'm hitting?
100
Help and Questions / Re: can you export MIDI modulation wheel?
« Last post by Saga Musix on October 03, 2020, 17:35:51 »
The mod wheel is standardized as CC 1. You'll have to configure a MIDI macro for that CC, i.e. the MIDI macro will most typically be "Bc01z" (or replace z by other parameters as discussed previously).
Pages: 1 ... 8 9 [10]