Cabbage Logo
Back to Cabbage Site

The Patcher: some thoughts

#1

I’ve mentioned before that the patcher is a great sandbox to test out ideas before committing to a exported plug-in (if at all), but in using it there are a couple of usability niggles and feature that I believe would really bring the patcher front and centre, and make the environment more than a plug-in creator.

  1. When saving a .cabbage that exists (not Save as…) I’m always prompted to save a new file. I’d expect it to just save rather than having to select the existing file and overwrite. Seems like a small bug.

  2. Adding a new instance of a plugin auto connects pins, sometimes this is not always what you want and you have to disconnect.

  3. Save patch states: I’ve noticed there is an option to show parameters which suggests that snapshots of a plug-in could be stored (and recalled somehow). Using Cabbage in a live context would benefit from this, but also when sound designing.

  4. Supply transport to the patch (maybe multiple independent transports) so that host tempo can be used. This has been touched on recently.

  5. Make connections intelligent. Plogue Bidule and Purr Data use some fancy automation to connect inlets /outlet pins to save on repetitive connections tasks.

  6. Rename duplicate patch instances so that you know what plug-in you’re editing

  7. A system to link up parameters of the plugins, a bit like the parameter window in Bidule. Sort of wireless connections.

That’s all I can think of right now; maybe some of it is too much and beyond the scope of what Cabbage is intended to be. But it seems that to provide a patching gui, and a few solid usability and performance features would make this app killer (IMO)

#2

Ps. It already is ‘killer’ (choice wording :roll_eyes:) to be honest!

#3
  1. could the patcher itself be a VST/AU plugin?
#4

Indeed, small, but I can imagine it might also be pretty annoying! I’ll take a look.

I understand, but it also means that people don’t have to open the patcher and make connections each time the run an instrument. For anyone not using the Patcher, this would be a pain. I could add a way to disable it?

Good call. That should really be there to be honest…

Agreed.

Making connections intelligent would imply some kind of intelligence on the part of the main developer. Do we really want people to make such assumptions :rofl: I’ve been very impressed with what I’ve seen from Bidule. Even AudioMulch had this kind of thing. It would be awesome. But I’m not sure it will be part of the Patcher any time soon.

But a duplicate instrument is just that? A duplicate. It’s a bit like an abstraction in Pd. So if you edit it, you are editing all instances? Or am I missing something? You can also ‘save-as’?

I’ve been down this road before. At one point I even had extra inputs for patching automation type plugins to nodes, but I scrapped it. It got way to complex. It could always be done with OSC if you really need that kind of functionality?

The quick answer is yes, but it would really be a lot of work.

The thing with the patcher is its part of the very fabric of the Cabbage IDE. Every time you run an instrument it is added to the digital audio graph. So I thought I might as well make it editable, but perhaps I should have waited until I could add the functionality you long for. I was forever frustrated with the Bitwig guys for telling us all about how Bitwig is really just a front-end to a great bit patching environment. But when I see the latest version of Bitwig, and what they call the grid, I understand why they held back for so long! I will try to add some of these things, but for the majority of users, being able to create killer plugins is the main reason for choosing to use Cabbage. Everything else is a nice side dish, but I guess we can still try to make it as tasty as we can.

Oh, there is another issue we should add to the list. Cabbage patcher files cannot easily be shared without them breaking due to absolute paths for plugins. Let’s call that number 9!

#5

Hi Rory

Aha, yes I see. Would a prompt or an extra key command when hitting play or saving the file work here?

Hahha classic!

I think I meant this: as you are able to add more than one instance of the plugin/instrument/effect, and you have the two or three guis displaying, it’s difficult to know which one you are editing. So a way to add a temporary identifier for the purposes of the patcher environment.

Yes of course, that is what it’s for. Also using inputs and outputs. Are the chnset/chnget type of opcodes sandboxed for a particular instance of a plugin then? But if we’re talking the whole modular approach with signals going everywhere, then that should be farmed out to something like VCV right?

Further to my comment above, I guess it sounds like I am trying to mould Cabbage into something like one of the many patching environments, but really I’m not…I hope it doesn’t come across like that. Those environments have their benefits and conveniences which can unleash creativity, but also some drawbacks. I think where it comes from it having used Bidule or Pd and wishing I could double click and object in to a coding environment like Cabbage, rather than more clicking and dragging cables and objects. Something a bit more lower level under the hood.

But now I realise I can do that with both, just by exporting the plugins! That said, some of the niceties that these patching environments offer would be welcome in Cabbage patcher. I’m not complaining in the slightest :wink:

Number 9 is a good one.

#6

Command B could build the plugin, but not make any connections?

yes, I understand now.

yes, they’re local to a plugin, to enable instrument to talk to each other using this mechanism would involve a complete rewrite of Cabbage…

You can certainly export to VCV and work there. There is nothing to stop you from building a similar system with the patcher, just use multichannel plugins to handle the control signals.

I will try to fix these things in the next few days :wink: Leave it with me.

#7

splendid splendid thanks

feel free to beta test stuff on me :wink:

#8

I just added a ctrl-b shortcut to enable disable automatically connecting nodes to the graph. It’s the best I can do without some serious messing around. I also fixed the save-as issues. New build will be available here shortly.

With regards to the saving of plugins settings. There are already saved. The only problem is they are not recalled. This is a little tricky, but I concur that it’s would be a good thing.

Another thing. Right now when you open a graph in Cabbage it opens each plugin GUI, but doesn’t start any plugins. If I added a transport dialogue, the star button could automatically start all the plugins that were running when the patch was saved. Would this be reasonable? I think it’s better than automatically starting everything and potentially blowing the ears of oneself?

#9

bloomin 'eck you’re quick! nice one

ideally there’d be a way to select multiple scenes, …or leave it up to the user to hook into the state system via dedicated channels? :thinking:

absolutely, I’m pretty sure I’ve ruined my ears by wearing headphones and this happening. Let’s give it a go and see how it fares. (Note use of royal 'let’s", I’m doing bugger all here, sorry, but I hope I’m helping in some way)

#10

I think you might be over thinking this. But there is another issue here. As soon as a user edits the source and recompiles, they will override the last saved state. This might be a little frustrating, but I guess they can simply reopen the patch?

#11

Probably, and jumping the gun too! I was only musing as to what it could be like.

Do you mean the “Patcher” .cabbage file?

I’ll have a play with the latest now an report back.

#12

I’m only now working on the transport controls. My 3 month old has finally fallen asleep. Time for some breakneck coding!

#13

Confirm this works.
Command-B - Is there a potential conflict with toggle file browser?

Saving the .cabbage file doesn’t prompt for filename now. All good

Ah bless!! blimey, what about you, and you’re still managing to do all this? (I have a 11 month and I barely get anything done :stuck_out_tongue_closed_eyes:)

#14

image
image.png2614×1380 555 KB

one small nit - when the patch file is opened, the guis all display, but the titles all read “CabbageEffectNam”. Closing and reopening fixes this though

#15

Good spot on the Ctrl-B shortcut. Changed now to Ctrl+,

I’ll look into this. Don’t ask me how I get anything done, although it’s not yet 6 am and I’m already on my second cup of coffee :grimacing:

#16

No, but it’s 5am judging by when your reply came in!!

#17

I’m in mainland Europe at the moment so it was actually closer to 6 :wink:

So I managed to get a start at implementing the transport controls for the patcher. So far I have only implemented a hand full of the information available. If you load the HostInfo.csd from the Misc examples folder you’ll see what is there and what needs doing. I will also update the look and feel as it is still a little rough, and missing certain things.

The latest build here will have all the new stuff once it finishes building, or should I say IF it finishes building…

#18

Sweet! it’s coming together; I’m happy to keep testing and throw back my comments.

One thing I was confused about is the state recall . Did you say that was implemented partially?

(sidenote: If I had the build process setup I could probably lend a hand with UI tweaks and submit a PR or two, might have to put aside some time to setup that though)

#19

You’re on OSX? The build shouldn’t be that tricky there. In fact, that following script shows almost all of what needs doing. you basically clone the Cabbage repo. Then clone the JUCE repo in the same directory the Cabbage one lives. Then build the Projucer in JUCE/extras/projucer/Builds/MacOS. Then run buildCabbage.sh from the cabbage/Bulids/MacOS folder. You will also need to install the VST3 SDK in order to build VST plugins.

I haven’t implemented the state recall yet. I want to get the transport controls sorted first.

#20

Hi @boonier_due I made some progress today with the patcher.

  • plugin states are saved and recall when a patch is opened. Note that each plugin is started when the session opens, otherwise the states will not be recalled.
  • paths for Cabbage plugins (i.e.e csd files) are saved as relative paths, so it makes it easier to share patches
  • Double clicking a node will now toggle visibility. This should make it much easier to know which node is which, until I can find a better way of making this obvious

Currently I’m trying to tidy up some stuff about what happens when you save a file that is open in other tabs. Right now it will save across all tabs that share the same file, but for some reason it also gets rid of the plugin window. I should get a fix for that shortly.

New builds can be got here when they’ve finished building.