I’ve offered to help out some people who are interested in making MIDI only plugins, and so have started work on a MidiFilter template.
Here 's the project (VC++e)… it’s not been totally tidied up yet and may involve a little tinkering in the paths etc…
In order to simplify things as much as possible (the initial request was ‘which is better for midi fx - SE or SM?’), i’ve made some ‘enhanced’ base filter classes. They may be of interest to some anyway.
[size=150]Automatic ‘Parameter’ system[/size]
First off, there’s a standard ‘Parameter’ type. Any filter parameters can be of type ‘Parameter’, which has several features:
- Automatic mapping of float (0-1) range onto a custom range
- Functions to retrieve the value in various forms (bool, int/float in custom range, internal 0-1 range)
- can register with a ParameterListener to update when its internal value changes
A ‘ParameterHostingFilter’ base class can hold these parameters, and they simply need to be registered in its constructor with the id (parameter index) it will be accessed with.
A ‘ParameterHostingEditor’ will automatically listen to all registered parameters, or components can be subclassed from ParameterControl (i’ve included a Slider and Button). Parameter controls can be registered with a parameter - they’ll automatically get updated if the parameter changes, and they’ll also update the parameter directly if they are adjusted by the user (notifying the host to allow for automation).
Also, the ParameterHostingFilter has a default implementation for storing/loading patches using the registered parameters.
What this means is that if you use this Parameter system, you don’t need to worry about telling the host about your parameters, updating parameter values from host messages, updating the GUI from the filter when a parameter changes, etc… or even storing a patch. It’s all covered.
I’ve also put in program support - changing programs will store the parameters and load those from the selected program. The only problem with this though is that - because the J.A.P framework uses chunks for the preset storage (best IMO), saving an FXB from the host ignores the actual bank made up of your programs, so i’m not sure quite how useful the program feature is.
[size=150]MidiOnlyFilter simplified base[/size]
On top of all this though, there’s a further simplified ‘MidiOnlyFilter’ class, which has a default audio pass-thru implementation, and tries to hide as much of the code as possible. It’s reduced to a few simple functions to implement:
a ‘processMidi (input,output)’ gives two buffers - the input one from the processBlock function, and an output one. Once this function returns, the input is cleared, and the output is copied into it (and then the output is also cleared).
On top of this, a little ‘processMidiBuffer’ function steps thru the provided buffer (specifically the input), and calls ‘midiInputRecieved (midimessage, samplepos)’ for each message found. The default processMidi implementation simply calls this, so if the person only wanted to remap incoming midi, they’d simply need to override ‘midiInputRecieved’. Another function ‘outputMidiMessage()’ can be used to put a message onto the output buffer.
I’m going to make a few examples, and make it as foolproof as possible (along with a guide, and instructions on how to configure the directory structure to get it built right away).
I’d like to hear any comments or suggestions. I’m aware that the simplification of the MidiOnlyFilter is not particularly efficient, but i think it should be acceptable and makes things a whole lot easier for newcomers (specifically, the people i’m making this for are not programmers!)