u/Swimming_Contest_349

Just found that video. How do you feel, is it anywhere similar to original Virus sound ?

A couple of years ago I started writing controller scripts for Bitwig.

It wasn't supposed to become a hobby. I just wanted to make my controller behave the way I wanted. One script became two. Then I started reverse engineering hardware protocols, rebuilding vendor scripts, experimenting with different interaction models. Somewhere along the way I realized I was spending almost as much time with the Controller API as I was actually making music.

And strangely enough, I enjoyed it.

Lately I've been working on my own controller script for the Nektar Aruba, and that's probably what finally pushed me to write this post.

The Aruba is a great piece of hardware. The pads feel fantastic, the build quality is solid, and there's clearly a lot of potential. But that potential is almost entirely locked behind Nektarine. Without it, Aruba is essentially reduced to a generic MIDI pad controller. In real-world use, despite the excellent hardware, it isn't fundamentally more capable than a random $50 pad controller from AliExpress.

That isn't really Nektar's fault, either. They built their own ecosystem because they had to. If you want deep integration, you end up writing software that works around the DAW instead of working with it.

While developing the Aruba script, I kept running into the same realization: the controller wasn't the limiting factor. My script wasn't the limiting factor. The Controller API was. Time after time, I'd find a Bitwig feature that already existed, only to discover there was simply no way to access it from a controller. That's when it stopped feeling like isolated omissions and started feeling like an architectural limitation.

There was something exciting about the idea that your hardware didn't have to be whatever the manufacturer imagined. You could make it yours. Build your own workflow. Remove friction. Make the computer disappear.

At least, that was the dream.

The first few obstacles didn't bother me. Every API has limitations. You work around them, move on, and keep building.

But after the tenth... the twentieth... the fiftieth workaround, something started feeling wrong. I'd have an idea for a feature, open the API docs, and find... nothing. Then I'd discover Bitwig itself already had exactly that functionality. Not hidden. Not experimental. Just... unavailable.

One example that still annoys me is selection.

Bitwig has actions called Extend Selection Up and Extend Selection Down. Exactly what I needed for a controller. Except they don't exist in the Controller API. The closest thing you get is Select Next and Select Previous. That sounds like a tiny omission until you realize what it means: a hardware controller simply cannot reproduce something Bitwig itself already does.

Not because the controller is incapable. Not because it's technically difficult. Simply because there's no path to it. At first I assumed I was missing something. Then I found another case. Then another.

Eventually I stopped looking for solutions and started asking a different question:

"Is this another mouse-only feature?"

And that's when I realized I'd been fighting the same problem all along. It feels like there are two different Bitwigs. There's the Bitwig you use with a mouse. And there's the Bitwig the Controller API is allowed to see.

Sometimes those two worlds overlap. Sometimes they don't.

Clicking something in the UI doesn't always mean your controller knows about it. Actions exist in menus but not in the API. Objects exist on screen but have no representation for controller developers.

The biggest reminder of this, for me, is automation. You can record automation from hardware all day long. That's easy. But try editing it: Automation lanes, Automation points, Curve handles, Segments, Selections.

From the perspective of the Controller API, most of that world simply isn't there.

So once again, your hand leaves the controller...and reaches for the mouse.

After enough projects, you stop noticing individual limitations. Instead, you notice the pattern.

The mouse is always the escape hatch. There's always one last thing that only the mouse can do.

I've been a software engineer for more than ten years. I have no idea what Bitwig looks like internally, and I'm not going to pretend I do. But I've worked on enough large systems to recognize a familiar smell. It doesn't feel like the UI is built on top of the same public API that controller developers receive. It feels like there are parallel paths through the application.

One for Bitwig itself.

One for everyone else.

And when software grows that way, those paths tend to drift further apart over time. Maybe that's not what's happening here. I genuinely hope it isn't.

Because I love Bitwig.

I wouldn't have spent hundreds of hours writing controller scripts for a DAW I didn't love.

That's probably the most frustrating part of all. Every time a new version comes out, I don't just wonder what features were added. I wonder whether this release finally lets controllers do one more thing without reaching for the mouse.

Usually, the answer is no.

People often point to DrivenByMoss, and rightly so. It's an incredible achievement. I honestly think Joerg has taken the Controller API further than anyone thought possible.

But that's also proof of the problem.

If someone with that much experience keeps running into the same walls, maybe the walls are real. I still think Bitwig is one of the most innovative DAWs available today. I just wish its Controller API felt like part of the same vision.

Because every time I sit down to build something new, I start with excitement...

...and eventually end up asking the same question:

"So... where does the mouse become mandatory this time?"

---

One thing this experience has changed for me is how I answer the question, "What's the best controller for Bitwig?" A year ago, I would have started comparing hardware. Better pads, better encoders, tighter integration, more polished scripts, vendor support... Today, I think that's the wrong question.

Because after spending so much time inside the Controller API, I've come to believe that the controller usually isn't the limiting factor. Neither is the manufacturer. Neither is the person writing the integration. Sooner or later, everyone runs into exactly the same ceiling.

So the next time someone asks, "What's the best hardware controller for Bitwig?", my answer will probably be: "Whichever one you like the most."

Because once you've reached the limits of the public API, it doesn't really matter whether you're holding a $50 MIDI pad from AliExpress or a beautifully engineered flagship controller with years of vendor development behind it. They all become constrained by the same architectural boundaries.

I hope I'm wrong.

I hope one day Bitwig embraces controllers as first-class citizens, exposing the same capabilities to developers that its own UI already enjoys. Because right now, after hundreds of hours writing controller scripts, it doesn't feel like Bitwig was designed around the idea that someone might want to leave the mouse on the desk.

Hey, finished an EP recently and wanted to throw it here for feedback.

It’s mostly melodic dnb-inspired stuff, but not really focused on super chaotic break chopping or sample-heavy oldschool style. All drums are programmed from scratch and I tried to put more attention into atmosphere, harmony, progression and overall flow between sections.

Would appreciate feedback on:

• mix
• drum programming
• arrangement
• whether the tracks evolve enough
• overall vibe/cohesion

I’m also very interested in negative feedback, things that don’t work, or ideas on what could be improved/pushed further. Don’t really need polite approval — useful criticism is way more valuable.

I know it sits a bit outside more “traditional” jungle approaches, but that was kinda the point.

Link:

https://distrokid.com/hyperfollow/synthronauta/buscando