ACP support would be a big deal and would make this a real contender for me. It looks super nice, but the idea of re-writing my Pi plugins is a real blocker.
I’m generally happy with my agent and want to keep that, but I do think the UI could be better and this looks like a neat step that way.
Nothing to say regarding this release, but thanks so much for creating Tracktion (first DAW I ever used back in 2006) and JUCE (I love and use many audio plugins created with it)! Have a great day!
This looks cool! I'll check it out. Out of curiosity: I assume you've also used agents to help build this, and on the site you mention working on this for ~6 months. Most one-man projects I see that use ai seem to focus on creating and presenting a concept as soon as possible
(to a lot of people I think the main benefit of stuff like vibing is that you really quickly get something that you can have others test out).
On the site you also mention being pretty opinionated about the tools you use / build, which I imagine is part of the reason why you spend more time on this before releasing it. What was your experience using ai to build a larger project with a very specific idea / taste in mind?
I must have authored literally a million lines of C++ over my career, and done many talks about clean coding, etc.. But in this one I quite appropriately wrong almost zero lines by hand!
Surprisingly, I've really enjoyed the experience. I have friends who lament that they probably won't be hand-writing code much more, but although I've always loved the craft of coding, I discovered that a lot of the fun I get is just in the end result, not how I got there.
But TBH I think a lot of the GUI agent tools so far have been pretty much terminal apps wrapped in a thin GUI layer, which is why they don't seem to add any value over just doing the same UX in a terminal
UI is clean. could install in Mac. Adding context files at the top is clean. It worked.
Currently I use zed, vscode (for UI). along with claude, codex, Hermes.
Not sure If I will continue to use. But I see it is a clean and good UI, and integrating to my exiting cli's. All the best.
Thanks! I think hearing "the UI is clean" is exactly the reaction I've been hoping for :)
While I've put huge effort into things like its architecture and extension API, it's really trying to just build a lovely UI/UX that has been my motivation on this.
Out of curiosity, did you use JUCE to build this? Were there any interesting gotcha's you encountered along the way?
I've settled on JUCE as my cross-platform app framework (not just plugins) of choice, so it'd be interesting to hear about your experience with building this app out .. could you tell us a bit more about the architecture and any impactful decisions you made along the way with regards to tooling/integration? Is there now a juce-go-module or something like that, which you've wired up to JUCE' web view functionality?
Ah, very interesting! I'm a little disappointed, but it's understandable.
Well, my first run wasn't very pretty .. installed it on a MacBook Air M5 with 16Gigs of RAM, set it up to access the local ollama instance (because I'm cheap like that), gave it a local JUCE app with a prompt to "analyze the project for issues porting from 32-bit to 64-bit" .. plugged in the laptop as it started processing, and then the system froze. I guess Juggler doesn't like display/USB enumeration events while its busy having ollama chug up all the resources .. well, that produced a system crash .. so came back, set it all back up again, and was .. after a few minutes .. told "the 'ls' tool is not available on this system" .. hmm .. I guess I might have missed a few setup steps in my rush to get it cranking on my JUCE project ..
In any case, will tinker with it some more, looks really great and a nice way to organize AI into a functional UI - especially better than some of the other things I've been using lately (hermes, mostly..) ..
Hmm, that's odd. Would like to dig into that more if you can find any more clues about what went wrong. Feel free to message me if you want to discuss it
The 'ls' problem is me just being a dufus and not setting up ollama to have tool access .. but I can confirm that plugging/unplugging my laptop into a USB-C hub (to get another monitor and keyboard/mouse) seems to plague Juggler in such a way that the system reboots, and only while it is actively engaged in an ollama connection, answering a prompt. Maybe its a resource issue - this is not the fattest machine for the job, after all.
At the moment it uses a GTK webview for running server-side javascript, so it's needed right now. At some point I'll see if I can find a JS engine that I could swap in there
Just wanted to add a follow-up to what I posted above..
In terms of who might be interested in this: I've watched amazing communities spring up around open agents like Opencode and Pi. People are getting into those because of their extensibility and being model-independant. They're great projects, but like many people I know, I really hate being stuck in the terminal for this kind of tool. I also had some ideas around what an agent's UX could be like if every item in the context was a plugin (with its own custom UI).
So I guess if you're a claude/codex user but want to escape the terminal (and let's face it, their GUI apps are also basically the same UX as a terminal but with nicer fonts), I'm trying to do something different here, would be really keen to hear what the enthusiasts think of it!
First of all, it's so cool to see you on HN and creating this. I'm not sure how much the HN community is aware of this, but JUCE is the standard for cross platform music plugin development and needs to work efficiently in hard realtime settings. Many of my favorite plugins are JUCE based (such as the Valhalla stuff) and I'm a huge fan. Tracktion is a great DAW as well that I got a lot of mileage of in my younger days (ended up with Renoise because I'm a tracker guy after all long term).
I mention all this to say someone like you picking up the desire to build an agentic platform really piques my interest. Right now I am using Opencode for most of the stuff I am trying to do at $WORK and it does a good job on the whole at having sufficient functionality. But the release pace is blistering and it does feel bloated - both in terms of functionality as well as system prompts.
Moreover, I observed all of the same issues you mentioned and certainly wanted more of a tree like experience as well as a more UI forward experience. In order to get the functionality I wanted (good worktree support, sandboxing, etc) I eventually just had to let go of using opencode's UI and embrace the TUI because it was the only thing I could embed into a workflow that let me set up all of that in a sane manner. But problems still remain with the "doom scroll" experience when to your point clearly a tree based experience would be better.
I was ready to just settle with my cobbled together opencode flow and maybe migrate to Pi later on and just accept i'd have to roll my own GUI harness for my nontechnical team members. But seeing what you've put together so far (and knowing it's you who wrote it so I'm probably going to just see a step function level better quality in architecture/efficiency) is going to make me reassess in a good way. Some things that I'll be considering:
- Worktree support
- Sandbox support
- Skills/subagent handling
- Hashline based editing (feel like this is a huge part of why
people get better results from pi/omp over opencode/codex/claude code)
- Ability to customize tool calls + have rich embeds
- Web UI support (if i'm building this out for team members, native GUI can get messy and web client is ideal)
- Long horizon efficiency (IE i regularly get to 200k-400k context length sessions; while the model handles it fine, opencode gui will get laggy while the tui keeps chugging along)
For a lot of this stuff, it's less critical that all of this works perfectly out of the box and more critical that the architecture makes it easy to build (ie as with Pi ecosystem). What I'm after long term is something a bit like https://github.com/ColeMurray/background-agents in capability but without the overly tight coupling and design decisions that product has made.
The way I want to get there is to find the right base (whether that's Pi, OpenCode, or your project Juggler) and build the background agent harness layer. Previously it was just Pi and OpenCode and neither was really perfect (GUI story was probably the weakest for both) but it's great that I have another option to diligence that might actually be a better fit for what I'm trying to do.
Excited to see how this develops and kick the tires on it myself. The tree paradigm feels like the killer feature to me; not sure of anything else besides pi/omp that has it.
I've got things like worktree/sandboxing/skills on my TODO list.
I'd heard of hashline based editing - I will dig into that, and it's probably easy to add, though TBH I've not had any hassle with the editing tools so far.
If you get stuck into customising tool calls + their UIs, would love to hear how you get on, as that's one of the big goals for this. I've implemented all the built-in tools as plugins so hopefully it'll cover everything you need.
In terms of long-horizon stuff, yes, I also often hit 3-400k and haven't had any issues, but let me know if you spot anything untoward
"No electron" is more about avoiding bloat and dependencies.
I come from a hardcore, real-time C++ background and the idea of a product not being a single self-contained binary is just too far for me to go!
(But I don't think the choice of JS back-end should make the slightest difference to anyone using this. I could swap electron in there in the future and probably no-one would notice)
I’m generally happy with my agent and want to keep that, but I do think the UI could be better and this looks like a neat step that way.
On the site you also mention being pretty opinionated about the tools you use / build, which I imagine is part of the reason why you spend more time on this before releasing it. What was your experience using ai to build a larger project with a very specific idea / taste in mind?
Surprisingly, I've really enjoyed the experience. I have friends who lament that they probably won't be hand-writing code much more, but although I've always loved the craft of coding, I discovered that a lot of the fun I get is just in the end result, not how I got there.
Got fed up with Zed, Cursor, and the other GUI agentic tools and created a console TUI agent for my own use.
But TBH I think a lot of the GUI agent tools so far have been pretty much terminal apps wrapped in a thin GUI layer, which is why they don't seem to add any value over just doing the same UX in a terminal
While I've put huge effort into things like its architecture and extension API, it's really trying to just build a lovely UI/UX that has been my motivation on this.
I've settled on JUCE as my cross-platform app framework (not just plugins) of choice, so it'd be interesting to hear about your experience with building this app out .. could you tell us a bit more about the architecture and any impactful decisions you made along the way with regards to tooling/integration? Is there now a juce-go-module or something like that, which you've wired up to JUCE' web view functionality?
There's no c++ in it, it's all Go/Javascript. And all the UIs are HTML. JUCE is a great choice for some things, but this wasn't one of them!
Well, my first run wasn't very pretty .. installed it on a MacBook Air M5 with 16Gigs of RAM, set it up to access the local ollama instance (because I'm cheap like that), gave it a local JUCE app with a prompt to "analyze the project for issues porting from 32-bit to 64-bit" .. plugged in the laptop as it started processing, and then the system froze. I guess Juggler doesn't like display/USB enumeration events while its busy having ollama chug up all the resources .. well, that produced a system crash .. so came back, set it all back up again, and was .. after a few minutes .. told "the 'ls' tool is not available on this system" .. hmm .. I guess I might have missed a few setup steps in my rush to get it cranking on my JUCE project ..
In any case, will tinker with it some more, looks really great and a nice way to organize AI into a functional UI - especially better than some of the other things I've been using lately (hermes, mostly..) ..
In terms of who might be interested in this: I've watched amazing communities spring up around open agents like Opencode and Pi. People are getting into those because of their extensibility and being model-independant. They're great projects, but like many people I know, I really hate being stuck in the terminal for this kind of tool. I also had some ideas around what an agent's UX could be like if every item in the context was a plugin (with its own custom UI).
So I guess if you're a claude/codex user but want to escape the terminal (and let's face it, their GUI apps are also basically the same UX as a terminal but with nicer fonts), I'm trying to do something different here, would be really keen to hear what the enthusiasts think of it!
I mention all this to say someone like you picking up the desire to build an agentic platform really piques my interest. Right now I am using Opencode for most of the stuff I am trying to do at $WORK and it does a good job on the whole at having sufficient functionality. But the release pace is blistering and it does feel bloated - both in terms of functionality as well as system prompts.
Moreover, I observed all of the same issues you mentioned and certainly wanted more of a tree like experience as well as a more UI forward experience. In order to get the functionality I wanted (good worktree support, sandboxing, etc) I eventually just had to let go of using opencode's UI and embrace the TUI because it was the only thing I could embed into a workflow that let me set up all of that in a sane manner. But problems still remain with the "doom scroll" experience when to your point clearly a tree based experience would be better.
I was ready to just settle with my cobbled together opencode flow and maybe migrate to Pi later on and just accept i'd have to roll my own GUI harness for my nontechnical team members. But seeing what you've put together so far (and knowing it's you who wrote it so I'm probably going to just see a step function level better quality in architecture/efficiency) is going to make me reassess in a good way. Some things that I'll be considering:
- Worktree support
- Sandbox support
- Skills/subagent handling
- Hashline based editing (feel like this is a huge part of why people get better results from pi/omp over opencode/codex/claude code)
- Ability to customize tool calls + have rich embeds
- Web UI support (if i'm building this out for team members, native GUI can get messy and web client is ideal)
- Long horizon efficiency (IE i regularly get to 200k-400k context length sessions; while the model handles it fine, opencode gui will get laggy while the tui keeps chugging along)
For a lot of this stuff, it's less critical that all of this works perfectly out of the box and more critical that the architecture makes it easy to build (ie as with Pi ecosystem). What I'm after long term is something a bit like https://github.com/ColeMurray/background-agents in capability but without the overly tight coupling and design decisions that product has made.
The way I want to get there is to find the right base (whether that's Pi, OpenCode, or your project Juggler) and build the background agent harness layer. Previously it was just Pi and OpenCode and neither was really perfect (GUI story was probably the weakest for both) but it's great that I have another option to diligence that might actually be a better fit for what I'm trying to do.
Excited to see how this develops and kick the tires on it myself. The tree paradigm feels like the killer feature to me; not sure of anything else besides pi/omp that has it.
I've got things like worktree/sandboxing/skills on my TODO list.
I'd heard of hashline based editing - I will dig into that, and it's probably easy to add, though TBH I've not had any hassle with the editing tools so far.
If you get stuck into customising tool calls + their UIs, would love to hear how you get on, as that's one of the big goals for this. I've implemented all the built-in tools as plugins so hopefully it'll cover everything you need.
In terms of long-horizon stuff, yes, I also often hit 3-400k and haven't had any issues, but let me know if you spot anything untoward
Cool project actually, but I noticed the author said "No Electron" as if Electron is synonymous with JavaScript.
My biggest concern about it actually is using Go to render web front-ends in HTML/CSS hahah so I'm not sure "No electron" is selling me.
I come from a hardcore, real-time C++ background and the idea of a product not being a single self-contained binary is just too far for me to go!
(But I don't think the choice of JS back-end should make the slightest difference to anyone using this. I could swap electron in there in the future and probably no-one would notice)