1
0
Fork 0
mirror of https://github.com/beefytech/Beef.git synced 2025-06-08 03:28:20 +02:00

s/seperate/separate

This commit is contained in:
Joseph Battelle 2021-01-29 23:52:58 -08:00
parent c0ae4bb8f7
commit a69dff59ce
7 changed files with 7 additions and 7 deletions

View file

@ -1108,7 +1108,7 @@ namespace FMOD
FMOD_DSP_CONNECTION_TYPE_SIDECHAIN<br>
----------------------------------<br>
Sidechain DSPConnection type. Audio is mixed from the input to the output DSP's sidechain buffer, meaning it will NOT be part of the audible signal. A sidechain connection will execute its input DSP if it has not been executed before.<br>
The purpose of the seperate sidechain buffer in a DSP, is so that the DSP effect can privately access for analysis purposes. An example of use in this case, could be a compressor which analyzes the signal, to control its own effect parameters (ie a compression level or gain).<br>
The purpose of the separate sidechain buffer in a DSP, is so that the DSP effect can privately access for analysis purposes. An example of use in this case, could be a compressor which analyzes the signal, to control its own effect parameters (ie a compression level or gain).<br>
<br>
For the effect developer, to accept sidechain data, the sidechain data will appear in the FMOD_DSP_STATE struct which is passed into the read callback of a DSP unit.<br>
FMOD_DSP_STATE::sidechaindata and FMOD_DSP::sidechainchannels will hold the mixed result of any sidechain data flowing into it.<br>

View file

@ -1828,7 +1828,7 @@ namespace FMOD
The FMOD_DSP_TRANSCEIVER_TRANSMITSPEAKERMODE is only applicable to the transmission format, not the receive format. This means this parameter is ignored in 'receive mode'. This allows receivers to receive at
the speaker mode of the user's choice. Receiving from a mono channel, is cheaper than receiving from a surround channel for example.
The 3 speaker modes FMOD_DSP_TRANSCEIVER_SPEAKERMODE_MONO, FMOD_DSP_TRANSCEIVER_SPEAKERMODE_STEREO, FMOD_DSP_TRANSCEIVER_SPEAKERMODE_SURROUND are stored as seperate buffers in memory for a tranmitter channel.
The 3 speaker modes FMOD_DSP_TRANSCEIVER_SPEAKERMODE_MONO, FMOD_DSP_TRANSCEIVER_SPEAKERMODE_STEREO, FMOD_DSP_TRANSCEIVER_SPEAKERMODE_SURROUND are stored as separate buffers in memory for a tranmitter channel.
To save memory, use 1 common speaker mode for a transmitter.
The transceiver is double buffered to avoid desyncing of transmitters and receivers. This means there will be a 1 block delay on a receiver, compared to the data sent from a transmitter.

View file

@ -356,7 +356,7 @@ namespace System.IO
StringComparison compareType = Environment.IsFileSystemCaseSensitive ? StringComparison.Ordinal : StringComparison.OrdinalIgnoreCase;
// On seperate drives?
// On separate drives?
if (!String.Equals(driveString1, driveString2, compareType))
{
outRelPath.Set(fullPath);

View file

@ -1108,7 +1108,7 @@ namespace FMOD
FMOD_DSP_CONNECTION_TYPE_SIDECHAIN<br>
----------------------------------<br>
Sidechain DSPConnection type. Audio is mixed from the input to the output DSP's sidechain buffer, meaning it will NOT be part of the audible signal. A sidechain connection will execute its input DSP if it has not been executed before.<br>
The purpose of the seperate sidechain buffer in a DSP, is so that the DSP effect can privately access for analysis purposes. An example of use in this case, could be a compressor which analyzes the signal, to control its own effect parameters (ie a compression level or gain).<br>
The purpose of the separate sidechain buffer in a DSP, is so that the DSP effect can privately access for analysis purposes. An example of use in this case, could be a compressor which analyzes the signal, to control its own effect parameters (ie a compression level or gain).<br>
<br>
For the effect developer, to accept sidechain data, the sidechain data will appear in the FMOD_DSP_STATE struct which is passed into the read callback of a DSP unit.<br>
FMOD_DSP_STATE::sidechaindata and FMOD_DSP::sidechainchannels will hold the mixed result of any sidechain data flowing into it.<br>

View file

@ -1829,7 +1829,7 @@ namespace FMOD
The FMOD_DSP_TRANSCEIVER_TRANSMITSPEAKERMODE is only applicable to the transmission format, not the receive format. This means this parameter is ignored in 'receive mode'. This allows receivers to receive at
the speaker mode of the user's choice. Receiving from a mono channel, is cheaper than receiving from a surround channel for example.
The 3 speaker modes FMOD_DSP_TRANSCEIVER_SPEAKERMODE_MONO, FMOD_DSP_TRANSCEIVER_SPEAKERMODE_STEREO, FMOD_DSP_TRANSCEIVER_SPEAKERMODE_SURROUND are stored as seperate buffers in memory for a tranmitter channel.
The 3 speaker modes FMOD_DSP_TRANSCEIVER_SPEAKERMODE_MONO, FMOD_DSP_TRANSCEIVER_SPEAKERMODE_STEREO, FMOD_DSP_TRANSCEIVER_SPEAKERMODE_SURROUND are stored as separate buffers in memory for a tranmitter channel.
To save memory, use 1 common speaker mode for a transmitter.
The transceiver is double buffered to avoid desyncing of transmitters and receivers. This means there will be a 1 block delay on a receiver, compared to the data sent from a transmitter.

View file

@ -1941,7 +1941,7 @@ public:
BF_AST_TYPE(BfReplaceNode, BfAstNode);
}; BF_AST_DECL(BfReplaceNode, BfAstNode);
//TODO: Should we have a seperate BfIdentifierExpression?
//TODO: Should we have a separate BfIdentifierExpression?
class BfIdentifierNode : public BfExpression
{
public:

View file

@ -4281,7 +4281,7 @@ bool BfReducer::IsTerminatingExpression(BfAstNode* node)
chevronDepth++;
break;
case BfToken_RChevron:
// If we find a < and > that are not seperated by parens, that's a generic, which must be a
// If we find a < and > that are not separated by parens, that's a generic, which must be a
// variable decl if it's not in parens
if ((parenDepth == 0) && (chevronDepth > 0))
return false;