Cabbage Logo
Back to Cabbage Site

Future directions for Cabbage

A few weeks ago JUCE announced some major changes to their EULA. It caused quite some uproar among the audio developer community. They have rolled back on some of the changes but it still leaves a bad taste. If JUCE were to further change their license terms, and some day get rid of the GPL version Cabbage would be in a very precarious position.

With this in mind I’ve started looking at redesigning Cabbage from the ground up, without JUCE. Rewriting the entire system would be a mammoth task, it’s simply not feasible. But I’m excited about the idea of redesigning it and delivering a better, more streamlined version of Cabbage for the future. Much of the design is still be worked out but there are two things that I’m almost certain to.

  1. Integrate the IDE into VS Code
  2. Switch to HTML/CSS/JS for plugin UIs

The end-user experience will remain largely unchanged: the Cabbage syntax will persist, users will retain access to a wide array of widgets, and will still be able to export to all popular plugin formats. The bulk of the new work will occur behind the scenes. I’m sure it will lead to a much more sustainable software, and I’m also pretty sure I will be able to get much performance out of it too. I’ll keep you posted on progress. I hope to showcase a good working prototype at this year’s Csound conference in Vienna. :slight_smile:

10 Likes

That’s bad, but also good to hear! :open_mouth: :partying_face:
A Cabbage plugin for VS Code is pure gold, it saves you from maintaining an entire IDE, which is super painful I guess :sweat_smile:

And having the UI based on HTML will add more portability (maybe CsoundQt widgets could be used/imported too).
On Unity, given the future switch to UI Toolkit (“inspired by standard web technologies”) we could import the UI without having to parse the csd, it could be a HUGE advancement!

So keep up the good work, and let me know if I can help in any way!

Exactly, the IDE and the widgets make up about 2/3rds of the code base. Replacing them seems like too good an opportunity to pass up!

I wasn’t aware of this, yes that would make life easier. The webview approach is gaining more and more interest across a lot of application. I don’t think it can match what can be done natively, but I think it’s a lot less work!

1 Like

Thanks for the announcement, Rory, but sorry to hear that this will probably involve a lot of work. I look forward to seeing the prototype.

Cabbage will prevail.

It’s a bit of work, but I’m excited about it. I hope to have versions for testing before Vienna, but let’s see :slight_smile:

Hi Rory,

Thanks for this update, and thanks for all the hard work on Cabbage!
I used the built in IDE for 10 months, and switched to VS Code. I think VS Code is a very nice solution and having a Cabbage plugin would be very nice.

I look forward to trying the new prototype. If you need beta testers don’t hesitate to send me a PM.

Hi Rory,

When you say VSCode, do you mean VSCodium? The last one has no telemetry functions and is really open source.
Why not start with Emacs which already has a Csound mode https://github.com/hlolli/csound-mode

Regard,
taime

vscodium or vscode. That’s up to the end user. I choose that flavor of editor because it’s very accessible to beginners, in comparison to other editors. However, It should be possible to port the extension to other editors down the road.

I don’t know about the details and have been busy with other audio programs and hardware lately, but it’s good to read that Cabbage will likely survive without Juce. Thanks and keep up the good work!

As I have also created music software in javascript I am now very interested in technical side of things. Does this means browser embedded in VST plugin or this is some DLL magic?

My experience is that CSound is good for writing DSP code but not so good for writing application logic. I also like drag and drop ability of Cabbage, but I can imagine using HTML instead. Javascript has poor timers and weird concurrency bugs.

It’s both. The plugin will use the platform native browser, safari, edge, etc, which is included by linking to the relevant framework library.

This will still be provided, but through a HTML interface.

No audio processing will be done on the JS side. No, that would be problematic for sure.

@rorywalsh If I’m not mistaken you had posted something mentioning HTML a while back with an example that had balls bouncing around. Is that right? If so was there any code with that?

Yes, it’s actually available now, but on the quiet. If you install the latest build you can open the WebUI example to check out how webviews can be embedded into your instrument.

1 Like