# Future directions for Cabbage

**URL:** <https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358>\
**Category:** Announcements\
**Created:** [21 May 2024 14:11 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358 "2024-05-21T14:11:08Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [21 May 2024 14:11 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/1 "2024-05-21T14:11:08Z")

</div>

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. 🙂

---

<div class="post-metadata">

**Author:** ![giovannibedetti](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/giovannibedetti/32/4146_2.png) [@giovannibedetti](https://forum.cabbageaudio.com/u/giovannibedetti)\
**Post date:** [21 May 2024 14:41 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/2 "2024-05-21T14:41:56Z")

</div>

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

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!

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [21 May 2024 14:55 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/3 "2024-05-21T14:55:26Z")

</div>

> [@giovannibedetti](#):
>
> A Cabbage plugin for VS Code is pure gold, it saves you from maintaining an entire IDE, which is super painful I guess 😅

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!

> [@giovannibedetti](#):
>
> On Unity, given the future switch to UI Toolkit (“inspired by standard web technologies”)

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!

---

<div class="post-metadata">

**Author:** ![iainmccurdy](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/i/8baadc/32.png) [@iainmccurdy](https://forum.cabbageaudio.com/u/iainmccurdy)\
**Post date:** [21 May 2024 20:39 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/4 "2024-05-21T20:39:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [21 May 2024 21:31 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/5 "2024-05-21T21:31:26Z")

</div>

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 🙂

---

<div class="post-metadata">

**Author:** ![nymano](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/nymano/32/4711_2.png) [@nymano](https://forum.cabbageaudio.com/u/nymano)\
**Post date:** [22 May 2024 07:31 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/6 "2024-05-22T07:31:51Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![taime](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/taime/32/5256_2.png) [@taime](https://forum.cabbageaudio.com/u/taime)\
**Post date:** [22 May 2024 22:16 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/7 "2024-05-22T22:16:20Z")

</div>

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](https://github.com/hlolli/csound-mode)

Regard,  
taime

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [23 May 2024 08:29 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/8 "2024-05-23T08:29:12Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![spruitje](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/s/5fc32e/32.png) [@spruitje](https://forum.cabbageaudio.com/u/spruitje)\
**Post date:** [26 May 2024 06:20 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/9 "2024-05-26T06:20:08Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![severak](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/severak/32/1517_2.png) [@severak](https://forum.cabbageaudio.com/u/severak)\
**Post date:** [28 May 2024 12:40 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/10 "2024-05-28T12:40:32Z")

</div>

As I have also created [music software in javascript](https://severak.github.io/cyber-music-studio/) 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](https://github.com/severak/cyber-music-studio/issues/13).

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [28 May 2024 13:15 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/11 "2024-05-28T13:15:19Z")

</div>

> [@severak](#):
>
> Does this means browser embedded in VST plugin or this is some DLL magic?

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

> [@severak](#):
>
> I also like drag and drop ability of Cabbage, but I can imagine using HTML instead.

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

> [@severak](#):
>
> Javascript has poor timers and [weird concurrency bugs](https://github.com/severak/cyber-music-studio/issues/13).

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

---

<div class="post-metadata">

**Author:** ![ST\_Music](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/st_music/32/4405_2.png) [@ST\_Music](https://forum.cabbageaudio.com/u/ST_Music)\
**Post date:** [29 May 2024 02:09 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/12 "2024-05-29T02:09:14Z")

</div>

@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?

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [29 May 2024 10:11 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/13 "2024-05-29T10:11:58Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [20 June 2024 09:18 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/14 "2024-06-20T09:18:48Z")

</div>

I’m conducting an audit of sorts for the current set of Cabbage widgets. I’m considering if some can be dropped due to lack of use, or better alternatives. The two that are popping out at me for now are:

**`signaldisplay`**  
I’m inclined to drop this as the new version of the gentable is very performant and can be used in place of it. Also, the Csound API is changing so I’m not sure the underlying graph functions will continue to be exposed.

**`soundfiler`**  
I’m not sure how best to handle this one. It was offered as more performant alternative to gentable. But with the way things are going now there will be no difference in performance between one of these and a gentable. It did have some nice features for zooming, and the option of selecting sections of waveforms. I know @iainmccurdy made great use of it in his file player/processing examples. It might be best to consolidate this with gentable?

* * *

In other news, I’ve made it extremely easy to create custom widgets in Cabbage 3, without having to compile any source code. New users can use existing identifiers such as `colour(), text(), bounds()`, etc, or define new identifiers such as `levelOfAwesomeness()` and `revenueSliderValue()`. Each newly defined identifier can be queried with a `cabbageGet` and updated in realtime with a `cabbageSet`. It’s going to be highly configurable 🙂 I’m really excite to see what people come up with.

---

<div class="post-metadata">

**Author:** ![iainmccurdy](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/i/8baadc/32.png) [@iainmccurdy](https://forum.cabbageaudio.com/u/iainmccurdy)\
**Post date:** [20 June 2024 10:38 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/15 "2024-06-20T10:38:04Z")

</div>

Don’t let me stand in the way of progress!

I’m assuming that the new `gentable` will display sound files sent to it as strings without the need to load them into function tables?

Is there going to be a new-and-improved `xypad`?

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [20 June 2024 12:11 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/16 "2024-06-20T12:11:58Z")

</div>

> [@iainmccurdy](#):
>
> I’m assuming that the new `gentable` will display sound files sent to it as strings without the need to load them into function tables?

Yeah, maybe, em 🤣 Because I’m no longer using JUCE I don’t have the same array of tools at my disposal. So I would need to either writing a robust soundfile reader myself, or use something like libsndfile. The other issue is that because the new UI is running in a browser, it doesn’t actually have access to local files. The solutions for this are to add the files to the server directory, the one your index.html file lives in, or open them using native OS methods and send the data back to the UI which Cabbage will do automatically.

As for the xypad, yeah, should be simple to throw something together. The problem is the automation. This has always been a pita because ti has to keep going even after the UI has closed. It’s something that could be handled very easily on the Csound side. On a mouse release a Euchlidean vector could be sent. That would give use direction and magnitude. With that it would be trivial to do the rest.

What about the selection of waveforms, how attached are you to that? I might put if on the todo list for phase 2..

---

<div class="post-metadata">

**Author:** ![iainmccurdy](https://forum.cabbageaudio.com/letter_avatar_proxy/v4/letter/i/8baadc/32.png) [@iainmccurdy](https://forum.cabbageaudio.com/u/iainmccurdy)\
**Post date:** [20 June 2024 12:59 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/17 "2024-06-20T12:59:42Z")

</div>

I’d have to say that I am quite attached to the ability to browse for files so I’m beginning to think I may need to go through some sort of therapy as I transition to Cabbage III. Actually, it’s more for composition students who are non-Csound programmers and find it invaluable to be able to access Csound power and pass their source sounds through it. My request for REC in the standalone Cabbage was a response to this sort of user and they shouldn’t be undervalued.

Hopefully Cabbage II will continue to function without updates for a while as Cabbage III beds in.

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [20 June 2024 16:01 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/18 "2024-06-20T16:01:01Z")

</div>

> [@iainmccurdy](#):
>
> I’d have to say that I am quite attached to the ability to browse for files

You can already browse for files with Cabbage 3. I have you covered in that regard. It was your comment about sending a file path to a gentable that has me thinking. The simplest thing (for me) would be to let users browse and load a file to a function table and then update the `gentable`.

> [@iainmccurdy](#):
>
> My request for REC in the standalone Cabbage was a response to this sort of user and they shouldn’t be undervalued.

I agree. I’ll have to think about how best to integrate this with VS-Code.

---

<div class="post-metadata">

**Author:** ![rorywalsh](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/rorywalsh/32/165_2.png) [@rorywalsh](https://forum.cabbageaudio.com/u/rorywalsh)\
**Post date:** [20 June 2024 21:42 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/19 "2024-06-20T21:42:32Z")

</div>

I have things in place now whereby if you send `file("myFile.wav")` to a `gentable` widget it will either replace or create a table according to `tableNumber()`. This seems like a good solution, but perhaps I’m missing something?

I’ve been thinking about zooming too. This is a little tricky because the UI doesn’t have access to all of the audio samples. Enough samples are sent in order to display a nice waveform, but sending every single sample would be quite slow. If users hit a zoom button, the UI will need to communicate with Csound, and then retrieve the required samples. It might be simpler to mange this from Csound, and send whatever range of samples you wish to display, be it a section in the middle of an existing function table, or the entire thing. Oh, I’ll not be putting any time into the editable function table stuff. That’s an exercise for someone else. It near broke my heart the last time, and I don’t think the the functions I used are going to make it into the Csound 7 API (probably for good reason!)

---

<div class="post-metadata">

**Author:** ![Bryan\_T](https://forum.cabbageaudio.com/user_avatar/forum.cabbageaudio.com/bryan_t/32/5680_2.png) [@Bryan\_T](https://forum.cabbageaudio.com/u/Bryan_T)\
**Post date:** [21 June 2024 04:28 UTC](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358/20 "2024-06-21T04:28:06Z")

</div>

I don’t really understand how JUCE fits together with Cabbage. In my mind, JUCE is to C++ as Cabbage is to CSound. But I’m guessing that isn’t right.

[Next page](https://forum.cabbageaudio.com/t/future-directions-for-cabbage/4358.md?page=2)
