@falktx Ah, that's great! Thank you! I think I'll make a video about Carla soon. I've finally checked out the new CV stuff.

Follow

@unfa cool, let me know if you find any issues! You got VST3 now on Linux too btw 😎

@falktx I wonder if I could somehow make once Carla instance not display nodes from another one - I always use Carla to record videos, so when I want to demonstrate it in another instance, I get all that mess fro my recordings setup visible. IS there something I could do?

@unfa same recommendation as last time - use the carla patchbay internal plugin and do whatever stuff is needed inside. parameters are exposed to the outside, so you can tweak things a bit even with the extra patchbay window closed

@falktx A way to avoid that is to work inside of a Carla Patchbay plug-in instead of a separate instance, but it might be a little confusing, because it's not exactly the same.

@trebmuh I am not a fan of hiding things. at this point carla's UI code is going to change very little, until the c++ rewrite is complete.

@falktx me neither, was just pointing @unfa to the issue I've opened since it sounded to be exactly the same workflow issue than mine.

@falktx I think I'm havng some weird signal leaks when working on a CV-driven modular synth in Carla Patchbay. I think I should update and test again.

@falktx Also - using Panic in my Carla Patchbay plug-in made all sound go away for good :D The modular synth no longer responds to MIDI input.

@unfa hmm maybe some synth or midi plugin has a bug and stops working after receiving all-notes-off? what plugins were you using there that used midi?

@falktx Another issue: re-opening the Carla-Patchbay internal plug-in's interface messes up the node layout of that patchbay. Reloading from a saved carxp file fixes that layout.

@unfa ah yes, because the canvas positions are saved in the json file, not the main carla project file.
it is an architecture/design problem. the plugin version has some state, but the UI is something that needs to be saved as well, even though the DSP/backend side has no use for it.
I can add a canvas->save-positions action, but having that automatic is tricky. we do not want to keep sending position data all the time, and we dont want to wait for UI stuff when saving host session. thoughts?

@unfa hmm thinking more about this, perhaps the UI can just tell the DSP/engine when a plugin position in the canvas changes, just caching values for saving in the project. the engine side of things has no use for it whatsoever, but it is just too useful and worth the small memory usage.
I will try this!

@falktx That sounds like a solution! So the canvas layout would then be stored inside the carxp file along the processing data? It would also be easier from a user's point of view to have one file instead of two.

@unfa Yes! I am working on this right now as I type.

@unfa now on latest git/develop of carla. Though I need to do some more testing to see if I find some edge cases or bugs. If you try it, let me know how it goes.

@falktx Now that I think of it - possible node grouping could be a UI feature alone. It'd allow for easier managing the nodes, but shouldn't really change the processing any.

@unfa Someone already started with that, basically port groups in the canvas. but tbh I don't see this as essential, so likely I will still skip this for 1 release or 2.

@falktx I see. Sure! I think being able to group nodes, edit these groups, duplicate them, clone them (linked duplicates) store them and load them from files would allow for creating much more complex setups in Carla, while still having them manageable.

Sign in to participate in the conversation
falkTX Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!