Separating the GUI from the processing

[deraudrl]

I'm spinning off this topic from another thread (http://www.dsprobotics.com/support/viewtopic.php?f=2&t=35609), here's some context:

My main issue [with FS at this point] is getting my head around the (rather baroque IMHO) interface between the working bits and the GUI; I have a lot of experience with "normal" GUI toolkits and there's a bit of culture shock kicking in. I tend to try to keep cosmetics well separated from functionality, and I'm not sure that's really possible here

It can be more difficult, especially if working with stock or downloaded modules, and it's not a common way of working. I do find it helpful at times to use separate modules for processing and GUI with wireless links or a bus used to share the control parameter data, but it's not always easy to arrange. A Ruby GUI framework is something that I've tinkered with over the past few years, but this has often been hampered by the way that Ruby and the GDI+ renderer are integrated into FS and the minimal support for external libraries (something else I've been looking into).

Continuing on that theme, I'm creating a DLL that acts as a shared-memory pipe between the working bits of a synth/effect/whatever and an (somewhat) independent external GUI process, possibly implemented in JUCE since it has a wealth of VST-friendly widgets and I know my way around it to some extent. The implementation would be based on this: https://docs.microsoft.com/en-us/windows/win32/dlls/using-shared-memory-in-a-dynamic-link-library; on the FS side, one or more DLL components could poll a semaphore and read out a set of control parameters when changes occurred.

Before I spend a lot of time chasing this, I need to ask:
1. Am I reinventing the wheel, i.e. does something similar already exist and I just haven't tripped over it yet?
2. Are there any obvious impossiilities that I'm missing?
2. Does it look like it would be worth the trouble?

[trogluddite]

Am I reinventing the wheel, i.e. does something similar already exist and I just haven't tripped over it yet?

I've never seen anything like that done, and I would be quite surprised if it had been - the DLL component doesn't get seen much in the wild. Everything in a similar vein that I've seen has been based on Ruby and the built-in GDI+ hooks.

Are there any obvious impossiilities that I'm missing?

Nothing fatal, I don't think. A few years back, I used MappedFiles experimentally for passing data between plugin instances successfully (my C++ is not pretty, but I can rummage for the source code if you think it might be any use to you). If the limited data types of the DLL primitive are a problem, Ruby can be used to pack Frames with binary data to work around strings being null-terminated (Ruby's Win32API class isn't available in VST exports, contrary to what the User Guide implies). You've mentioned polling already, so I'm guessing you've already taken into account latency and that callbacks won't be possible. Docking windows would present the problem of finding the parent window location, but should be possible with the Windows API, though identifying the window might require sniffing window content if process IDs are shared with e.g. a VST host or other plugins.

Does it look like it would be worth the trouble?

The bridge crossing scene from Monty Python and the Holy Grail comes to mind - two easy questions to lull us into a false sense of security; and then, Pow!

I could certainly think of some use cases for it (e.g. I've always wanted an always-on-top debugging window), and there are certainly a few of us who've found the GDI+ renderer limiting for animations and displaying structured data. I'm less sure that it would suit most people's way of working with FS, though, and a native way to create child windows is already (partly?) implemented in recent Alphas, IIRC. I think Inter-app comms developments along the way might well interest a few people. Is it trying to hammer a square peg into a round hole? I'm not sure, I could be swayed either way, and I'm not familiar enough with JUCE to know what it might bring to the table. Of course, if you have your own use-cases, and it's an enticing project, none of that may matter.

[trogluddite]

A quick additional thought. The only way to have individually named VST parameters for presets and automation is for each control to have its own VST parameter primitive with data flow in both directions. I can imagine that might get a bit ugly.

[deraudrl]

Are there any obvious impossiilities that I'm missing?

Nothing fatal, I don't think. A few years back, I used MappedFiles experimentally for passing data between plugin instances successfully (my C++ is not pretty, but I can rummage for the source code if you think it might be any use to you). If the limited data types of the DLL primitive are a problem, Ruby can be used to pack Frames with binary data to work around strings being null-terminated (Ruby's Win32API class isn't available in VST exports, contrary to what the User Guide implies). You've mentioned polling already, so I'm guessing you've already taken into account that callbacks won't be possible and there'd be latency for mouse actions. Docking windows would present the problem of finding the parent window location, but should be possible with the Windows API, though identifying the window might require sniffing window content if process IDs are shared with e.g. a VST host or other plugins.

This whole idea is based on data being exchanged at GUI rate, maybe a few tens of HZ max, certainly not signal data or anything I'd normally consider real-time.

I'm not sure the data types are an issue...for the life of me, I can't see how there's any control data that needs to be passed that can't be done with arrays of ints, arrays of floats, and/or arrays of strings. Frames might be handy for passing data upstream to a graphical readout (scope or FFT window), but things like sample files and bitmaps wouldn't go over that pipe anyway, just pathnames or indices to pre-loaded files.

The window-docking thing is something I really hadn't considered. I'm a bit fuzzy about how hosts handle the positioning of plug-in GUIs in the first place. If the host is providing a parent window handle, it may be as easy as passing that back up to the GUI on a second pipe...assuming of course that that information is visible at the module level.

The bridge crossing scene from Monty Python and the Holy Grail comes to mind - two easy questions and then pow!

I'm more worried about a "Killer Rabbit of Caerbannog" scenario.

[deraudrl]

A quick additional thought. The only way to have individually named VST parameters for presets and automation is for each control to have its own VST parameter primitive with data flow in both directions. I can imagine that might get a bit ugly.

For some arbitrarily-large value of "ugly"...I was having enough trouble dealing with the mental image of a string primitive containing all the bus signal names.

Maybe it's just time for me to get with the program and carry on learning the "Flowstone Way".

A rant, possible worthy of its own thread...

Ok, I open the schematic of one of the gorgeous synths posted up here, and the whole thing is a black-box module, hidden behind a front panel. So I open that module...and the whole front panel freaking disappears. I know it's still there, it's part of the module I just opened, right? Here a knob, there a knob, everywhere a knob-knob, labels scattered more or less at random, all nestled in around fundamentally non-GUI bits like oscillators and filters. I read the tutorials and (sort of) see how the GUI is constructed bottom-up, but for the life of me I can't take one apart top down and get to a coherent place in the middle without getting lost in the weeds.

Thus endeth the rant.

[trogluddite]

If the host is providing a parent window handle, it may be as easy as passing that back up to the GUI on a second pipe...assuming of course that that information is visible at the module level.

As far as the FS schematic is concerned, it just receives a "View" representing a GDI+ object to draw on. The data available to us from the host is pretty much just audio, MIDI, VST presets, and song tempo/meter/position, in whatever form primitives expose them. The schematic's file location, the process ID, and environment variables can also be read.

A rant...

You have no idea how often I've been temped to say just the same to some people who I've offered to help with bug-hunting in their rats' nests of links!

As you've probably noticed, there are no style-guides for FS! Some of us label diligently, modularise in a way that maps to concepts, unit test each module in isolation, and arrange our links neatly. Others channel Jackson Pollock and give "spaghetti code" a whole new meaning! I can't promise that you'll find a comfortable way of working, but having been a coder for a decade or two before using SM, I understand why it can take a bit of getting used to. I'd suggest just getting stuck into a project and let the path of least resistance lead to what works for you.

Good ranting style, BTW; "here a knob, there a knob, everywhere a knob-knob" particularly tickled me!

[Spogg]

It would be really nice if we had two simultaneous views available: one for the highest level - the front panel, and one for diving into the schematic. Often I’ve had to put readouts inside modules then go to the front panel to see what’s happening, or sometimes put knobs and such into modules so I could emulate the front panel for testing and de-bugging.

Maybe be a letter to Santa?

Cheers

Spogg

[trogluddite]

It would be really nice if we had two simultaneous views available

It's long been on my wish-list, too. It's no coincidence that most conventional code editors allow multiple views, either into the same source file or of multiple files, which is something you wonder how you ever lived without once you get used to it (especially if you're prone to forgetting something that you read only two seconds ago like I am!) How feasible it would be with the FS redraw triggering, I'm less sure - there have been bugs in the past where views could behave bizarrely when redraw triggers from the schematic collided with those from the FS workspace. I don't think it would be as easy as doing it for a bunch of text files.

[tulamide]

Continuing on that theme, I'm creating a DLL that acts as a shared-memory pipe between the working bits of a synth/effect/whatever and an (somewhat) independent external GUI process, possibly implemented in JUCE since it has a wealth of VST-friendly widgets and I know my way around it to some extent. The implementation would be based on this: https://docs.microsoft.com/en-us/windows/win32/dlls/using-shared-memory-in-a-dynamic-link-library; on the FS side, one or more DLL components could poll a semaphore and read out a set of control parameters when changes occurred.

Before I spend a lot of time chasing this, I need to ask:
1. Am I reinventing the wheel, i.e. does something similar already exist and I just haven't tripped over it yet?
2. Are there any obvious impossiilities that I'm missing?
2. Does it look like it would be worth the trouble?

1. Yes. It's called JUCE
2. The window is registered through the DAW. If you can manage to get a window handle, everything else should work fine.
3. No. I'm really serious: If you manage to do a JUCE GUI, you already know everything needed programming-wise to do the whole VST in JUCE.

[k brown]

You have no idea how often I've been temped to say just the same to some people who I've offered to help with bug-hunting in their rats' nests of links!

. . . I think my ears are burning