<?xml version="1.0" encoding="utf-8"?>
<!--RSS generated by Flaimo.com RSS Builder [2026-10-21 17:43:31]-->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"><channel><docs>https://bugs.openmpt.org/</docs><link>https://bugs.openmpt.org/</link><description><![CDATA[OpenMPT Issue Tracker - Issues]]></description><title>OpenMPT Issue Tracker - Issues</title><image><title>OpenMPT Issue Tracker - Issues</title><url>https://bugs.openmpt.org/images/custom/openmpt-bt-logo.png</url><link>https://bugs.openmpt.org/</link><description><![CDATA[OpenMPT Issue Tracker - Issues]]></description></image><language>en</language><category>All Projects</category><ttl>10</ttl><dc:language>en</dc:language><sy:updatePeriod>hourly</sy:updatePeriod><sy:updateFrequency>1</sy:updateFrequency><item><title>0001991: update LAME</title><author></author><link>https://bugs.openmpt.org/view.php?id=1991</link><description><![CDATA[see &lt;&lt;a href=&quot;https://svn.code.sf.net/p/lame/svn/trunk/lame/doc/html/history.html&gt;&quot; rel=&quot;noopener,nofollow&quot;&gt;https://svn.code.sf.net/p/lame/svn/trunk/lame/doc/html/history.html&gt;&lt;/a&gt;]]></description><category>File Format Support</category><pubDate>Mon, 19 Oct 2026 17:53:55 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1991</guid><comments>https://bugs.openmpt.org/view.php?id=1991#bugnotes</comments></item><item><title>0001990: Pattern break in MOD/XM files is clamped without warning</title><author></author><link>https://bugs.openmpt.org/view.php?id=1990</link><description><![CDATA[I was testing corner-cases in MOD/XM files, and I created an XM file that had a pattern break to line 135 or so, and I noticed that my player was jumping to the wrong row.&lt;br /&gt;
&lt;br /&gt;
Basically, OpenMPT lets you write any value from 0x00 to 0xFF in a Dxx effect, but then it can only save values from 0x00 to 0x9F in the final file. While you are editing the file, it will use the original value without letting you know it goes over the limit, it will even jump to the correct row in the following pattern. When you save it, it doesn't warn you or anything because CSoundFile::ModSaveCommand() doesn't check bounds for CMD_PATTERNBREAK. It simply overflows, it doesn't max out at 0x9F.&lt;br /&gt;
&lt;br /&gt;
For MOD this isn't a big deal because you can't have MOD patterns with more than 64 rows, but XM can have longer patterns, and it could happen that someone uses a pattern break with a parameter over 0x9F.&lt;br /&gt;
&lt;br /&gt;
I would expect that the pattern editor doesn't let me input values higher than 0x9F, or that it warns me when it saves the file.]]></description><category>File Format Support</category><pubDate>Mon, 12 Oct 2026 19:10:45 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1990</guid><comments>https://bugs.openmpt.org/view.php?id=1990#bugnotes</comments></item><item><title>0001772: Move MIDI output off audio thread</title><author></author><link>https://bugs.openmpt.org/view.php?id=1772</link><description><![CDATA[While working on [Beyond](&lt;a href=&quot;https://sagamusix.de/download/beyond/&quot; rel=&quot;noopener,nofollow&quot;&gt;https://sagamusix.de/download/beyond/&lt;/a&gt;) my ASIO driver was struggling due to the MIDI driver taking its time to process outgoing MIDI messages to seven different devices. I modified the MIDI code locally to run on a separate thread (one per device actually), but that solution is not quite in a merge-able state yet (there are still some random deadlocks when closing a module). But the direction is right and should be used for more stable MIDI output.]]></description><category>General</category><pubDate>Fri, 09 Oct 2026 13:55:16 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1772</guid><comments>https://bugs.openmpt.org/view.php?id=1772#bugnotes</comments></item><item><title>0001988: When importing this Soundfont, it's not importing ANY samples</title><author></author><link>https://bugs.openmpt.org/view.php?id=1988</link><description><![CDATA[When importing this Soundfont I provided in the zip file, it's not importing any samples whatsoever.]]></description><category>File Format Support</category><pubDate>Fri, 09 Oct 2026 13:45:31 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1988</guid><comments>https://bugs.openmpt.org/view.php?id=1988#bugnotes</comments></item><item><title>0000783: cross-platform OpenMPT</title><author></author><link>https://bugs.openmpt.org/view.php?id=783</link><description><![CDATA[This is a meta-issue, collecting various other issues related to making OpenMPT itself cross-platform.]]></description><category>Feature Request</category><pubDate>Mon, 05 Oct 2026 13:19:44 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=783</guid><comments>https://bugs.openmpt.org/view.php?id=783#bugnotes</comments></item><item><title>0001989: "Classic (accurate)" tempo mode</title><author></author><link>https://bugs.openmpt.org/view.php?id=1989</link><description><![CDATA[A tempo mode that behaves like classic, but has accurate BPM like the modern mode (similar to the &quot;precise BPM&quot; option in 8bitbubsy's FT2 clone). This would allow BPM-accurate renders of modules that change their speed, e.g. for remixing in modern DAWs.&lt;br /&gt;
&lt;br /&gt;
Though maybe this would work better as a tracker setting (a toggle for always using precise BPM calculation regardless of the song's tempo mode) rather than a song setting.]]></description><category>Feature Request</category><pubDate>Sat, 26 Sep 2026 10:41:48 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1989</guid><comments>https://bugs.openmpt.org/view.php?id=1989#bugnotes</comments></item><item><title>0001987: Duplicating patterns does not create an undo point</title><author></author><link>https://bugs.openmpt.org/view.php?id=1987</link><description><![CDATA[Duplicating a pattern cannot be undone, which may cause the undo buffer to apply confusing actions if another previous undo action modifies the same pattern.&lt;br /&gt;
&lt;br /&gt;
For example:&lt;br /&gt;
- Delete pattern 0&lt;br /&gt;
- Duplicate pattern 1, which now creates a new pattern 0&lt;br /&gt;
- Undo&lt;br /&gt;
&lt;br /&gt;
The old contents of pattern 0 are now found in the new pattern 0.]]></description><category>User Interface</category><pubDate>Sat, 29 Aug 2026 23:40:00 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1987</guid><comments>https://bugs.openmpt.org/view.php?id=1987#bugnotes</comments></item><item><title>0001951: Keep loop pattern on when using Space to play song</title><author></author><link>https://bugs.openmpt.org/view.php?id=1951</link><description><![CDATA[When using Space to play a track with Loop Pattern turned on, the loop keeps disabling. There's some more information here: &lt;a href=&quot;https://www.reddit.com/r/OpenMPT/comments/1k16k60/comment/o1q6o7y/?context=1&quot; rel=&quot;noopener,nofollow&quot;&gt;https://www.reddit.com/r/OpenMPT/comments/1k16k60/comment/o1q6o7y/?context=1&lt;/a&gt; - as explained, if using pause instead of stop, the loop pattern doesn't turn off, but there should be a way to force Loop Pattern to stay on persistently.]]></description><category>Feature Request</category><pubDate>Sat, 22 Aug 2026 21:47:36 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1951</guid><comments>https://bugs.openmpt.org/view.php?id=1951#bugnotes</comments></item><item><title>0001984: Treeview usability improvements</title><author></author><link>https://bugs.openmpt.org/view.php?id=1984</link><description><![CDATA[For starters, you should be able to select multiple items in there, it's very annoying when I want to delete a bunch of samples or patterns at once and I have to go one at a time instead of just box selecting and pressing delete all at once, might be even faster than using the cleanup menu in certain circumstances! Even if box selecting isn't possible, it's very annoying when I instinctively shift or ctrl click to select multiple items on there only to unselect the first thing I clicked, so that could be added instead&lt;br /&gt;
&lt;br /&gt;
In the same vein as that, being able to drag samples or instruments would make working a lot faster, so instead of having to open the sample tab in one song, copying, going to the other song, and pasting, you could just grab the sample and bring it over, not to mention if you want to use multiple from a sample or instrument bank you could just select them and drag them all across instead of pasting one at a time.&lt;br /&gt;
&lt;br /&gt;
Finally, being able to &quot;add&quot; patterns into the hierarchy should probably be added, it seems so weird that you can Edit, Delete, Set, Rename, but not make a new one.]]></description><category>Feature Request</category><pubDate>Sun, 16 Aug 2026 18:07:46 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1984</guid><comments>https://bugs.openmpt.org/view.php?id=1984#bugnotes</comments></item><item><title>0001985: 16-bit tempo XMs: header tempo clamped to 1000, and volume ramping causes loud whines</title><author></author><link>https://bugs.openmpt.org/view.php?id=1985</link><description><![CDATA[Test module: &quot;Jakob Bienenhalm – Haesslich&quot; (scene.org, one-sample compo, winner of Evoke 2013 - One sample compo). Header tempo 39293, speed 16, 16 channels. Every row triggers a note on all 16 channels with EDx (x = channel index): one retrigger per tick, music in the volume column — the module is a PCM DAC at tick rate. Plays correctly in XMPlay, which I used as reference renderer (48 kHz WAV) for the measurements below.&lt;br /&gt;
&lt;br /&gt;
Issue 1 — loader clamp. Load_xm.cpp clamps the header tempo to xmEx max (1000): the module plays &lt;a href=&quot;https://bugs.openmpt.org/view.php?id=61#c39&quot; class=&quot;resolved&quot;&gt;0000061:0000039&lt;/a&gt;× too slow. The XM saver has a comment saying FT2 accepts any 16-bit tempo. Suggested fix: clamp to uint16_max on load (safe as far as I can tell: the default tempo never goes through SetTempo(), and Fxx is 8-bit).&lt;br /&gt;
&lt;br /&gt;
Issue 2 — volume ramp longer than a tick. With the tempo fixed, a row is 48 samples at 48 kHz but the FT2-style ramp is 5 ms (240 samples): retriggered every row, it never completes and modulates the whole mix at the row rate — a loud steady &lt;a href=&quot;https://bugs.openmpt.org/view.php?id=6#c1&quot; class=&quot;resolved&quot;&gt;0000006:0000001&lt;/a&gt; kHz whine (−38 dBFS vs −86 in the XMPlay render). Disabling ramping instead leaves the tick steps unsmoothed: 16 kHz carrier at −32 dBFS (XMPlay: −54).&lt;br /&gt;
&lt;br /&gt;
Suggested fix: cap the ramp length at the tick length when ticks are very short (e.g. samplesPerTick &lt; 64). Measured result: whine −95 dBFS, carrier −56 — at or below the XMPlay reference, and every normal module stays bit-identical.&lt;br /&gt;
&lt;br /&gt;
Note: fractional tick lengths in Classic mode make things worse (the inserted longer ticks form an audible &lt;a href=&quot;https://bugs.openmpt.org/view.php?id=285#c849&quot; class=&quot;resolved&quot;&gt;0000285:0000849&lt;/a&gt; Hz-spaced comb); XMPlay appears to use integer ticks (its carrier sits at exactly 48000/3 Hz).]]></description><category>libopenmpt</category><pubDate>Sun, 16 Aug 2026 17:37:20 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1985</guid><comments>https://bugs.openmpt.org/view.php?id=1985#bugnotes</comments></item><item><title>0001983: Accidental quadratic complexity in C API metadata retrieval</title><author></author><link>https://bugs.openmpt.org/view.php?id=1983</link><description><![CDATA[`openmpt_module_get_*_name` functions return individual item names, but use the C++ APIs that return entire vectors of items under the hood to retrieve the item name. Listing for example all sample names thus introduces quadratic complexity.&lt;br /&gt;
&lt;br /&gt;
The internal implementation (`mod-&gt;impl`) should probably offer both single-name and multi-name variants for the the C++ and C APIs to use, with the multi-name variant using the single-name variant under the hood to avoid inconsistencies in string conversion etc.]]></description><category>libopenmpt</category><pubDate>Tue, 04 Aug 2026 18:47:50 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1983</guid><comments>https://bugs.openmpt.org/view.php?id=1983#bugnotes</comments></item><item><title>0001982: Parameter editor screen doesn't update properly if updated row is not visible in pattern view</title><author></author><link>https://bugs.openmpt.org/view.php?id=1982</link><description><![CDATA[The parameter editor / &quot;visualize effect&quot; window is not redrawn when the mouse is clicked on a certain region. The position and size of this region seems to be random. The window is properly redrawn again if resized, or if the mouse is clicked somewhere else outside the region.&lt;br /&gt;
&lt;br /&gt;
I was able to reproduce this on my main computer on both Wine 11.13 and a Windows 10 virtual machine, but it works fine on a different machine running Windows 10 natively. So this might only be an issue on Wine and virtualized systems?]]></description><category>User Interface</category><pubDate>Tue, 28 Jul 2026 12:45:59 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1982</guid><comments>https://bugs.openmpt.org/view.php?id=1982#bugnotes</comments></item><item><title>0001981: Cue points playability via keyboard</title><author></author><link>https://bugs.openmpt.org/view.php?id=1981</link><description><![CDATA[Hello Saga,&lt;br /&gt;
&lt;br /&gt;
Would it be a feasible idea to make the cue points playable and recordable via the pattern editor? I had this idea that within the sample map in the instrument tab a third column could be added representing the cue point number. This way you could assign them to a key and a root note and &quot;jam&quot; with the cue points to come up with ideas and record them. &lt;br /&gt;
&lt;br /&gt;
I know you can preview cue points within the sample editor via Shift + cue number, but you can't record this into the pattern editor. And I am aware that you can slice a sample at cue points and make a new instrument with those samples but this means you have to commit to the slices and with two sliced samples or more the sample pool can become quite unwieldy. The only way at the moment is to &quot;program&quot; the cue points in the pattern editor via the &quot;o&quot; command in the volume column.&lt;br /&gt;
&lt;br /&gt;
Again it's just an idea I had and I'm not a programmer so I have no idea if this fits the roadmap or if its realistic within the scope of the development of openmpt. &lt;br /&gt;
&lt;br /&gt;
Greetings,&lt;br /&gt;
&lt;br /&gt;
FWL]]></description><category>Feature Request</category><pubDate>Sun, 26 Jul 2026 17:19:43 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1981</guid><comments>https://bugs.openmpt.org/view.php?id=1981#bugnotes</comments></item><item><title>0001980: Auto adjust sample volume after normalizing it</title><author></author><link>https://bugs.openmpt.org/view.php?id=1980</link><description><![CDATA[The &quot;normalize&quot; function in the sample editor could adjust the sample's global volume, like the &quot;remove DC offset&quot; function. (or maybe add a separate variant of the normalize function that does this.)]]></description><category>Feature Request</category><pubDate>Fri, 24 Jul 2026 20:41:05 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1980</guid><comments>https://bugs.openmpt.org/view.php?id=1980#bugnotes</comments></item><item><title>0001042: Render pattern channels to separate buffers</title><author></author><link>https://bugs.openmpt.org/view.php?id=1042</link><description><![CDATA[Suggested by emoon (and some other people in the past): Provide a libopenmpt interface for rendering each channel separately, e.g. so that you can draw scopes for each pattern channel.&lt;br /&gt;
OpenMPT could also benefit from this.&lt;br /&gt;
Plugins make this more complicated because if two channels feed their output into one plugin, we cannot tell them apart anymore. Renoise &quot;solves&quot; this by only showing the plugin output on one of the channels (the last one that triggered a note, I think).&lt;br /&gt;
We can already render channels to different buffers (e.g. for plugins or reverb), so the infrastructure is there, it just cannot be used to its full extent at the moment.]]></description><category>libopenmpt</category><pubDate>Thu, 16 Jul 2026 19:46:20 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1042</guid><comments>https://bugs.openmpt.org/view.php?id=1042#bugnotes</comments></item><item><title>0001979: Loop-vision mode in sample editor.</title><author></author><link>https://bugs.openmpt.org/view.php?id=1979</link><description><![CDATA[Loop overlay mode.&lt;br /&gt;
When mode is activated, if you are looking at loop start/end, corresponding waveforms are overlayed with different color.&lt;br /&gt;
This is less pressing with technological advancements such as crossfading, but personally, I'd rather butcher as little as possible.&lt;br /&gt;
Caveat: cannot see properly if at the very start/end of sample.&lt;br /&gt;
For this I propose: split view. Draw another sample view in line with the real sample view, but dedicated to loop viewing, own zoom, only activates with mode.]]></description><category>Feature Request</category><pubDate>Wed, 08 Jul 2026 15:27:26 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1979</guid><comments>https://bugs.openmpt.org/view.php?id=1979#bugnotes</comments></item><item><title>0001978: Sample editor modes for amplitude and DC, using instr envelope semantics with realtime update</title><author></author><link>https://bugs.openmpt.org/view.php?id=1978</link><description><![CDATA[I propose three new buttan/tools in sample editor.&lt;br /&gt;
&lt;br /&gt;
1. Live amplitude editor.&lt;br /&gt;
Enable mode to add envelopes in the sample editor, by points. Same semantics as instruments, except tied to middle axis(amp or decrease vol).&lt;br /&gt;
These update waveform live so you can see what you are doing. Optionally, affect playback live.&lt;br /&gt;
When you are done, can discard or apply to sample.&lt;br /&gt;
Use: fiddle with sample dynamics.&lt;br /&gt;
&lt;br /&gt;
2. Live DC offset editor.&lt;br /&gt;
Similar to above in operation.&lt;br /&gt;
Use: correct wobbly DC offset before fiddling with dynamics, impromptu half-sample distortion!]]></description><category>Feature Request</category><pubDate>Mon, 06 Jul 2026 20:28:09 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1978</guid><comments>https://bugs.openmpt.org/view.php?id=1978#bugnotes</comments></item><item><title>0001977: Rendering X and Y cursor axis in sample view when drawing enabled.</title><author></author><link>https://bugs.openmpt.org/view.php?id=1977</link><description><![CDATA[Render an X and an Y axis at cursor position in sample view when sample-drawing pencil is enabled.&lt;br /&gt;
This is like a ruler.&lt;br /&gt;
&lt;br /&gt;
Serves two purposes.&lt;br /&gt;
1. Helps you eye amplitudes faster when looking at the other cycles of the waveform.&lt;br /&gt;
2. Is warning signal that you left drawing mode on. Too many times I was dingus and accidentally drawn spikes into sample. Derp.&lt;br /&gt;
&lt;br /&gt;
Adendum:&lt;br /&gt;
We have a measurement bar on top of sample. What if we add a second vertical axis, adjustable to be in front or behind cursor position by X amount?&lt;br /&gt;
This improves eyeing even more.&lt;br /&gt;
Now the ruler has become a caliper!]]></description><category>Feature Request</category><pubDate>Mon, 06 Jul 2026 12:29:04 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1977</guid><comments>https://bugs.openmpt.org/view.php?id=1977#bugnotes</comments></item><item><title>0001971: Looping problem in OpenMPT</title><author></author><link>https://bugs.openmpt.org/view.php?id=1971</link><description><![CDATA[Hi )&lt;br /&gt;
Now available problem and as I think not correct work OpenMPT plugin , what I want mean...&lt;br /&gt;
If I not want use repeating and looping file I check repeat never , with this setting all files will play once and next will stoped&lt;br /&gt;
If I want do looping playlist , me need check this setting and check repeating or looping playlist in player and this logical . but if module available jump to back with looping zone - I can not hearing correct result if do set repeat never , if I set repeat once - I get one replay and all , but what if I want not do looping all modules , but want recive corretly forever looping separate modules ?&lt;br /&gt;
Examples :&lt;br /&gt;
&lt;a href=&quot;https://disk.yandex.ru/d/9O5NXOqieNhnFA&quot; rel=&quot;noopener,nofollow&quot;&gt;https://disk.yandex.ru/d/9O5NXOqieNhnFA&lt;/a&gt; - this without looping&lt;br /&gt;
&lt;a href=&quot;https://disk.yandex.ru/d/WsIPhuqDNAOtMA&quot; rel=&quot;noopener,nofollow&quot;&gt;https://disk.yandex.ru/d/WsIPhuqDNAOtMA&lt;/a&gt; - this file must be looping , but in currently settings absent option auto , I mean sayd what OpenMPT can not detect is it necessary to loop the module?&lt;br /&gt;
Please , add option besides Never , Forever , Once , method Auto , I offer do auto as automatic detect is there any need looping in data of tracker]]></description><category>Player input plugins (xmp-openmpt, in_openmpt)</category><pubDate>Thu, 25 Jun 2026 07:35:24 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1971</guid><comments>https://bugs.openmpt.org/view.php?id=1971#bugnotes</comments></item><item><title>0001976: Add the ability to estimate length of certain patterns.</title><author></author><link>https://bugs.openmpt.org/view.php?id=1976</link><description><![CDATA[There's been a few times now where I'm dealing with songs of abnormal pattern lengths where I want to get an easy idea of how long sections are without having to constantly do subtraction in my head, so being able to select certain patterns to estimate it's song length (the same way you're able to do with selecting patterns to export only certain sections of a song) would be a really nice addition to the program. If you don't want to clutter the UI with an extra button in the Player drop down, you could just add a second line under &quot;Approximate song length:&quot; that says &quot;Approximate selection length:&quot;, and it'd also be nice to select rows and be able to do it for that, but given that it's not currently possible to export certain rows I'd understand if it doesn't make sense to add.]]></description><category>User Interface</category><pubDate>Wed, 24 Jun 2026 20:43:27 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1976</guid><comments>https://bugs.openmpt.org/view.php?id=1976#bugnotes</comments></item><item><title>0001975: Instrument Bake for notes</title><author></author><link>https://bugs.openmpt.org/view.php?id=1975</link><description><![CDATA[&gt; (render samples for several notes and tune them as one instrument)&lt;br /&gt;
&lt;br /&gt;
A new DIALOGEX with a Sample Map:&lt;br /&gt;
&lt;br /&gt;
input several notes to play and numbers them (or names them), map the notes, and finally override an instrument.&lt;br /&gt;
&lt;br /&gt;
## new DIALOGEX:&lt;br /&gt;
&lt;br /&gt;
- A GROUPBOX for managing builtin and custom mapping presents. builtin: buttons per set, cyclic arrangement, single sample (range supported). Maybe create new file extension.&lt;br /&gt;
- A ??? for inputing notes and IDs.&lt;br /&gt;
- A Piano Key Map like the Sample Map.&lt;br /&gt;
- A GROUPBOX with widgets used to select the sampling range, duration, and samples mapping interval.&lt;br /&gt;
- A GROUPBOX used to select rendering settings and instrument slots.]]></description><category>Feature Request</category><pubDate>Sat, 13 Jun 2026 08:24:14 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1975</guid><comments>https://bugs.openmpt.org/view.php?id=1975#bugnotes</comments></item><item><title>0001017: Tick boundary rendering (was: ~~Provide access to next play position~~)</title><author></author><link>https://bugs.openmpt.org/view.php?id=1017</link><description><![CDATA[PoroCYon asked on IRC if it's possible to retrieve the next play position (row/pattern). We already have this information, but it is currently not exposed.]]></description><category>libopenmpt</category><pubDate>Thu, 11 Jun 2026 12:06:32 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1017</guid><comments>https://bugs.openmpt.org/view.php?id=1017#bugnotes</comments></item><item><title>0001373: Fasttracker 2 Custom Sync Event (Wxx) not implemented in OpenMPT</title><author></author><link>https://bugs.openmpt.org/view.php?id=1373</link><description><![CDATA[I've seen ms-dos demos that have events that are triggered by this effect command for syncing to the beat for the .xm files. Protracker also does that by using 8xx for syncing too. Can you implement that please? Thank you]]></description><category>Feature Request</category><pubDate>Thu, 11 Jun 2026 06:05:25 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1373</guid><comments>https://bugs.openmpt.org/view.php?id=1373#bugnotes</comments></item><item><title>0001662: Real stereo channel VU meter</title><author></author><link>https://bugs.openmpt.org/view.php?id=1662</link><description><![CDATA[The channel VU meters are fake, (mostly Scream tracker, Schism Tracker [to 2009 version]), This feature needs to make real VU meter mostly like (IMAGO Orpheus, Impulse Tracker, Schism Tracker [from 2010 version])&lt;br /&gt;
```&lt;br /&gt;
L 100      75      50      25     0     25      50      75      100 R&lt;br /&gt;
  [[]][[]][[]][[]][[]][[]][[]][[]]|[[]][[]][[]][[]][[]][[]][[]][[]]&lt;br /&gt;
```&lt;br /&gt;
Can you make this feature and put to Miscellaneous Options]]></description><category>Feature Request</category><pubDate>Sat, 06 Jun 2026 06:17:05 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=1662</guid><comments>https://bugs.openmpt.org/view.php?id=1662#bugnotes</comments></item><item><title>0000569: Unicode strings in CSoundFile.</title><author></author><link>https://bugs.openmpt.org/view.php?id=569</link><description><![CDATA[Use Unicode strings for all strings (samples/instrument/channel/pattern names and other general metadata) in CSoundFile.]]></description><category>General</category><pubDate>Sat, 06 Jun 2026 06:07:58 +0000</pubDate><guid>https://bugs.openmpt.org/view.php?id=569</guid><comments>https://bugs.openmpt.org/view.php?id=569#bugnotes</comments></item></channel></rss>
