Cabbage Logo
Back to Cabbage Site

Future directions for Cabbage

#21

Cabbage is written in C++.

#22

Will Cabbage 3 still be able to generate standalone apps?

#23

Yeah, standalone applications will be supported again, along with all the other plugin formats. :+1:

2 Likes
#24

Sounds very exciting indeed.

#25

I have had a computer crash and am now in the process of reinstalling the audio software. Would it be better for me to wait for the new version of Cabbage before installing it again? Iā€™m not currently using Csound or Cabbage, but I plan to do so again some time in the future. But that may be months or a year from now.

#26

I hope that Cabbage wasnā€™t somehow the cause the crash :man_shrugging:

As to whether or not you should wait, itā€™s up to you. The instrument you develop with the current version should still run fine with the newer version. Some small things may need updating, but nothing major. So if you have some things you are keen to work on, Iā€™d say go ahead with the latest dev build :+1:

#27

The cause of the crash was that I had collected too much software on my computer. I have now minimized the software to those audio programs that I frequently use or at least plan to use in the foreseeable future. Thereā€™s so much fun stuff around, but one cannot seriously work with all of it. However I will keep Csound and Cabbage and a few more. :wink:

#28

Right? Itā€™s crazy.

#29

Just an update on this. Iā€™m slowly starting to work my way through all the widget examples that ship with Cabbage 2. Here you can see the property editor, and a Cabbage instrument actually running inside VS Code :wink:

9 Likes
#30

So you know the way that comboboxes start from 1 instead of 0ā€¦

This has always annoyed me. It was like this because JUCE used to populate the combobox with a default ā€˜selectā€™ item, and because 20 years ago I didnā€™t know how to get rid of it :rofl:

Now would be a good time to change to normal indexing? What do people thing? Remember this new behaviour would only affect new plugins, or those that were updated. Iā€™ll leave it at 1 for now, but maybe people can chime in with their thoughts.

#31

This too has also annoyed me mildly from the start. Iā€™m relieved to hear that it was a Juce initiative and not a Rory initiative. Humans count from 1, computers count from zero. Happy to see it changed and I will probably modify all examples where I use old-style comboboxes, tedious though that will be.

#32

Great. Btw, Iā€™m planning on updating all your examples. I donā€™t expect you to do that.

Btw, would it be worth adding a global identifier to specify count from 1 for combos, defaulting to 0. It would be a lot easier to add this simple flag to older instruments than having to rewrite everything?

#33

Ok, Iā€™m going to propose a somewhat radical idea now for Cabbage 3ā€¦

Currently, Cabbage code, i.e.,

button bounds(100, 28, 80, 80) channel("button1") text("Play", "Stop")

is stored internally as a JSON object, i.e.,

{"type": "button", "bounds": [100, 28, 80, 80], "channel": "button1", "text": ["Play", "Stop"]}

I find myself writing parsing functions that convert one representation to another. The thing is, the JSON version isnā€™t that far removed from the Cabbage version. If Cabbage used JSON syntax for its UI declarations, I wouldnā€™t have to write or maintain any parser. Plus, we would gain the ability to format our Cabbage code any way we like, without having to worry about breaking something. Weā€™d also adhere to a simple, albeit strict, set of well-defined rules that I canā€™t accidentally break with an ill-informed update.

I will provide scripts users can run on older code to convert their syntax to JSON if, for some reason, they want to re-release a plugin with Cabbage 3. Let me know what you all think.

3 Likes
#34

That seems like a smart choice to me.

1 Like
#35

I think itā€™s an excellent idea, and with json formatters weā€™ll be able to beautify the json definitions to have cleaner code (my Cabbage UI code is a bit messy now, so itā€™ll solve this issue)

1 Like
#36

Any issues with macro variables in the JSON stuff? Iā€™d really like to be able to define a color in one place and have it successfully populate everywhere. But also sizes that might be in a different macro.

#37

I havenā€™t given much thought to macros. But one thing that will be possible in the new version is the option to define your own defaults for any widget. The widgets are created using JSON text is readily accessible. For example, a numberbox/slider is defined as:

{
  "type": "nslider",
  "top": 10,
  "left": 10,
  "width": 60,
  "height": 60,
  "channel": "nslider",
  "min": 0,
  "max": 1,
  "value": 0,
  "skew": 1,
  "increment": 0.001,
  "index": 0,
  "text": "",
  "fontFamily": "Verdana",
  "fontSize": 0,
  "align": "centre",
  "textOffsetY": 0,
  "valueTextBox": 0,
  "colour": "blue",
  "fontColour": "#dddddd",
  "outlineColour": "#525252",
  "outlineWidth": 2,
  "decimalPlaces": 1,
  "velocity": 0,
  "popup": 1,
  "visible": 1,
  "automatable": 1,
  "valuePrefix": "",
  "valuePostfix": "",
  "presetIgnore": 0
}

Users can edit/modify these default values as they wish. They can even add new fields that can be accessed/modified within Cabbage. I think this could be a powerful feature. In relation to the macro issue, you could handle this in Csound with a couple of well placed cabbageSet's.

2 Likes
#38

Another thing to note with this change is how the cabbageSet opcodes work. They will also expect json type strings, for example:

cabbageSet "gentable1", "tableNumber(99)"

now becomes:

cabbageSet ā€œgentable1ā€, {{ā€œtableNumberā€:99}}

note the use of the {{-}} so we donā€™t have to escape the quotes. If user want to update instruments they will nee to take that into account.

1 Like
#39

Go ahead, Rory! Cabbage is great!

2 Likes
#40

this is exciting! Good luck:)