for Track Modules to be able to integrate seemlessly into the editor, two things need to happen.
The load/save/copy/paste controls need to be aware of them, and the context options need to be customized for them.
I’m thinking the easiest approach to the file handling is for a module to have a couple of functions that are used by the host to register the module, for example:
fileFormatSupported()
and
getModuleID()
fileFormatSupported would return a list of file extensions supported by the Module. In this way load and save can adapt to support new file types.
getModuleID returns a unique ID set by the developer of this module. Modules will need to support a unique ID, much like the vst ID, so that the supported file formats can be associated with a given module. This ID will also be used to create Display Presets.
All modules will descend from a base module class, which provides primitives for copy and paste operations.
Whilst I’m sure it is unfinsihed, the above should provide the basic framework for allowing teh global controls to handle new Track Modules and file types gracefully.
More tricky is the context menu. For this I propose that the Module be able to specify which of the base context options are available, and to add new buttons itself. I need to think about this some more, but it seems like the only way to make the interface truly extensible is to allow Track Modules to install their own context functions.
Each Track Module when initialized could call a function such as
addContextOption()
for every function it wants to add to the context area.
(the options can be in the form of buttons or menus)
A waveform module would therefore make available functions such as reverse, normalise etc
a midi module might make available functions such as transpose
the timline (which itself would be just another track module) would have options to control tempo and time sig.
