oceanwaves

I wonder how this will work for third-party providers' enterprise customers. E.g. Vertex, Bedrock

Yes, that's what I'm finding too. There seems to be a concerted promotional pricing campaign tied to M3's release across providers. Since their differences are subtle, it makes a lot of sense to fan-out to M3.

GLM 5.2 edges as the safer pick when tasks are more challenging from-scratch builds and the result needs to arrive as a complete, runnable project. MiniMax M3 is the value pick for a lot of worker traffic.

This submission's reference URL is not affiliated with Nous Research

This was not a pleasant experience to register with and evaluate. Nowhere is a Linux-deployable harness mentioned. It seems to be a Perplexity-like offering.

On top of that, users logging in with Google OIDC cannot delete their accounts. Eve asks for the login password to confirm account deletion. Broken.

Even in my plugins, I don't actually use JUCE DSP primitives. It's mostly a product shell and distribution framework, two things I have no need for in this codebase.

I've actually fixed the page based on your feedback. Not sure why you continue to be bothered by my open source hobby's landing page.

https://brume.aftertone.co/lcxl3.png

Cheers.

Yeah, I understand the lens through which you're probably evaluating this. Wouldn't be for you.

I wanted to design, learn, build, and have fun with something physical on my desk that I could swipe, turn, twist, and make sounds with.

https://brume.aftertone.co/lcxl3.png

Just a hobby project I'm sharing.

Oh man, the prices of these components have skyrocketed since I began this project. It has been depressing to watch.

Yeah that's by design, and kind of a nifty byproduct. The demo tune on the landing page was actually generated by the DSP engine running on macOS. For me, it's mostly a development aid but you can use it that way if you wanted.

Just wasn't part of the motivation. I wasn't looking for another standalone macOS app or VST. Wanted something tactile (controller I already have muscle memory with) and a touchscreen UI.

For the DAW-less use case, I actually prototyped this with a DAC hat before deciding to go the Overbridge route. I might resurrect that support some day...

It should run ok on a CM4, but with some limitations.

Less DSP headroom; swatcoder's optimization suggestions in this thread become more important. Simultaneous 4-part polyphony might push things. You'd probably want at least a 4GB board.

Also, the brumectl installer will not attempt to set up the USB audio/MIDI bridge (Meridian) on a CM4. That auto-configures only on a CM5 for now.

Would be a pretty light lift to get that working if you are interested.

I do distribute VST/AU plugins that are built with JUCE, but this is an application that runs on the Raspberry Pi platform.

And yeah, line-out audio on a Pi is a non-starter.

This was really designed to be surfaced in a DAW via USB.

Thanks, I'll try to improve the reader experience.

The copy makes it pretty clear this is firmware for a CM5.

Rest assured, if you click the "READ THE MANUAL" button on the landing page you will see screenshots of all synth engines and configuration screens.

The repo's README also starts with a screenshot.

Thanks.

A -ton-

No hesitation to enthusiastically share that it was actually a parallel goal to see just how deeply I could go while keeping it stable, performant, and extensible for the long term.

I ended up building a lot of ancillary agent infrastructure to push the determinism in all the fanned out work slices, too.

https://thinkwright.github.io/threadmark/

Also: https://brume.aftertone.co/develop.html#agents

Exactly the kind of feedback I'm looking for, since this is an educational, hobby-class project for myself. I'm just treating the development of it formally as a product to stay disciplined.

Make no mistake, I'm not promoting this thing like a product, though. I'm aware there's a big gulf between this and a commercialized purpose-built product.

That said, there is a ton of headroom right now on the 8GB CM5 reference platform and I felt some of these optimizations were overkill in this pre-1.0 phase. The FX bus is already block-based, but the voice synthesis path remains pretty simple. Some of the block scaffolding for the better approach exists and I'll plan to evolve in that direction.

Thank you.

Hey, thanks. Kind of obsessed over that demo for too long.

The Rust engine underneath isn't even Pi-locked. It'll run on macOS/Linux, but the touch UI and USB-audio bridge is device specific so it would be fairly useless.

You might be over-indexing on "build this". It's actually just slapping a few 1-click shopping parts together and running two commands in your shell to have a playable instrument.

I've got a vague idea to maybe pull the FM engine out some day since I love having a DX-style synth that actually has a filter, but my plugin work is generally focused on effects processing and not voicing, so I dunno...

I wanted another multi-part hardware synth, so I thought it would be fun to see what I could come up with using the parts I already had, particularly the touchscreen.

Loosely inspired by Norns, Brume is a four-part multi-timbral synthesizer that runs on a Raspberry Pi Compute Module 5. It has four synth engines and six voices per part, a shared filter section feeding an effects chain, a sandboxed Lua scripting layer, and a 10.1-inch touchscreen UI. A single USB cable presents the device to a host computer as a class-compliant audio and MIDI interface ala Elektron Overbridge.

Quick BoM to get started: cm5+carrier, any of the endless 10-inch hdmi touchscreens for RPI, and a midi controller. Novation Launch Control XL 3 and Korg nanoKONTROL2 are supported out-of-the box.

* While you can run this on a Raspberry Pi 5, Pi 5s don't expose USB OTG. The carrier board is what makes the class-compliant Audio+MIDI over USB work.

I hope this can be fun for others!

https://brume.aftertone.co https://github.com/aftertonesignal/brume

In my building and research of Simplex, specs designed for LLM consumption don't need a formalized syntax as much as they just need an enforced structure, ideally paired with a linter. An effective spec for LLMs will bridge the gap between natural language and a formal language. It's about reducing ambiguity of intent because of the weaknesses and inconsistencies of natural language and the human operator.

I've been working on re-imagining the useful parts of Antigravity (Agent Manager) into an orchestrator that is tightly coupled with an LLM-optimized spec: https://thinkwright.ai/plexus

Early days and would appreciate any feedback

Not a language, but we are having very good success using https://brannn.github.io/simplex/ for autonomous one-shot workflows. It seems to be a very high-fidelity input for LLMs.