u/UesleiDev

I posted Riff here earlier and got a lot of really useful feedback, so I wanted to share a follow-up update.

For context, Riff is a single-file VBA audio engine built on WASAPI and Media Foundation. The goal is still the same: no external DLLs, no COM registration, no references, no installer. Just import Riff.bas, call RiffOpen, and play audio directly from VBA.

The first thread helped a lot. A few people pointed out real issues and interesting future directions, so I spent some time cleaning things up and adding some of the missing pieces.

The biggest fixes and additions in this update:

• Fixed the VBA7 vs Win64 LongLong issue in the Media Foundation decoding path
• Updated the examples so RiffOpen is clearly required before playback
• Added WAV export for loaded buffers
• Added offline oscillator rendering directly to WAV
• Added biquad-based EQ, low-pass, and high-pass filters
• Added BLEP-style band-limited oscillators to reduce aliasing on square and saw waves
• Reworked the reverb into a Freeverb-style implementation
• Improved validation around buffer handles, loop regions, seeking, and memory-loaded audio
• Updated the README and API reference

The WAV export part was added because someone asked whether Riff could generate audio files instead of only playing audio. That was not available in the first version, but now it is.

Example:

Dim buf As Long
buf = RiffLoad("C:\sounds\sound.mp3")

RiffExportBufferWav buf, "C:\sounds\export.wav"

Oscillator rendering is also possible now:

RiffRenderOscillatorWav 0, 440, 3, "C:\sounds\sine.wav"
RiffRenderOscillatorWav 1, 110, 2, "C:\sounds\square.wav"
RiffRenderOscillatorWav 2, 220, 2, "C:\sounds\saw.wav"

I also experimented with direct vtable calls inside the Media Foundation decoding loop to reduce DispCallFunc overhead, but I reverted that path for now. It was too unstable in VBA and could crash Excel. I would rather keep the engine stable than ship a risky optimization just because it looks clever.

That said, the typelib discussion from the previous thread got me thinking a lot. There is clearly a bigger problem around making lower-level Windows APIs more accessible from VBA, especially for 64-bit Office, without forcing every developer to manually deal with raw pointers, vtable offsets, broken tooling, or incomplete definitions.

So this update is not just “Riff got better audio”. It also made me think that maybe these projects should not live only under my personal profile forever.

Would it make sense to create a small team or organization focused specifically on serious VBA research and tooling? Something dedicated to projects like Riff, low-level Windows API access, audio, networking, typelibs, Office automation internals, and modern experiments around what VBA can still do today?

I am curious if people would find that useful, or if it is better to keep everything as individual projects under my own GitHub.

I am very pleased to announce a significant milestone for the Wasabi project. After several in depth technical discussions with sancarn, the creator of the renowned stdVBA library, Wasabi has been officially included in the Awesome VBA list. This is a meaningful recognition for a project that originated from a specific need within a niche PowerPoint gaming community and has now matured into a robust tool for general purpose networking.

For those who are not familiar with the project, Wasabi is a self contained .bas module designed to provide a complete networking stack for VBA. It requires zero external dependencies, zero references, and no registration of COM DLLs. It implements WebSockets (WSS), raw TCP, and full Proxy support directly within the VBA environment.

The core of Wasabi architecture relies on machine code thunks for both x86 and x64 architectures. These thunks handle critical operations such as memory zeroing, byte searching, and WebSocket masking outside the standard VBA stack. This creates a vital safety layer. In typical VBA networking, the application often crashes if the editor enters break mode or encounters an unhandled error while a Windows message pump is active. Wasabi assembly thunks act as a firewall, intercepting these events and preventing the host application from closing abruptly.

The repository was recently updated to version 2.3.8-beta. This update focused on hardening the protocol implementations and expanding compatibility with modern standards.

1. Native MQTT 5.0 Implementation The MQTT parser has been significantly overhauled to move beyond the legacy 3.1.1 standard. Wasabi now natively supports the MQTT 5.0 protocol. This includes the correct processing of variable byte integers for the remaining length field and the mandatory property length fields in CONNECT, SUBSCRIBE, and PUBLISH packets. We have successfully validated this implementation against modern brokers like HiveMQ and EMQX, as well as testing tools like MQTTX. MQTTX Reported by u/Savings_Mission_534 (https://www.reddit.com/r/vba/comments/1t9q3nc/comment/ol4zycm)
2. RFC 6455 Hardening and Protocol Compliance We have reinforced the WebSocket frame parser to be strictly compliant with RFC 6455. The parser now performs strict validation of reserved bits (RSV2 and RSV3). According to the specification, if these bits are set without a negotiated extension, the connection must be terminated with a protocol error code 1002. Additionally, the handling of TLS fragments during reassembly was improved to ensure that data remains contiguous and valid even during high volume or fragmented transmissions.
3. Memory Management and Buffer Optimization The internal routine for buffer allocation, EnsureBufferCapacity, was rewritten to handle larger data streams more efficiently. The previous limits were found to be too restrictive for certain industrial applications. The module now supports data payloads of up to 256MB by utilizing a more aggressive growth strategy and safer memory pointers, which is a significant leap for the VBA environment.
4. Closing Handshake Logic The Finite State Machine (FSM) for connection teardown was refined. Wasabi now correctly handles the STATE_CLOSING status, ensuring that it sends the closing frame and waits for the server echo before fully releasing the socket resources. This prevents half open connections and potential memory leaks during rapid connect and disconnect cycles.

Looking ahead, the goal is to further increase the stability and reach of the module. There is an ongoing plan to eventually integrate these networking capabilities into a dedicated class for the stdVBA library, making it even easier for developers to build modern, connected applications.

Contributions through Pull Requests, detailed bug reports, or architectural suggestions via GitHub Issues are highly encouraged. Whether you are interested in Win32 API hacks, IoT integration, or real time data synchronization within Office, Wasabi provides a solid foundation to explore these limits.

Github: https://github.com/uesleibros/wasabi

Release: https://github.com/uesleibros/wasabi/releases/tag/v2.3.8-beta

I want to thank the members of this sub who provided technical feedback on previous versions. Your insights were crucial in identifying edge cases and refining the memory management logic. We continue to push the boundaries of what is possible within the VBA environment.

A day ago I posted here about Wasabi v2.3.2. First and foremost, I want to express my deepest gratitude. The repository just hit 20 stars on GitHub! The community reception has been absolutely incredible, and your support gave me the exact fuel I needed to push some massive updates over the last few days.

The leap from the version I posted earlier this week to the current v2.3.4-beta is not just an update. It is a complete architectural paradigm shift. I want to dive deep into what is new, because there is a lot to unpack.

1. The High Performance Assembly Engine (Wasabi ASM)

We all know VBA is excellent for automation, but it is notoriously slow at processing massive byte arrays sequentially. To solve this bottleneck once and for all, Wasabi now features a microscopic Assembly Engine. The module safely allocates executable memory and injects native x86 and x64 machine code directly into the CPU. Wasabi now executes heavy networking math with C level throughput.

• ws_mask: I completely rewrote the WebSocket XOR masking logic in Assembly. By eliminating the high overhead VBA loops, payloads ranging from kilobytes to several megabytes are now masked in microseconds. This also completely resolved a critical frame validation issue (Error 4002) with the Discord Gateway.
• mem_find: An ultra optimized "Needle in a Haystack" search engine powered by the repe cmpsb hardware instruction. Wasabi can now scan massive TCP streams for delimiters (like \r\n) almost instantaneously, without blocking the Office UI thread during large data transfers.
• mem_zero: Implements hardware level memory zeroing using the rep stosb instruction. Upon connection teardown, all sensitive buffers and proxy credentials are physically wiped from RAM instantly to prevent data leakage.
• Native Kernel Entropy: I stripped out legacy cryptographic APIs and implemented RtlGenRandom. Wasabi now fetches cryptographically secure random bytes for WebSocket masking directly from the Windows Kernel with significantly lower latency.

2. Bulletproof TLS and Graceful Teardowns

I spent the last couple of days stress testing Wasabi on highly demanding, long lived connections. I noticed a critical edge case: if a server gracefully decided to drop your connection (a normal session cycle), the Windows Schannel engine would return a SEC_I_CONTEXT_EXPIRED alert. Wasabi was misidentifying this normal teardown as a fatal decryption failure (ERR 15). Worse, it would attempt to write queued data to a dead socket, causing a zombie socket crash (ERR 10).

Version 2.3.4-beta completely eliminates this issue. The module now intercepts the graceful teardown, closes the internal state cleanly, and silently hands over the flow to the AutoReconnect engine. Long lived connections can now run for days and recover from server drops seamlessly.

3. The Future: The Framework Era (Middlewares & Extensions)

This is what excites me the most. Wasabi is evolving from a monolithic script into a modular ecosystem. I have officially laid the groundwork for an injection system using Late Binding, inspired by modern frameworks like Express.js.

The goal is to turn the core Wasabi module into a "Dumb Pipe" that only handles raw Sockets and Schannel. Everything else will become pluggable Lego pieces. The community will soon be able to inject custom high level protocols (like Socket.IO or MQTT 5.0), security interceptors (autonomous OAuth/JWT headers or E2E AES encryption), and decouple the Zlib compression into an optional standalone extension. You can read the full architectural blueprint in the repository roadmap.

4. Ultra Low Latency Code Example

By combining the new Assembly engine, the decoupled Zlib compression, and disabling the TCP Nagle algorithm, the processing overhead in VBA is now practically zero. Here is how you can build a rock solid, ultra low latency connection to Discord:

Dim h As Long

' Enable Zlib compression to drastically reduce massive payload sizes
Wasabi.WebSocketSetDeflate True, True, h

' Disable Nagle algorithm for instant packet delivery
Wasabi.WebSocketSetNoDelay True, h

' Configure a resilient AutoReconnect (5 attempts, 1000ms base delay)
Wasabi.WebSocketSetAutoReconnect True, 5, 1000, h

' Connect to Discord requesting zlib stream transport
If Wasabi.WebSocketConnect("wss://gateway.discord.gg/?v=10&encoding=json&compress=zlib-stream", h) Then
    
    Debug.Print "Connected! Physical Latency: " & Wasabi.WebSocketGetLatency(h) & "ms"
    
    Do While Wasabi.WebSocketIsConnected(h)
        Dim msg As String
        msg = Wasabi.WebSocketReceive(h)
        
        If Len(msg) > 0 Then
            Debug.Print "Received Event: " & Left(msg, 100) & "..."
        End If
        
        DoEvents
    Loop
    
End If

With these updates, Wasabi handles all the heavy protocol level math in the background, allowing your VBA project to dedicate 100% of its execution time to your actual application logic.

Check out the latest release:

GitHub Repository: https://github.com/uesleibros/wasabi

Release v2.3.4-beta: https://github.com/uesleibros/wasabi/releases/tag/v2.3.4-beta

Extensions Roadmap: https://github.com/uesleibros/wasabi/tree/main/extensions

Thank you all once again for the stars, the feedback, and the community validation. It is an honor to build this alongside you. I would love to hear your thoughts, answer questions, or see the crazy integrations you are building with this!

Two days ago I posted about Wasabi, a zero-dependency WebSocket/WSS module for VBA. Since then the project has moved quickly. Version v2.3.2-beta is now available, and I want to share what has been added.

The biggest addition is a full native TCP client that works over plain TCP and over TLS 1.2/1.3. It shares the same connection pool, proxy support, MTU discovery, and Schannel infrastructure as the WebSocket client. The API is deliberately straightforward:

Dim h As Long

' Plain TCP
If TcpConnect("tcpbin.com", 4242, h) Then
    TcpSendText "Hello" & vbCrLf, h
    Debug.Print TcpReceiveText(h)
    TcpDisconnect h
End If

' TLS-wrapped TCP
If TcpConnectTLS("example.com", 443, h) Then
    TcpSendText "GET / HTTP/1.0" & vbCrLf & "Host: example.com" & vbCrLf & vbCrLf, h
    Debug.Print TcpReceiveText(h)
    TcpDisconnect h
End If

All TCP functions (TcpSend, TcpSendText, TcpReceive, TcpReceiveText, TcpReceiveUntil, TcpBroadcast, etc.) work seamlessly with corporate proxies, NTLM/Kerberos authentication, and the same TLS stack that powers wss connections. The same timeout, certificate, and buffer configuration functions are available on TCP handles as well.

The repository now contains an examples folder with ready-to-run code:

• WebSocket connection to Binance for live ticker data
• MQTT publish and subscribe using Mosquitto
• Raw HTTPS request over TLS
• Proxy connection with NTLM authentication

Each example is documented and tested on 32-bit and 64-bit Office.

A benchmarks folder has been added. It contains VBA routines that measure throughput, round-trip time, and connection setup. These are useful for tuning and for comparing environments.

A tests folder now holds unit tests for frame parsing, compression, MQTT packet handling, and other internal logic. The test suite is growing with each release.

The documentation in the docs folder has been reorganized. The API reference is clearer, error codes are explained, and an architecture overview has been included.

A quick example using WebSocket and MQTT:

Dim h As Long

If WebSocketConnect("wss://test.mosquitto.org:8081/mqtt", h, False, True, "mqtt") Then
    MqttConnect "wasabi-client", h
    MqttSubscribe "sensors/temperature", 0, h
    
    Do While WebSocketIsConnected(h)
        Dim msg As String
        msg = MqttReceive(h)
        If msg <> "" And Left(msg, 1) <> "[" Then
            Dim parts() As String
            parts = Split(msg, "|", 2)
            Debug.Print parts(0), parts(1)
        End If
        DoEvents
    Loop
    
    MqttDisconnect h
    WebSocketDisconnect h
End If

A bug reported by fafalone (a crash on 32-bit Office) was fixed within hours of the original post and the patch is already in main.

The module remains a single .bas file with no references, no DLLs, and no registration. It works from Windows XP to Windows 11, in any VBA host.

Github: https://github.com/uesleibros/wasabi

Release v2.3.2-beta: https://github.com/uesleibros/wasabi/releases/tag/v2.3.2-beta

I would be glad to hear about your use cases, questions, or ideas.

It's worth highlighting that I really liked the community's reception; I believe this project will become increasingly solid and have a great user base over time.