buzz forums

Thanks for the report. I've found additional issues not addressed in the previous fix.

Download the new build and let me know if clicks persist. The fix should handle all cases of v1.10 project loading.

Amazing, thanks. Will let you know later.

Still getting the high amp clicks and pops I'm afraid, along with some erratic other crazy sounds. Let me know if there's any more specific info I can pass over.

Thanks for the report. I'm confused about the issue. Buzz installs Matilde Tracker2.dll, which doesn't conflict with the latest Matilde Tracker (Matilde Tracker.dll). I can't load Matilde 1.09 on the latest Buzz, and I can't find 1.10 anywhere. Renaming the latest one seems like the best workaround.

I added new fixes, but we're in a bit hit and miss scenario.

Huge thanks for your time, this might be a total dead end and given that it seems to be fine if you start from scratch OR just leave it on filter mode 2 then that may be how it is...

I've always used the multi-out mtracker as 'Matilde Tracker3.dll' and that's what I've been copying these updates to. Could that be overly confusing matters?

Hey @george

Your updated, updated version of Matilde *seems* to play better in ReBuzz than in old Buzz. I don't have empirical proof of this but my testing the improved SINC setting in old Buzz has usually had it using a lot more CPU than is really feasible whereas in ReBuzz that doesn't *seem* to be an issue. How much of a task would it be (given we now have absurdly powerful AI coding tools to help us) to create a 64bit version of it? Is your updated source for it available anywhere?

I guess 3 seconds but how would the 64-bit version help?

I'm thinking some overhead might be reduced by the processes running directly under the ReBuzz main process rather than via the 32bit bridge. Is that naive?

george wrote: ↑Sun Oct 12, 2025 5:07 pm

Joachip wrote: ↑Sat Oct 11, 2025 5:39 pm The recent versions are called "Matilde Tracker2.dll" (versions 1.7 and up). I wonder if we should stick to this? ... or is it called "Matilde Tracker.dll" in people's Buzz installs?

Output binary in the project was called Matilde Tracker.dll for the 1.10rc build. I kept this name, but I can change it if another name is required.

I think it might be better if the new build is called Matilde Tracker2.dll as the original Matilde Tracker only had one parameter vs Matilde Tracker 2's six parameters (i.e. from version 1.7 and up)



Loading old projects with these latest builds of Matilde Tracker.dll causes all Matilde patterns in that project to be empty - presumably due to this parameter mismatch ( viewtopic.php?p=17903#p17903 )

Oh, feel free to rename the dll on the zip.

Took some free time today to update Matilde to 1.14. This version rewrites the SINC resampler, fixes a number of crashes and playback bugs, and adds a 64-bit build.

Package contents

• x86/Matilde Tracker.dll for 32-bit Buzz
• x64/Matilde Tracker.dll for 64-bit Buzz
• README.txt

Copy the DLL that matches your Buzz into Gear\Generators.

64-bit build

• New x64 DLL for 64-bit Buzz
• The C runtime is linked statically, no Visual C++ redistributable needed

SINC resampler rewrite

• Stereo samples play in stereo in SINC modes (before, only the left channel was used)
• Looped samples no longer stop at the loop end in SINC modes
• No more clicks at loop points: interpolation reads across the loop, wrapped for forward loops and mirrored for ping-pong loops
• Kaiser-windowed kernels from precomputed tables instead of sin/cos per tap, many times faster
• When pitching up, the kernel widens to keep aliasing low
• AVX2/FMA is used for 16-bit and float samples, mono and stereo, when the CPU and Windows support it. The DLL itself no longer requires AVX2, so it loads on any x86 CPU.

Crash fixes

• Crash after many notes with virtual channels or probability (10xx): sample slots leaked until the pool ran out
• Crash when a note was cut between subdivision steps (DC, 18, ED)
• Crash with an arpeggio after a cut in the first effect slot
• Memory corruption with sample offset (09xx) past the loop end
• Hang or memory corruption on waves with a zero-length loop
• Crash after reducing the number of tracks while notes were playing

Playback fixes

• B notes were detuned: the B tuning attribute was never read
• Effect 23 (cutoff LFO type) acted as tone portamento and the note did not play
• 15xx random delay dropped the note when the roll was 0, and 15 00 dropped every note
• Delayed notes (ED, 18, 15, shuffle) were lost on tracks whose previous note had already ended
• 03 00 with no earlier portamento speed silenced the note
• 19 1y (sustain pedal down) only worked for 19 10
• 17xx on a row without a note used a garbage pitch
• Arpeggio, portamento and 17xx now follow the per-note tuning offsets
• Stereo samples with the filter on: the right channel was not filtered
• Stereo fade-out could click on the right channel
• Reverse playback skipped a sample when wrapping into the loop
• Stale audio in blocks split at a subdivision step
• Voices taken over by channel stealing kept being controlled by their old track
• MIDI note numbers below 24 were played as note-offs or got stuck
• Opening About twice stacked dialogs
• With virtual channels, notes started by E9, ED, 18 or 15 now start on their step instead of up to one buffer late
• The Mono build wrote mono data into stereo outputs

Requirements

• Windows 10 or later, 32-bit or 64-bit Buzz
• AVX2 is optional: Intel Haswell (2013+) and AMD Excavator (2015+) get the faster SINC path, older CPUs use scalar code

Thank you !!!

Thanks a lot!