Cabbage Logo
Back to Cabbage Site

Future directions for Cabbage

#1

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:

13 Likes
#2

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!

#3

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!

2 Likes
#4

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.

#5

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:

#6

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.

#7

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

#8

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.

#9

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!

#10

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.

#11

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.

#12

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

#13

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
#14

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 :slight_smile: I’m really excite to see what people come up with.

1 Like
#15

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?

#16

Yeah, maybe, em :rofl: 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…

#17

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.

#18

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.

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

#19

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!)

#20

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.