This is the "blank" core template for compiling your own Cores as dynamic modules. More...

#include <synthlabcore.h>

Inheritance diagram for SynthLab::SynthLabCore:

Public Member Functions
	SynthLabCore ()
	Construction: Cores follow the same construction pattern. More...

virtual bool	reset (CoreProcData &processInfo) override
	Resets object to initialized state. More...

virtual bool	update (CoreProcData &processInfo) override
	Updates the object for the next block of audio processing. More...

virtual bool	render (CoreProcData &processInfo) override
	Renders the output of the module. More...

virtual bool	doNoteOn (CoreProcData &processInfo) override
	Note-on handler for the ModuleCore. More...

virtual bool	doNoteOff (CoreProcData &processInfo) override
	Note-off handler for the ModuleCore. More...

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

virtual int32_t	getState () override

virtual bool	shutdown () override
	Shutdown handler for EG. More...

virtual void	setSustainOverride (bool b) override
	Sustain pedal handler for EG. More...

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

void	flushDelays ()

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

double	renderSample (SynthClock &clock, double shape=0.5)
	Renders one sample out of the wavetable Core Specific: More...

double	renderHardSyncSample (SynthClock &clock, double shape=0.5)
	Renders one hard-synced sample from the wavetable Core Specific: More...

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

virtual int32_t	getState () override

virtual bool	shutdown () override

virtual void	setSustainOverride (bool b) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

double	renderSample (SynthClock &clock, double shape=0.5)

double	renderHardSyncSample (SynthClock &clock, double shape)

bool	createTables (double sampleRate=44100.0)
	Table Creation funciont. More...

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

virtual int32_t	getState () override

virtual bool	shutdown () override

virtual void	setSustainOverride (bool b) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

double	renderSample (SynthClock &clock)
	render a sample More...

double	renderHardSyncSample (SynthClock &clock)
	render a hard-sunk sample More...

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

double	renderSample (SynthClock &clock, bool forceLoop)

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

double	renderSawtoothSample (SynthClock &clock, bool advanceClock=true)
	BLEP sawtooth. More...

double	renderSquareSample (SynthClock &clock, double &sawtoothSample)
	sum of saws method More...

	SynthLabCore ()

virtual	~SynthLabCore ()

virtual bool	reset (CoreProcData &processInfo) override

virtual bool	update (CoreProcData &processInfo) override

virtual bool	render (CoreProcData &processInfo) override

virtual bool	doNoteOn (CoreProcData &processInfo) override

virtual bool	doNoteOff (CoreProcData &processInfo) override

Public Member Functions inherited from SynthLab::ModuleCore
	ModuleCore ()
	Constructs a ModuleCore. More...

virtual void	setStandAloneMode (bool b)

bool	startGlideModulation (GlideInfo &glideInfo)

uint32_t	getModuleType ()

const char *	getModuleName ()

void *	getModuleHandle ()

void	setModuleHandle (void *handle)

uint32_t	getModuleIndex ()

void	setModuleIndex (uint32_t index)

int32_t	getPreferredModuleIndex ()

void	setPreferredModuleIndex (uint32_t index)

ModuleCoreData &	getModuleData ()
	provides access to the core data: More...

Protected Types
enum	{ a0, a1, a2, b1, b2, c0, d0 }

enum	{ kNylonGtr, kDistGtr, kBass, kSilent }

Protected Member Functions
void	calcAttackCoeff (double attackTime, double attackTimeScalar=1.0)

void	calcDecayCoeff (double decayTime, double decayTimeScalar=1.0)

void	calcReleaseCoeff (double releaseTime, double releaseTimeScalar=1.0)

void	checkAddWavetable (SynthLabTableSet &slTableSet, CoreProcData &processInfo, uint32_t waveIndex)
	helper function to check database for wavetable and add it if the table does not exist More...

double	renderSample (SynthClock &clock, bool forceLoop)
	Renders one sample out of the wavetable Core Specific: More...

double	setStepInc (double timeMsec, double scale=1.0)
	Calculates linear step increment based on time in millisecs. More...

void	checkAddSampleSet (std::string sampleDirectory, std::string sampleName, CoreProcData &processInfo, uint32_t index)
	Query the PCM database and add sample sources as needed. More...

double	setStepInc (double timeMsec, double scale=1.0)

void	checkAddSampleSet (std::string sampleDirectory, std::string sampleName, CoreProcData &processInfo, uint32_t index)
	query and add a sample set to the database

void	addMorphBankData (std::string name, SynthLabBankSet &slTableSet, uint32_t index)
	add a bank top database More...

void	checkAddWaveBank (SynthLabBankSet &slTableSet, CoreProcData &processInfo, uint32_t waveIndex)
	Calls the querying function to check and add a new wavebank (set of wavetables) More...

int32_t	checkAddWavetable (SynthLabTableSet &slTableSet, StaticTableSource *tableSource, CoreProcData &processInfo)
	Function that queries the datbase for the various tables based on unique table names. More...

void	checkAddSampleSet (std::string sampleDirectory, std::string sampleName, CoreProcData &processInfo, uint32_t index)

Protected Attributes
double	sampleRate = 1.0
	sample rate More...

bool	noteOff = false
	for retriggering EG More...

bool	retriggered = false
	for retriggering EG More...

double	lastTriggerMod = 0.0
	for retriggering EG trigger detection More...

double	sustainLevel = 1.0
	level, not time

double	attackTime_mSec = 1.0
	att: is a time duration

double	decayTime_mSec = 1.0
	dcy: is a time to decay from max output to 0.0

double	releaseTime_mSec = 1.0
	rel: is a time to decay from max output to 0.0

double	envelopeOutput = 0.0
	the current envelope output sample More...

double	attackCoeff = 0.0
	exponential feedback coefficient

double	attackOffset = 0.0
	TCO offset to allow proper attack/decay on [1, 0].

double	attackTCO = 0.0
	TCO value for calculating offset.

double	decayCoeff = 0.0
	exponential feedback coefficient

double	decayOffset = 0.0
	TCO offset to allow proper attack/decay on [1, 0].

double	decayTCO = 0.0
	TCO value for calculating offset.

double	releaseCoeff = 0.0
	exponential feedback coefficient

double	releaseOffset = 0.0
	TCO offset to allow proper attack/decay on [1, 0].

double	releaseTCO = 0.0
	TCO value for calculating offset.

bool	sustainOverride = false
	if true, places the EG into sustain mode

bool	releasePending = false
	a flag set when a note off event occurs while the sustain pedal is held, telling the EG to go to the release state once the pedal is released

double	incShutdown = 0.0
	shutdown linear incrementer

EGState	state = EGState::kOff
	EG state variable. More...

BQAudioFilter	filter [STEREO_CHANNELS]
	biquad audio filter objects

double	outputAmp = 1.0
	output scaling More...

double	midiPitch = 440.0
	midi note pitch More...

std::unique_ptr< BasicLookupTables >	lookupTables = nullptr
	LUTs for some waveforms.

double	outputValue = 0.0
	current output, More...

double	rshOutputValue = 0.0
	current output,

SynthClock	lfoClock
	timbase

bool	renderComplete = false
	flag for one-shot

NoiseGenerator	noiseGen
	for noise based LFOs

Timer	sampleHoldTimer
	for sample and hold waveforms

Timer	delayTimer
	LFO turn on delay.

RampModulator	fadeInModulator
	LFO fade-in modulator.

double	outputAmplitude = 1.0
	amplitude in dB

double	panLeftGain = 0.707
	left channel gain

double	panRightGain = 0.707
	right channel gain

int32_t	currentWaveIndex = -1
	to minimize dictionary (map) lookup iterating

SynthClock	oscClock
	the oscillator timebase More...

IWavetableSource *	selectedTableSource = nullptr
	selected table More...

Synchronizer	hardSyncronizer
	hard sync helper More...

StaticTableSource	wavetables [MODULE_STRINGS]

bool	oneShotDone = false
	one-shot flag More...

DrumWTSource	drumTables [MODULE_STRINGS]

double	egStepInc = 0.0
	linear time stepping More...

double	attackTimeScalar = 0.0
	for MIDI modulations to attack time More...

double	decayTimeScalar = 0.0
	for MIDI modulations to decay time More...

double	linearEnvOutput = 0.0
	current outupt

double	curveEnvOutput = 0.0
	current outupt

double	dxOutput = 0.0
	final output value

double	releaseLevel = 0.0
	release end point

bool	resetToZero = false
	notes the EG is in reset-to-zero mode

double	modStrength = 1.0
	current output,

SynthClock	fmOpClock [NUM_FMLFO_OPS]
	for 3 operators

SineTableSource	sineTableSource
	a single sinewave table More...

std::unique_ptr< DXEG >	dxEG = nullptr
	an EG for FM modulation

std::shared_ptr< EGParameters >	dxEGParameters = nullptr
	EG parameters for controlling the EG.

double	currentTableRate = 0.0
	sample rate

double	hardSyncRatio = 1.0
	for hard sync More...

DynamicTableSource	dynamicTableSource
	dynamic tables come out of this source

uint32_t	pluckPosition = 1
	position: 0 = at nut, 1 = at center of string

double	saturation = 1.0
	for distortion control

Exciter	exciter
	exciter for KS model

Resonator	resonator
	resonator for KS model

HighShelfFilter	highShelfFilter
	filter for adding bite to exciter

LP2Filter	bassFilter
	for bass guitar pickup simulation

LP2Filter	distortionFilter
	for soft clip distortion

PluckPosFilter	pluckPosFilter
	for simulating pluck position with comb filter

ParametricFilter	bodyFilter
	sinple parameteric filter for adding a resonant hump to th output More...

double	readIndex = 0.0
	must persist between update and render More...

double	phaseInc = 0.0
	must persist between update and render More...

uint32_t	currentIndex = 0
	must persist between update and render More...

IPCMSampleSource *	selectedSampleSource = nullptr
	current PCM sample More...

SynthLabPCMSource	pcmSources [MODULE_STRINGS]

int32_t	currentTable0 = -1
	to minimize dictionary (map) lookup iterating

int32_t	currentTable1 = -1
	to minimize dictionary (map) lookup iterating

double	mixValue0 = 0.0

double	mixValue1 = 0.0

MorphBankData	morphBankData [MODULE_STRINGS]
	morphing bank of wavetables

int32_t	table0last = -1
	running index of last table_0

int32_t	table1last = -1
	running index of last table_1

double	morphLocation = 0.0
	fractional location to morph between table_0 and table_1

double	lastMorphMod = -10.0
	last morph modulator

DrumWTSource	sfxTables [MODULE_STRINGS]
	pitchless wavetable sets

VA1Filter	va1 [STEREO]
	1st order VA

VASVFilter	svf [STEREO]
	SVF.

VAKorg35Filter	korg35 [STEREO]
	Korg35.

VAMoogFilter	moog [STEREO]
	moog

VADiodeFilter	diode [STEREO]
	diode

FilterModel	selectedModel = FilterModel::kFirstOrder

uint32_t	outputIndex = 0
	selected output

bool	forceDualMonoFilters = false
	DM option for slow machines.

Limiter	limiter [STEREO]
	limiters to squelch oscillations

double	pulseWidth = 0.5
	[0.5, 0.95] for square wave only

Protected Attributes inherited from SynthLab::ModuleCore
uint32_t	moduleType = UNDEFINED_MODULE
	type of module, LFO_MODULE, EG_MODULE, etc...

const char *	moduleName = nullptr
	module name must be set in derived constructor

void *	moduleHandle = nullptr
	used for dynamically loading cores from DLLs

uint32_t	moduleIndex = 0
	index of this core

int32_t	preferredIndex = -1
	preferred index of this DYNAMIC core

ModuleCoreData	coreData
	core strings (16) and mod knob labels (4)

bool	standAloneMode = false
	flag for stand-alone mode of operation outside of SynthLab

std::unique_ptr< GlideModulator >	glideModulator
	built-in glide modulator for oscillators

Detailed Description

This is the "blank" core template for compiling your own Cores as dynamic modules.

PCM oscillator that plays wave-slices that are mapped to the C-major scale keys starting at middle C.

Virtual Analog oscillator implementation.

Implements all of the virtual analog (VA) filters in the Synth Book using sub-filtering objects.

Wavetable oscillator with one-shot sound-effects (SFX) extracted into wavetables from WAV files.

Morphing Wavetable oscillator.

PCM oscillator using Mellotron(R) samples freely available.

Simplest EG of all, using linear segments - the place to start to build your own EG from scratch.

PCM oscillator using the same multi-samples from the 1st edition of the Synth Book.

Implements three Karplus-Strong algorithms to generate.

Fourier wavetable oscillator with sine and parabola waveforms.

Sinusoidal-only oscillator and attached EG.

LFO using simple FM algorithms for interesting modulators.

Yamaha DX EG-based.

Wavetables that implement electronic drum samples; these samples were extracted from WAV files and converted into wavetables using RackAFX-TableMaker.

Wavetable oscillator with classic waveforms.

LFO that renders all classical and many noisy wavforms.

Implements Filters via BiQuad structures; includes one pole HPF and LPF.

Analog EG emulator.

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: Depends on the type of Core you are implementing

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Render:

Oscillators and Filters:

processes all audio samples in block
processes from input buffer to output buffer using pointers in the CoreProcData argument

EGs

renders into the modulation output array that is passed into the function via the CoreProcData structure and populates the arrays with index values of:
kEGNormalOutput normal EG output value
kEGBiasedOutput biased EG (sustain level subtracted out)

LFOs 1.renders into the modulation output array that is passed into the function via the CoreProcData structure and populates the arrays with index values of:

kLFONormalOutput normal LFO output value
kLFOInvertedOutput 180 degrees out of phase with normal output
kUnipolarFromMax unipolar version of the waveform that sits at +1 when the output amplitude is at 0, and descends from +1 downward as the output amplitude is increases; used for tremolo
kUnipolarFromMin unipolar version of the waveform that sits at 0 when the output amplitude is at 0, and ascends from 0 upward as the output amplitude is increases; the ordinary unipolar version

Filters

renders into the output buffer using pointers in the CoreProcData argument to the render function
processes one block of audio input into one block of audio output per render cycle
processes in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: EGParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

ADSR, AR

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Start Lvl"
MOD_KNOB_B = "B"
MOD_KNOB_C = "C"
MOD_KNOB_D = "D"

Render:

renders into the modulation output array that is passed into the function via the CoreProcData structure and populates the arrays with index values of:
kEGNormalOutput normal EG output value
kEGBiasedOutput biased EG (sustain level subtracted out)
designed to operate in a block-fasion, knowing that only the first output sample will be used

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: FilterParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

No_Filter, _1PLPF, _1PHPF, BQ_LPF2, BQ_HPF2

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Key Track"
MOD_KNOB_B = "Drive"
MOD_KNOB_C = "EG Int"
MOD_KNOB_D = "BP Int"

Render:

processes all audio samples in block
processes from input buffer to output buffer using pointers in the CoreProcData argument

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

demonstrates use of BasicLookupTables
demonstrates use of NoiseGenerator
demonstrates use of RampModulator for fade-in
demonstrates use of Timers for sample and hold and simple time delay

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: LFOParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

triangle, sine ,ramp_up, ramp_dn, exp_up, exp_dn, exp_tri, square, rand_SH1, pluck

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Shape"
MOD_KNOB_B = "Delay"
MOD_KNOB_C = "FadeIn"
MOD_KNOB_D = "BPM Sync"

Render:

renders into the modulation output array that is passed into the function via the CoreProcData structure and populates the arrays with index values of:
kLFONormalOutput normal LFO output value
kLFOInvertedOutput 180 degrees out of phase with normal output
kUnipolarFromMax unipolar version of the waveform that sits at +1 when the output amplitude is at 0, and descends from +1 downward as the output amplitude is increased; used for tremolo
kUnipolarFromMin unipolar version of the waveform that sits at 0 when the output amplitude is at 0, and ascends from 0 upward as the output amplitude is increased; the ordinary unipolar version
designed to operate in a block-fasion, knowing that only the first output sample will be used

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

demonstrates use of IWavetableSource interface object

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: WTOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

ana_saw, ana_sqr, fm_bass1, fm_bass2, fm_organ, vs_saw, vs_octsqr, vs_buzz, akwf_br7, akwf_br12, akwf_br17, akwf_br24, akwf_dst15, akwf_dst22, akwf_dst27, akwf_tri11

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Shape"
MOD_KNOB_B = "HSync"
MOD_KNOB_C = "Phase"
MOD_KNOB_D = "D"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

This is one of the simplest wavetable oscillator cores because the samples are pitchless and there is no pitch modulation applied. Pitch modulation addition is an excellent homework chore.

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: WTOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

Kick_1, Kick_2, Kick_3, Snare_1, Snare_2, Snare_3, Closed_HH, Open_HH, Tom_1, Tom_2, Tom_3, Tom_4, Tom_5, Crash_1, Crash_2, Crash_3

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "A"
MOD_KNOB_B = "B"
MOD_KNOB_C = "C"
MOD_KNOB_D = "D"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: EGParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

ADSlSR, ADSlR

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Start Lvl"
MOD_KNOB_B = "Decay Lvl"
MOD_KNOB_C = "Slope Time"
MOD_KNOB_D = "Curvature"

Render:

renders into the modulation output array that is passed into the function via the CoreProcData structure and populates the arrays with index values of:
kEGNormalOutput normal EG output value
kEGBiasedOutput biased EG (sustain level subtracted out)
designed to operate in a block-fasion, knowing that only the first output sample will be used

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: LFOParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

FM_2, FM_3A, FM_3B

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Shape"
MOD_KNOB_B = "Ratio"
MOD_KNOB_C = "Index"
MOD_KNOB_D = "BPM Sync"

Render:

renders into the modulation output array that is passed into the function via the CoreProcData structure and populates the arrays with index values of:
kLFONormalOutput normal LFO output value
kLFOInvertedOutput 180 degrees out of phase with normal output
kUnipolarFromMax unipolar version of the waveform that sits at +1 when the output amplitude is at 0, and descends from +1 downward as the output amplitude is increased; used for tremolo
kUnipolarFromMin unipolar version of the waveform that sits at 0 when the output amplitude is at 0, and ascends from 0 upward as the output amplitude is increased; the ordinary unipolar version
designed to operate in a block-fasion, knowing that only the first output sample will be used

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

you may add more waveforms to this object to completely change the DX synth!
includes a standalone DXEG object for FMOperator
demonstrates use of SineTableSource object

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: FMOperatorParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

sinewave

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "A"
MOD_KNOB_B = "B"
MOD_KNOB_C = "C"
MOD_KNOB_D = "F.Back"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

demonstrates use of SineTableSource object
demonstrates use of DynamicTableSource object
demonstrates use of IWavetableSource interface
Dynamic tables: created at runtime rather than static arrays & re-created if sample rate changes

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: WTOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

sinewave, parabola

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Shape"
MOD_KNOB_B = "HSync"
MOD_KNOB_C = "Phase"
MOD_KNOB_D = "D"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

nylong string guitar
electric guitar (with soft clipping amplifier)
bass guitar Includes very specialized objects
Exciter exciter; ///< exciter for KS model
Resonator resonator; ///< resonator for KS model
PluckPosFilter pluckPosFilter; ///< for simulating pluck position with comb filter
ParametricFilter bodyFilter; ///< sinple parameteric filter for adding a resonant hump to th output

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: KSOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

nylon, dist gtr, bass

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Detuning"
MOD_KNOB_B = "Output"
MOD_KNOB_C = "Bite"
MOD_KNOB_D = "Pluck Pos"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

demonstrates use of IPCMSampleSource interface object
demonstrates simplest PCM oscillator
samples are bass-oriented and culled from FutureMusic magazine's free samples

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: PCMOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

Dagga, DigPuff, Divider, Doom, Dumma, Fazzy, FuzzVibe, Heaver, KickWob, Knocka, MultiWave, OldFlatty, Polsar, Quorum, RazzBass, Wobbular

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "A"
MOD_KNOB_B = "B"
MOD_KNOB_C = "C"
MOD_KNOB_D = "D"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: EGParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

ADSR

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Start Lvl"
MOD_KNOB_B = "B"
MOD_KNOB_C = "C"
MOD_KNOB_D = "D"

Render:

renders into the modulation output array that is passed into the function via the CoreProcData structure and populates the arrays with index values of:
kEGNormalOutput normal EG output value
kEGBiasedOutput biased EG (sustain level subtracted out)
designed to operate in a block-fasion, knowing that only the first output sample will be used

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

demonstrates use of IPCMSampleSource interface object
changes operation form Synth Book; was one-shot and now it loops
samples are very long in duration > 7 seconds

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: PCMOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

Cello, Choir, M300_Brass, M300A, M300B, MK2_Brass, MK2_Flute, MK2_Violins, String_Section, Woodwinds

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "A"
MOD_KNOB_B = "B"
MOD_KNOB_C = "C"
MOD_KNOB_D = "D"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

demonstrates morphing between two IWavetableSources
demonstrates use of MorphBankData to store a bank of wavetable oscillator waveforms
morphs across a range of up to 16 waveforms, each of which is a set of high-resolution wavetables
allows hard-sync of wavetables during morph (!!)

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: WTOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

PrimalWaves, DigiDoo1, DigiDoo2, DigiDoo3, SawDemon, SquareDuty,S quareComb, SquareRing, SineMorph, Dentist

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "A"
MOD_KNOB_B = "HSync"
MOD_KNOB_C = "MorphStart"
MOD_KNOB_D = "MorphMod"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

demonstrates use of IWavetableSource interface object
demonstrates use of DrumWTSource for storing pitch-less wavetables

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: WTOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

Creme, JawBreak, Laser, Minipop, Noisey, Ploppy, Pop, RobotPunch, Seeit, Speeder, Splok, Sploop, SprinGun, Swish, Swoosh, WackaBot

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Shape"
MOD_KNOB_B = "HSync"
MOD_KNOB_C = "Phase"
MOD_KNOB_D = "D"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

breaks filters into families (1st order, SVF, Korg, Moog, Diode) and generates ALL outputs for that family at once

Demonstrates use of following VAFilter objects:

VA1Filter first order filters
VASVFilter state variable filters
VAKorg35Filter Korg35 filters
VAMoogFilter Moog filters
VADiodeFilter Diode ladder filter (VCS3)

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: FilterParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

No_Filter, LPF1, HPF1, APF1, SVF_LP, SVF_HP, SVF_BP, SVF_BS, Korg35_LP, Korg35_HP, Moog_LP1, Moog_LP2, Moog_LP3, Moog_LP4, Diode_LP4

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "Key Track"
MOD_KNOB_B = "Drive"
MOD_KNOB_C = "EG Int"
MOD_KNOB_D = "BP Int"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
processes one block of audio input into one block of audio output per render cycle
processes in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

This object outputs both square, saw, or a blend of these two; great for TB303 emulation or Oberheim SEM

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: VAOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

saw/sqr, sawtooth, square

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "WaveMix"
MOD_KNOB_B = "PulseWidth"
MOD_KNOB_C = "C"
MOD_KNOB_D = "D"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

demonstrates IPCMSampleSource for storing PCM samples on database

Used Aubio tools to generate the slice WAV files, but may be done with any app.

Base Class: ModuleCore

Overrides the five (5) common functions plus a special getParameters() method to return a shared pointer to the parameters structure.
NOTE: These functions have identical names as the SynthModules that own them, however the arguments are different. ModuleCores use the CoreProcData structure for passing arguments into the cores because they are thunk-barrier compliant.
This means that the owning SynthModule must prepare this structure and populate it prior to function calls. The large majority of this preparation is done in the SynthModule constructor and is one-time in nature.

GUI Parameters: PCMOscParameters

GUI parameters are delivered into the core via the thunk-barrier compliant CoreProcData argument that is passed into each function identically
processInfo.moduleParameters contains a void* version of the GUI parameter structure pointer
the Core function casts the GUI parameter pointer prior to usage

Access to Modulators is done via the thunk-barrier compliant CoreProcData argument

processInfo.modulationInputs
processInfo.modulationOutputs

Access to audio buffers (I/O/FM) is done via the thunk-barrier compliant CoreProcData argument

processInfo.inputBuffers
processInfo.outputBuffers
processInfo.fmBuffers

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Standalone Mode:

These objects are designed to be internal members of the outer SynthModule that owns them. They may be used in standalone mode without modification, and you will use the CoreProcData structure to pass information into the functions.

Module Strings, zero-indexed for your GUI Control:

keys, lucci, ob6, darkpiano

ModKnob Strings, for fixed GUI controls by index constant

MOD_KNOB_A = "A"
MOD_KNOB_B = "B"
MOD_KNOB_C = "C"
MOD_KNOB_D = "D"

Render:

renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Author: Will Pirkle http://www.willpirkle.com

Remarks: This object is included and described in further detail in Designing Software Synthesizer Plugins in C++ 2nd Ed. by Will Pirkle

Version: Revision : 1.0

Date: Date : 2021 / 04 / 26

Constructor & Destructor Documentation

◆ SynthLabCore() [1/19]

SynthLab::SynthLabCore::SynthLabCore ( )

Construction: Cores follow the same construction pattern.

Constructs Construction: Cores follow the same construction pattern.

Constructs FM oscillator Core including standalone DXEG object.

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

depends on your core type

Returns: the newly constructed object

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

implements two EG contours, ADSR and AR
you can add more here
sets up attack and release time constants based on analog capacitor charge/discharge rates
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

implements a few of the filters from Will Pirkle's FX Plugin book
includes one pole HPF, LPF
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

creates new lookup table, which are compact in nature (no reason to share the resource)
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

uses SynthLab::SynthLabTableSet structure to describe the wavetables in the #included directories
you are free to create your own custom table descriptions
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables
in addition, this core adds its tables directly to setup the database

Core Specific:

tables are defined in wavetables/drumtables.h file
uses DrumWTSource to store pointers to the tables
gets table pointers from database
uses static
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

two EG contours are supported
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

uses simple FM to create complex LFO patterns
three FM algoriths are implemented, add more here

Construction: Cores follow the same construction pattern

set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

demonstrates Fourier Synthesis; see createTables()
implements two Fourier tables, add more here
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

Waveform names are the names of folders in the container folder
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

simplest of all EGs
only one EG contour implemented
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

Waveform names are the names of folders in the \ container folder
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

uses MorphBankData structures to hold information about these STATIC structures
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

note use of DrumWTSource structures to hold table information here; this is not dynamic data and is small in size and nature
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

note the way this core stores families of filters
each filter family produces all filter outputs at once
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

the one and only VA core object
uses BLEP correction
set the Module type and name parameters
expose the 16 module strings
expose the 4 mod knob label strings
intialize any internal variables

Core Specific:

uses Aubio to cut waveforms into slices
mapped to keyboard C-major scale starting at middle C

Member Function Documentation

◆ addMorphBankData()

void SynthLab::SynthLabCore::addMorphBankData	(	std::string	name,
		SynthLabBankSet &	slBankSet,
		uint32_t	index
	)

protected

add a bank top database

Adds a set of tables to the morph bank data structures, storing names of the tables.

Core Specific:

nothing to do

Parameters

name	name of wavetable
slBankSet	set of sets-of-tables to be added
index	index in MorphBankData structure

◆ calcAttackCoeff()

void SynthLab::SynthLabCore::calcAttackCoeff	(	double	attackTime,
		double	attackTimeScalar = `1.0`
	)

inlineprotected

Calculate Time Coefficients

◆ calcDecayCoeff()

void SynthLab::SynthLabCore::calcDecayCoeff	(	double	decayTime,
		double	decayTimeScalar = `1.0`
	)

inlineprotected

Calculate Time Coefficients

◆ calcReleaseCoeff()

void SynthLab::SynthLabCore::calcReleaseCoeff	(	double	releaseTime,
		double	releaseTimeScalar = `1.0`
	)

inlineprotected

Calculate Time Coefficients

◆ checkAddSampleSet()

void SynthLab::SynthLabCore::checkAddSampleSet	(	std::string	sampleDirectory,
		std::string	sampleName,
		CoreProcData &	processInfo,
		uint32_t	index
	)

protected

Query the PCM database and add sample sources as needed.

Query the database and add a set of PCM samples if not existing already.

Parameters

sampleDirectory	dirctory full of PCM WAV files ]param sampleName name of this sample set to check
processInfo	is the thunk-barrier compliant data structure for passing all needed parameters
sampleDirectory	folder full of folders of samples
sampleName	name of sub-folder with set of PCM samples
processInfo	the thunk-barrier compliant data structure for passing all needed parameters

◆ checkAddWaveBank()

void SynthLab::SynthLabCore::checkAddWaveBank	(	SynthLabBankSet &	slBankSet,
		CoreProcData &	processInfo,
		uint32_t	waveIndex
	)

protected

Calls the querying function to check and add a new wavebank (set of wavetables)

Parameters

slBankSet	set of banks to be added
processInfo	is the thunk-barrier compliant data structure for passing all needed parameters
waveIndex	index of module-string array corresponding to this set

◆ checkAddWavetable() [1/2]

void SynthLab::SynthLabCore::checkAddWavetable	(	SynthLabTableSet &	slTableSet,
		CoreProcData &	processInfo,
		uint32_t	waveIndex
	)

protected

helper function to check database for wavetable and add it if the table does not exist

wavetables are identified with unique waveform name string
uses static table sources since these wavetables are fixed and never re-calculated
sets the unique index of the table in the database for faster parsing; you may still use the unique name string as a means of lookup, but it will slow the update() function a bit

Core Specific:

nothing to do

Parameters

slTableSet	a set of wavetables for a single waveform
processInfo	is the thunk-barrier compliant data structure for passing all needed parameters
waveIndex	index of the module-string that corresponds to this table; used for fast lookup

◆ checkAddWavetable() [2/2]

int32_t SynthLab::SynthLabCore::checkAddWavetable	(	SynthLabTableSet &	slTableSet,
		StaticTableSource *	tableSource,
		CoreProcData &	processInfo
	)

protected

Function that queries the datbase for the various tables based on unique table names.

this is a set-wise version of the same function found on the non-morphing cores

Parameters

slTableSet	set of tables tp be added
processInfo	is the thunk-barrier compliant data structure for passing all needed parameters

Returns: index of table in database if successful, -1 otherwise

◆ createTables()

bool SynthLab::SynthLabCore::createTables ( double sampleRate = 44100.0 )

Table Creation funciont.

Dynamic table creation, based on fx

creates a parabola waveform
bandlimited to each MIDI note's capabilities; calculates harmonic number limit

Parameters

sampleRate required for bandlimiting operation

Returns: true if successful, false otherwise

◆ doNoteOff()

bool SynthLab::SynthLabCore::doNoteOff ( CoreProcData & processInfo )

overridevirtual

Note-off handler for the ModuleCore.

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

checks the sustain override flag and releases the note if needed
goes to release or off mode

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

nothing to do here

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

nothing to do

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

sends attached EG into release phase

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

Implements SynthLab::ModuleCore.

◆ doNoteOn()

bool SynthLab::SynthLabCore::doNoteOn ( CoreProcData & processInfo )

overridevirtual

Note-on handler for the ModuleCore.

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

sets the finite state machine for another run
checks attack and decay scaling (only caclulated once per note-event)

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

saves MIDI pitch in case of key-tracking modulation
flushes biquad state variable delay lines

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

reset delay timer and fade-in ramp modulator
reset sample and hold timer
reset timebase for next run

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

saves MIDI pitch for modulation calculation in update() function
sets wavetable start-read location (aka "Phase")

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

resets the clock
sets one-shot flag

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

resets FM operator clocks when not in free-run mode
resets rendering flag

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

saves MIDI pitch for modulation calculation in update() function
resets timebase
rests DXEG for another run

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

saves MIDI pitch for modulation calculation in update() function
resets all sub-filters and objects

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

saves MIDI pitch for modulation calculation in update() function
resets read index values to -1 indicating a new note event

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

saves MIDI pitch for modulation calculation in update() function
resets PCM sample lookup index

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

saves MIDI pitch for modulation calculation in update() function
resets table index values to -1 indicating a new note event

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

reset clock
reset one-shot flag

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

saves MIDI pitch for key tracking

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
MIDI note information is accessed via processInfo.noteEvent

Core Specific:

saves MIDI pitch for modulation calculation in update() function
resets clock, sets phase depending on waveform

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

Implements SynthLab::ModuleCore.

◆ flushDelays()

void SynthLab::SynthLabCore::flushDelays ( )

inline

flush biquad delays on reset and new note events

◆ getState() [1/3]

virtual int32_t SynthLab::SynthLabCore::getState ( )

inlineoverridevirtual

ModuleCore Overrides for EG Cores only

Reimplemented from SynthLab::ModuleCore.

◆ getState() [2/3]

virtual int32_t SynthLab::SynthLabCore::getState ( )

inlineoverridevirtual

ModuleCore Overrides for EG Cores only

Reimplemented from SynthLab::ModuleCore.

◆ getState() [3/3]

virtual int32_t SynthLab::SynthLabCore::getState ( )

inlineoverridevirtual

ModuleCore Overrides for EG Cores only

Reimplemented from SynthLab::ModuleCore.

◆ render()

bool SynthLab::SynthLabCore::render ( CoreProcData & processInfo )

overridevirtual

Renders the output of the module.

Renders one block of audio data Core Specific:

write modulator output with: processInfo.modulationOutputs->setModValue( )

Core Specific:

see class declaration (comments and Doxygen docs) about where to write output values
see template below

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

write modulator output with: processInfo.modulationOutputs->setModValue( ) Core Specific:
runs the finite state machine for the EG
runs the FSM on each sample interval, but only use the output of the first loop (see book)

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

processes from input buffer to output buffer using pointers in the CoreProcData argument Core Specific:
filter sub-objects perform processing
implements drive control with arc-tangent waveshaper

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

write modulator output with: processInfo.modulationOutputs->setModValue( ) Core Specific:
runs delay timer first
runs LFO next,
applies fade-in modulation if needed
then modifies outputs:
kLFONormalOutput normal LFO output value
kLFOInvertedOutput 180 degrees out of phase with normal output
kUnipolarFromMax unipolar version of the waveform that sits at +1 when the output amplitude is at 0, and descends from +1 downward as the output amplitude is increases; used for tremolo
kUnipolarFromMin unipolar version of the waveform that sits at 0 when the output amplitude is at 0, and ascends from 0 upward as the output amplitude is increases; the ordinary unipolar version

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

renders to output buffer using pointers in the CoreProcData argument
supports FM via the pmBuffer if avaialble; if pmBuffer is NULL then there is no FM Core Specific:
call rendering sub-function
apply and remove phase offsets for phase modulation (FM)
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

renders to output buffer using pointers in the CoreProcData argument
calls rendering sub-function
the simplest render function of any oscillator

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

write modulator output with: processInfo.modulationOutputs->setModValue( ) Core Specific:
kLFONormalOutput normal LFO output value
kLFOInvertedOutput 180 degrees out of phase with normal output
kUnipolarFromMax unipolar version of the waveform that sits at +1 when the output amplitude is at 0, and descends from +1 downward as the output amplitude is increased; used for tremolo
kUnipolarFromMin unipolar version of the waveform that sits at 0 when the output amplitude is at 0, and ascends from 0 upward as the output amplitude is increased; the ordinary unipolar version

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

gets EG output value for the entire block
applies instantaneous phase modulation to synth clock timebase by addition
runs the oscillator for one sample period
applies EG contour to output of oscillator
includes self-modulation state variable if connected
renders into the output buffer using pointers in the CoreProcData argument to the render function
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Parameters

processInfo is the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

renders to output buffer using pointers in the CoreProcData argument
supports FM via the pmBuffer if avaialble; if pmBuffer is NULL then there is no FM Core Specific:
calls the subfiltering in this order:
(1) render exciter output sample
(2) apply high-shelf filter -> pluck position filter
(3) render the resonator using the filtered input
(4) apply distortion for electric guitar
(5) process through body filter

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

renders to output buffer using pointers in the CoreProcData argument
supports FM via the pmBuffer if avaialble; if pmBuffer is NULL then there is no FM Core Specific:
simple reading of PCM wave buffer
no FM
applies gain/volume
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

renders to output buffer using pointers in the CoreProcData argument
does not support FM Core Specific:
read PCM sample from source (may be mono or stereo)
write to output buffers

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

processes input to output buffer using pointers in the CoreProcData argument Core Specific:
process left and right channels through independent filters
apply peak limiter
renders one block of audio per render cycle
renders in mono that is copied to the right channel as dual-mono stereo

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

renders to output buffer using pointers in the CoreProcData argument
supports FM via the pmBuffer if avaialble; if pmBuffer is NULL then there is no FM Core Specific:
call rendering sub-function
allows mix of square and saw (a la Oberhiem SEM)

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

< current outupt

Implements SynthLab::ModuleCore.

◆ renderHardSyncSample() [1/2]

double SynthLab::SynthLabCore::renderHardSyncSample	(	SynthClock &	clock,
		double	shape = `0.5`
	)

Renders one hard-synced sample from the wavetable Core Specific:

calls renderSample() for the main and reset oscillators as needed
detects new reset signal and restarts synchronizer

Parameters

clock	the current timebase
shape	the shape amount [-1, +1] from GUI and/or modulation

Returns: true if successful, false otherwise

◆ renderHardSyncSample() [2/2]

double SynthLab::SynthLabCore::renderHardSyncSample ( SynthClock & clock )

render a hard-sunk sample

Renders one hard-synced sample from the wavetable Core Specific:

calls renderSample() for the main and reset oscillators as needed
detects new reset signal and restarts synchronizer

Parameters

clock the current timebase

Returns: true if successful, false otherwise

◆ renderSample() [1/5]

double SynthLab::SynthLabCore::renderSample	(	SynthClock &	clock,
		bool	forceLoop
	)

Helper function for rendering

◆ renderSample() [2/5]

double SynthLab::SynthLabCore::renderSample	(	SynthClock &	clock,
		double	shape = `0.5`
	)

Helper functions for rendering

◆ renderSample() [3/5]

double SynthLab::SynthLabCore::renderSample	(	SynthClock &	clock,
		double	shape = `0.5`
	)

Renders one sample out of the wavetable Core Specific:

Helper functions for rendering

applies phase distortion for shape modulation

Parameters

clock	the current timebase
shape	the shape amount [-1, +1] from GUI and/or modulation

Returns: true if successful, false otherwise

◆ renderSample() [4/5]

double SynthLab::SynthLabCore::renderSample	(	SynthClock &	clock,
		bool	forceLoop
	)

protected

Renders one sample out of the wavetable Core Specific:

helper to render each sample from wavetable

reads drum table in one-shot fashion

Parameters

clock the current timebase

Returns: true if successful, false otherwise

applies phase distortion for shape modulation

Parameters

clock	the current timebase
forceLoop	true to force this sample to loop (repeated over duration)

Returns: true if successful, false otherwise

◆ renderSample() [5/5]

double SynthLab::SynthLabCore::renderSample ( SynthClock & clock )

render a sample

Renders one sample out of the wavetable Core Specific:

Render helper functions

note the check to see if we are at the end of the tables (morph = 1)
uses constant power morphing; you can try the others too: square law and linear

Parameters

clock the current timebase

Returns: true if successful, false otherwise

◆ renderSawtoothSample()

double SynthLab::SynthLabCore::renderSawtoothSample	(	SynthClock &	clock,
		bool	advanceClock = `true`
	)

BLEP sawtooth.

Renders a BLEP sawtooth sample Core Specific:

helper to render each sample

note the check to see how many points may be safely calculated per side of discontinuity
use trivial oscillator output and correct with BLEP

Parameters

clock	the current timebase
advanceClock	true to advance clock after render

Returns: true if successful, false otherwise

◆ renderSquareSample()

double SynthLab::SynthLabCore::renderSquareSample	(	SynthClock &	clock,
		double &	sawtoothSample
	)

sum of saws method

Renders a BLEP squarewave sample with sum-of-saws methog Core Specific:

see synth book for details on sum-of-saws

Parameters

clock the current timebase

Returns: true if successful, false otherwise

◆ reset() [1/19]

bool SynthLab::SynthLabCore::reset ( CoreProcData & processInfo )

overridevirtual

Resets object to initialized state.

parameters are accessed via the processInfo.moduleParameters pointer
resets and initializes clocks and timers
sets initial state variables

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
initializes sample rate dependent stuff via processInfo.sampleRate
calculates intitial coefficients
sets initial state variables

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
initialize timbase and hard synchronizer
check and add wavetables to the database

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
wavetable database is accessed via processInfo.wavetableDatabase
initialize timbase
check table sources and add if needed

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
resets and initializes the 3 SynthClock objects that are the operators
sets initial state variables

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
add the single sinusoidal wavetable to the database
reset the EG

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
initialize timbase and hard synchronizer
create new tables if fs changed, or on first reset -query and add new tables to database

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
reset member objects
setup bass filter with fc = 150 Hz, Q = 0.707
setup distortion filter with fc = 2000 Hz, Q = 1.0

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
initialize timbase and hard synchronizer
parses WAV folders and adds PCM samples to database as needed

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
sets start level and state varible

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
initialize timbase and hard synchronizer
finds WAV files in a common folder (name of instrument)
sample sets are loaded into database if not existing already

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
initialize timbase and hard synchronizer
check and add wavetable banks to the database
a bank is a set of wavetable sources

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
reset all filters
reset limiters

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
initialize timbase

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
finds PCM samples in WAV files
registers samples with database

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

Implements SynthLab::ModuleCore.

◆ setStepInc() [1/2]

double SynthLab::SynthLabCore::setStepInc	(	double	timeMsec,
		double	scale = `1.0`
	)

inlineprotected

Calculates linear step increment based on time in millisecs.

calculate new step size

Parameters

timeMsec the time in milliseconds scalar value for stretching or shrinking the final value

Returns: new step increment value

◆ setStepInc() [2/2]

double SynthLab::SynthLabCore::setStepInc	(	double	timeMsec,
		double	scale = `1.0`
	)

inlineprotected

calculate new step size

◆ setSustainOverride()

void SynthLab::SynthLabCore::setSustainOverride ( bool b )

overridevirtual

Sustain pedal handler for EG.

all EGs should implement this base class function
if turned off (pedal released), clears the pending release if exists
if turned on, sets the sustain pedal override to keep the EG stuck in the sustain state until the pedal is released

Reimplemented from SynthLab::ModuleCore.

◆ shutdown()

bool SynthLab::SynthLabCore::shutdown ( )

overridevirtual

Shutdown handler for EG.

all EGs should implement this base class function
calculates shutdown amp increment based on current output value

Returns: true if successful, false otherwise

Reimplemented from SynthLab::ModuleCore.

◆ update()

bool SynthLab::SynthLabCore::update ( CoreProcData & processInfo )

overridevirtual

Updates the object for the next block of audio processing.

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[]

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
recalculates attack/decay/release coefficients if needed
checks the re-trigger modulation input to alter state machine

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates fc modulation value from input modulators, kBipolarMod and kEGMod
calculates key-tracking modulation value (if enabled)
calculated the coefficients for various filters based on user selection

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
sets BPM Sync clocking if wanted
applies FM if needed (LFO1 can modulate LFO2's fo)
updates clock with current frquency
generates modulation values from RampModulator
generates timing values for sample/hold and delay

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates the pitch modulation value from GUI controls, input modulator kBipolarMod, and MIDI pitch bend
selects a wavetable based on modulated frequency to avoid aliasing
sets up hard-sync (this oscillator's unique modulation)
calculates final gain and pan values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
there is NO pitch modulation as these are pitchless drum samples
to add pitch modulation, see the ClassicWTCore object
calculates final gain and pan values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
is used in a standalone manner with the FMOperator object; the parameter messaging is direct, bypassing mod knobs
checks the re-trigger modulation input to alter state machine

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
supports sync-to-BPM as with the other LFOs
Uses three simple stacked FM algorithms: kFM2
- OP2 -> (OP1 * ratio)
kFM3A
- OP3 -> (OP2 * ratio) -> (OP1 * 1.414 * ratio)
kFM3B
- OP3 -> (OP2 * ratio) -> (OP1 * 0.707 * ratio)

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
forwards EG parameters to the member DXEG object
calcuates and applies pitch mod
calculates final gain and pan values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates the pitch modulation value from GUI controls, input modulator kBipolarMod, and MIDI pitch bend
selects a wavetable based on modulated frequency to avoid aliasing
sets up hard-sync (this oscillator's unique modulation)
calculates final gain and pan values
this is identical to the ClassicWTCore code; the only difference is dynamic tables

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates the pitch modulation value from GUI controls, input modulator kBipolarMod, and MIDI pitch bend
selects a wavetable based on modulated frequency to avoid aliasing
calculates pluck position filtering parameters Changes body filter parameters based on selected model:
nylong string: fc = 400Hz, Q = 1.0
distorted electric guitar: fc = 300Hz, Q = 2.0
bass guitar: fc = 250Hz, Q = 1.0

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates the pitch modulation value from GUI controls, input modulator kBipolarMod, and MIDI pitch bend
selects a PCM sample based on the oscillator's modulated frequency
calculates final gain and pan values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[]

Core Specific:

does NOT implement the re-trigger modulation to keep it as simple as possible

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates the pitch modulation value from GUI controls, input modulator kBipolarMod, and MIDI pitch bend
selects a PCM sample based on modulated frequency
calculates final gain and pan values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates the pitch modulation value from GUI controls, input modulator kBipolarMod, and MIDI pitch bend
selects a pair of wavetables based on modulated frequency AND morphing location across bank
sets up hard-sync (this oscillator's unique modulation)
calculates final gain and pan values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
NO pitch modulation for these SFX samples
selects a wavetable based on waveform name
calculates final gain and pan values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates the fc modulation value from GUI controls, input modulators kBipolarMod, and kEGMod
monitors key-tracking to adjust fc again if needed
calcualtes new filter coeffients once, then copies into reolicated filters (left/right)
calculates final gain and drive values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates the pitch modulation value from GUI controls, input modulator kBipolarMod, and MIDI pitch bend
calculates pulse width information (unique modulator for this oscillator)
calculates final gain and pan values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

parameters are accessed via the processInfo.moduleParameters pointer
modulator inputs are accessied via processInfo.modulationInputs
mod knob values are accessed via parameters->modKnobValue[] Core Specific:
calculates the pitch modulation value from GUI controls, input modulator kBipolarMod, and MIDI pitch bend
the pitch modulation is ultimately not used, but code is kept here if you want to add it
selects a PCM sample based on modulated frequency
calculates final gain and pan values

Parameters

processInfo the thunk-barrier compliant data structure for passing all needed parameters

Returns: true if successful, false otherwise

must persist between update and render

must persist from update to render

index of sample; does not change often

double SynthLab::SynthLabCore::hardSyncRatio = 1.0

protected

for hard sync

hard sync ratio with modulators applied

◆ hardSyncronizer

Synchronizer SynthLab::SynthLabCore::hardSyncronizer

protected

hard sync helper

hard synchronizer

◆ lastTriggerMod

double SynthLab::SynthLabCore::lastTriggerMod = 0.0

protected

for retriggering EG trigger detection

for detecting rising edge of modulator

◆ midiPitch

double SynthLab::SynthLabCore::midiPitch = 440.0

bool SynthLab::SynthLabCore::retriggered = false

protected

for retriggering EG

for retrigger modulation

◆ sampleRate

double SynthLab::SynthLabCore::sampleRate = 1.0

protected

sample rate

fs

◆ selectedSampleSource

IPCMSampleSource * SynthLab::SynthLabCore::selectedSampleSource = nullptr

protected

current PCM sample

selected PCM sample

PCM sourse database object.

◆ selectedTableSource

IWavetableSource * SynthLab::SynthLabCore::selectedTableSource = nullptr

protected

selected table

two tables to morph across

selected dynamic table

selected based on oscillator pitch

◆ sineTableSource

SineTableSource SynthLab::SynthLabCore::sineTableSource

protected

a single sinewave table

sine table for very high frequney notes that have only one harmonic (the fundamental)

◆ state

EGState SynthLab::SynthLabCore::state = EGState::kOff

protected

EG state variable.

FSM state variable.

state variable for FSM

The documentation for this class was generated from the following files:

C:/RackAFX Projects/SynthLab_SDK/source/core_templates/synthlabcore.h
C:/RackAFX Projects/SynthLab_SDK/source/core_templates/synthlabcore.cpp

Public Member Functions

Protected Types

Protected Member Functions

Protected Attributes

Detailed Description

Constructor & Destructor Documentation

◆ SynthLabCore() [1/19]

◆ SynthLabCore() [2/19]

◆ ~SynthLabCore() [1/18]

◆ SynthLabCore() [3/19]

◆ ~SynthLabCore() [2/18]

◆ SynthLabCore() [4/19]

◆ ~SynthLabCore() [3/18]

◆ SynthLabCore() [5/19]

◆ ~SynthLabCore() [4/18]

◆ SynthLabCore() [6/19]

◆ ~SynthLabCore() [5/18]

◆ SynthLabCore() [7/19]

◆ ~SynthLabCore() [6/18]

◆ SynthLabCore() [8/19]

◆ ~SynthLabCore() [7/18]

◆ SynthLabCore() [9/19]

◆ ~SynthLabCore() [8/18]

◆ SynthLabCore() [10/19]

◆ ~SynthLabCore() [9/18]

◆ SynthLabCore() [11/19]

◆ ~SynthLabCore() [10/18]

◆ SynthLabCore() [12/19]

◆ ~SynthLabCore() [11/18]

◆ SynthLabCore() [13/19]

◆ ~SynthLabCore() [12/18]

◆ SynthLabCore() [14/19]

◆ ~SynthLabCore() [13/18]

◆ SynthLabCore() [15/19]

◆ ~SynthLabCore() [14/18]

◆ SynthLabCore() [16/19]

◆ ~SynthLabCore() [15/18]

◆ SynthLabCore() [17/19]

◆ ~SynthLabCore() [16/18]

◆ SynthLabCore() [18/19]

◆ ~SynthLabCore() [17/18]

◆ SynthLabCore() [19/19]

◆ ~SynthLabCore() [18/18]

Member Function Documentation

◆ addMorphBankData()

◆ calcAttackCoeff()

◆ calcDecayCoeff()

◆ calcReleaseCoeff()

◆ checkAddSampleSet()

◆ checkAddWaveBank()

◆ checkAddWavetable() [1/2]

◆ checkAddWavetable() [2/2]

◆ createTables()

◆ doNoteOff()

◆ doNoteOn()

◆ flushDelays()

◆ getState() [1/3]

◆ getState() [2/3]

◆ getState() [3/3]

◆ render()

◆ renderHardSyncSample() [1/2]

◆ renderHardSyncSample() [2/2]

◆ renderSample() [1/5]

◆ renderSample() [2/5]

◆ renderSample() [3/5]

◆ renderSample() [4/5]

◆ renderSample() [5/5]

◆ renderSawtoothSample()

◆ renderSquareSample()

◆ reset() [1/19]

◆ reset() [2/19]

◆ reset() [3/19]

◆ reset() [4/19]

◆ reset() [5/19]

◆ reset() [6/19]

◆ reset() [7/19]

◆ reset() [8/19]

◆ reset() [9/19]

◆ reset() [10/19]

◆ reset() [11/19]