openshot-audio
0.1.7
|
#include <juce_audio_processors.h>
Public Types | |
enum | IODeviceType { audioInputNode, audioOutputNode, midiInputNode, midiOutputNode } |
![]() | |
enum | WrapperType { wrapperType_Undefined = 0, wrapperType_VST, wrapperType_VST3, wrapperType_AudioUnit, wrapperType_RTAS, wrapperType_AAX, wrapperType_Standalone } |
Additional Inherited Members | |
![]() | |
static int | getDefaultNumParameterSteps () noexcept |
static void | copyXmlToBinary (const XmlElement &xml, juce::MemoryBlock &destData) |
static XmlElement * | getXmlFromBinary (const void *data, int sizeInBytes) |
static void JUCE_CALLTYPE | setTypeOfNextNewPlugin (WrapperType) |
![]() | |
WrapperType | wrapperType |
![]() | |
AudioPluginInstance () | |
![]() | |
AudioProcessor () | |
void | sendParamChangeMessageToListeners (int parameterIndex, float newValue) |
![]() | |
AudioPlayHead * | playHead |
A special type of AudioProcessor that can live inside an AudioProcessorGraph in order to use the audio that comes into and out of the graph itself.
If you create an AudioGraphIOProcessor in "input" mode, it will act as a node in the graph which delivers the audio that is coming into the parent graph. This allows you to stream the data to other nodes and process the incoming audio.
Likewise, one of these in "output" mode can be sent data which it will add to the sum of data being sent to the graph's output.
Specifies the mode in which this processor will operate.
AudioProcessorGraph::AudioGraphIOProcessor::AudioGraphIOProcessor | ( | const IODeviceType | type | ) |
AudioProcessorGraph::AudioGraphIOProcessor::~AudioGraphIOProcessor | ( | ) |
|
overridevirtual |
Returns true if the processor wants midi messages.
Implements juce::AudioProcessor.
|
overridevirtual |
Called by the host to rename a program.
Implements juce::AudioProcessor.
|
overridevirtual |
Creates the filter's UI.
This can return nullptr if you want a UI-less filter, in which case the host may create a generic UI that lets the user twiddle the parameters directly.
If you do want to pass back a component, the component should be created and set to the correct size before returning it. If you implement this method, you must also implement the hasEditor() method and make it return true.
Remember not to do anything silly like allowing your filter to keep a pointer to the component that gets created - it could be deleted later without any warning, which would make your pointer into a dangler. Use the getActiveEditor() method instead.
The correct way to handle the connection between an editor component and its filter is to use something like a ChangeBroadcaster so that the editor can register itself as a listener, and be told when a change occurs. This lets them safely unregister themselves when they are deleted.
Here are a few things to bear in mind when writing an editor:
Implements juce::AudioProcessor.
|
overridevirtual |
Fills-in the appropriate parts of this plugin description object.
Implements juce::AudioPluginInstance.
|
overridevirtual |
Returns the number of the currently active program.
Implements juce::AudioProcessor.
|
overridevirtual |
Returns the name of one of the processor's input channels.
The processor might not supply very useful names for channels, and this might be something like "1", "2", "left", "right", etc.
Implements juce::AudioProcessor.
Returns the name of this processor.
Implements juce::AudioProcessor.
|
overridevirtual |
Returns the number of preset programs the filter supports.
The value returned must be valid as soon as this object is created, and must not change over its lifetime.
This value shouldn't be less than 1.
Implements juce::AudioProcessor.
|
overridevirtual |
Returns the name of one of the processor's output channels.
The processor might not supply very useful names for channels, and this might be something like "1", "2", "left", "right", etc.
Implements juce::AudioProcessor.
|
inlinenoexcept |
Returns the parent graph to which this processor belongs, or nullptr if it hasn't yet been added to one.
|
overridevirtual |
Must return the name of a given program.
Implements juce::AudioProcessor.
|
overridevirtual |
The host will call this method when it wants to save the filter's internal state.
This must copy any info about the filter's state into the block of memory provided, so that the host can store this and later restore it using setStateInformation().
Note that there's also a getCurrentProgramStateInformation() method, which only stores the current program, not the state of the entire filter.
See also the helper function copyXmlToBinary() for storing settings as XML.
Implements juce::AudioProcessor.
|
overridevirtual |
Returns the length of the filter's tail, in seconds.
Implements juce::AudioProcessor.
|
inlinenoexcept |
Returns the mode of this processor.
|
overridevirtual |
Your filter must override this and return true if it can create an editor component.
Implements juce::AudioProcessor.
|
noexcept |
True if this is an audio or midi input.
|
overridevirtual |
Returns true if the specified channel is part of a stereo pair with its neighbour.
Implements juce::AudioProcessor.
|
noexcept |
True if this is an audio or midi output.
|
overridevirtual |
Returns true if the specified channel is part of a stereo pair with its neighbour.
Implements juce::AudioProcessor.
|
overridevirtual |
Called before playback starts, to let the filter prepare itself.
The sample rate is the target sample rate, and will remain constant until playback stops.
The estimatedSamplesPerBlock value is a HINT about the typical number of samples that will be processed for each callback, but isn't any kind of guarantee. The actual block sizes that the host uses may be different each time the callback happens, and may be more or less than this value.
Implements juce::AudioProcessor.
|
overridevirtual |
Renders the next block.
When this method is called, the buffer contains a number of channels which is at least as great as the maximum number of input and output channels that this filter is using. It will be filled with the filter's input data and should be replaced with the filter's output.
So for example if your filter has 2 input channels and 4 output channels, then the buffer will contain 4 channels, the first two being filled with the input data. Your filter should read these, do its processing, and replace the contents of all 4 channels with its output.
Or if your filter has 5 inputs and 2 outputs, the buffer will have 5 channels, all filled with data, and your filter should overwrite the first 2 of these with its output. But be VERY careful not to write anything to the last 3 channels, as these might be mapped to memory that the host assumes is read-only!
Note that if you have more outputs than inputs, then only those channels that correspond to an input channel are guaranteed to contain sensible data - e.g. in the case of 2 inputs and 4 outputs, the first two channels contain the input, but the last two channels may contain garbage, so you should be careful not to let this pass through without being overwritten or cleared.
Also note that the buffer may have more channels than are strictly necessary, but you should only read/write from the ones that your filter is supposed to be using.
The number of samples in these buffers is NOT guaranteed to be the same for every callback, and may be more or less than the estimated value given to prepareToPlay(). Your code must be able to cope with variable-sized blocks, or you're going to get clicks and crashes!
If the filter is receiving a midi input, then the midiMessages array will be filled with the midi messages for this block. Each message's timestamp will indicate the message's time, as a number of samples from the start of the block.
Any messages left in the midi buffer when this method has finished are assumed to be the filter's midi output. This means that your filter should be careful to clear any incoming messages from the array if it doesn't want them to be passed-on.
Be very careful about what you do in this callback - it's going to be called by the audio thread, so any kind of interaction with the UI is absolutely out of the question. If you change a parameter in here and need to tell your UI to update itself, the best way is probably to inherit from a ChangeBroadcaster, let the UI components register as listeners, and then call sendChangeMessage() inside the processBlock() method to send out an asynchronous message. You could also use the AsyncUpdater class in a similar way.
Implements juce::AudioProcessor.
|
overridevirtual |
Returns true if the processor produces midi messages.
Implements juce::AudioProcessor.
|
overridevirtual |
Called after playback has stopped, to let the filter free up any resources it no longer needs.
Implements juce::AudioProcessor.
|
overridevirtual |
Called by the host to change the current program.
Implements juce::AudioProcessor.
void AudioProcessorGraph::AudioGraphIOProcessor::setParentGraph | ( | AudioProcessorGraph * | newGraph | ) |
|
overridevirtual |
This must restore the filter's state from a block of data previously created using getStateInformation().
Note that there's also a setCurrentProgramStateInformation() method, which tries to restore just the current program, not the state of the entire filter.
See also the helper function getXmlFromBinary() for loading settings as XML.
Implements juce::AudioProcessor.
|
overridevirtual |
Returns true if a silent input always produces a silent output.
Implements juce::AudioProcessor.