Replies: 1 comment
-
I have thought quite a lot about this in the last years. The "proper approach" for this application would be to have a real service and a separated gui code that communicates with it. But my conclusion is always that I do not have time to implement and maintain things this way. The main problem with having the window in a separated process is communication. We have too many parameters. Too many level meters. As things are right now the gui code just uses a pointer to the corresponding plugin backend and the job is essentially done. With the plugin backend living with the background service in a different process there is no way the communication with the gui code is going to be that straightforward. It will be a lot more complicated. And that is when lack of time to do all that becomes an issue. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I very much like this application however i have a slight issue with the hard requirement of needing a GUI.
With gtk it wasn't too big of an issue i could just patch in some presets and be fine however with the switch to qt i find that my gentoo dep tree has grown quite large.
Thing is I don't really need the GUI, i'd much prefer to just have a terminal interface or atleast stubs for the effects which i could than manually direct using a patchbay.
Is there any chance a feature like this could happen in the future? I'd like to be able to compile the application without needing to pull in any crazy gui frameworks.
Beta Was this translation helpful? Give feedback.
All reactions