Looking for modular design suggestions

#1

A friend and I looking to create an editor framework using Juce that is modular in nature. That is, the user can add device editors to the core application as they become available.

My question is: how can we best modularize these device editors? In other words, what technique should we use to allow the core application to communicate with editor components added later dynamically? By dynamically, i mean that these applications are not ever statically linked together.

any suggestions will be appreciated.

#2

what do you mean by ‘device’? and do you mean that you’ll want to be able to let the user add a DLL (made by you) to a defined directory and have the new ‘device’ editor appear in the application?

What i’d suggest is to come up with some kind of base device editor class, with a carefully planned interface that has all the general functions applicable to all devices. You can then come up with a kind of template DLL project, which exposes the functions in your editor base class, acting upon a global pointer (within the DLL) to your editor base.

When you create a device editor module, you’d make a subclass of your editor base, and include it in your DLL project. Create a global instance of it on loading of the DLL, and assign the editor pointer to this new object. The exposed functions would then act on this instance, allowing a general fixed set of functions (known by your program) to be accessed by your program, calling those defined in your subclass. Your application would have to of course dynamically load these DLLs, using some kind of folder scanning function to find out what modules are present.

You could of course then release the DLL project with the editor base header as a ‘device SDK’ for others to make devices to be added.

As long as you keep the instance contained within the DLL, and just let the functions act upon it, you’ll not run into any problems.

#3

using a dll is a good approach and definitely the approach that first comes to mind. that approach is very similar to a vst host/plugin design.

another approach is to use an ip socket between the core and the device editors. this takes the place of the dll approach and is there only to bind the core and addons. it is not really making use of the socket for connecting across machines. it would basically connect to locahost using an internal port number. xml could be the data format used to communicate between core and device editors.

either way it’s done, defining an immutable api is required. so that requirement is not the tie-breaker.

not knowing enough about the mechanics of dll’s, i’m not sure why i’d choose one approach over another (or a third option, for that matter).

p.s. haydxn, good to hear from you! i’m glad to see that you are adding to the tutorial. it has helped me in the past.

#4

we’d also like for the application (and editors) to work cross-platform (win/mac/linux). can the dll approach work on those non-windows platforms?

#5

yep. with some limitations but on linux/unix u can use dl* functions. i’ve written a DynamicLibraryLoader what works on linux and windows with the same interface, *.dll on one system, *.so on the other… it’s very simple. if you’re interested i can post the code

#6

It would help to know what you mean by ‘device’. If you’re really sure of your interface, you’d be able to come up with a general editor class that can construct itself based on an XML script.

It depends on the kind of components the editors may need, and the sort of functions they may wish to call. If by ‘device’ you mean some kind of hardware that would need specific functions called for it, or some special kind of conversion functions or what have you, then you will of course need to have extra code for each device editor.

If not though, and each editor will merely be some kind of interface panel for changing different settings in different ways specific to some other kind of whatever-it-is, then this approach could work. Your editors would be created by a generic editor, which will process an XML editor layout file and create the appropriate widgets in the layout specified. These components would be designed for general applications such that their behaviour can be customised according to a script. Each could then be given the ability to register with a particular parameter within the program, or perhaps to dump their edited values to an xml state to then be processed by the program.

My MidiPanelDesigner program for example, has Parameter objects (which hold details on a parameter in a piece of MIDI hardware, and the type of message it uses), ControlPanel objects, which hold arrangements of ControlWidget objects, which are in turn linked to Parameter objects. The control widgets set the values of the parameters, and the program responds to these value changes by sending MIDI to a device. The layout of the control panel is stored as XML, with the control widgets linked to the parameters by unique ID, and various other settings (a panel title, text boxes on the panels, different types of control widget etc…) stored too. That means that a different synth device editor can be loaded up, arranging the stored controls, linking them to their parameters etc… and becoming active for the program to respond to. You could make a dedicated editor program to create these editors (in my case, the program IS the editor too).

But, like i said, you may need to have each editor call specific functions which could be unknown at the time of building the main user application. It does depend on the type of ‘device’ you are talking about.

#7

that is a nice offer. we’d need to find a mac solution for it to be feasible. are you saying thatthe api will work for osx (you mentioned unix)?

#8

actually i don’t know if the dl* family functions exists on macosx tho (i think gcc have dlfcn.h, but don’t know xcode)… if there is a macosx user out there that can clarify this to us would be appreciated :wink:

ps. when i come home i get the files for you.

#9

Since you have not yet stated (or I have not noticed) what a device is, you may think about using an embedded interpreted language as well. Something like Python would allow whoever to write extensions in Python, or in C++ using a Python module (dll/so/pyd/etc…).

#10