Some thoughts on Track Modules


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 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


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.


Fleshing this out a little:

the base class for a Track Module needs to support a basic timeline functionality, obviously.

Personally I’d prefer to represent the timeline as a 32 bit unsigned int but vsts use a floating point representation for beats bars and measures, so a hybrid approach will be needed,

How the timeline is stored internally is probably a matter of implementation, but I need to think about it a little more. My gut feeling though is that unsigned ints make the most sense for utterly reliable sample accurate editing, with a conversion to float type only when calculating sample pos on a tempo basis.

The tempo will represnt bar as a whole number, where the real part will be fractions of a bar. In this way tempo format remains constant with the VST format.

Track Modules are responsible for creating their own components (or descendents) on which to draw themselves. This component will be public, such that the midsection code can handle resizing as necessary,

A track module owns the data it represents, and will also therefore provide the functionality to load save and edit the data.

At this time, I think the base class will only need to provide virtual functions for load, save, copy, insert, and paste.


I think with timeline using unsigned int’s you’ll have trouble forcing a usable (not hacked) workaround for very very large files.

Id prefer a double, which would be a bit easier to work with the VST spec while giving the needed expansion you suggest.


What are you calling very very large?

32bit unsigned at 96k allows for 12 hours worth of audio at sample accurate positioning.

I worry that with floats you lose that sample accuracy at unpredicatable steps.

double is definitely easier to work with though in regards to vsts. Integer is quicker for indexing the sample array.

I’m not set for or against, so if you can sell me doubles, then by all means do. :wink:


hmmm, but then I think about what int means to say a video stream, and I’m painfully aware that it’s a silly idea.

Float it is. :slight_smile:

Though I think the sample module should support int for scripting purposes.