Auditory signal dependent knowledge source superclass: AuditoryFrontEndDepKS
ΒΆ
Whenever a knowledge source needs signals, cues or features from the auditory
front-end, it should subclass from the AuditoryFrontEndDepKS
class. Any
knowledge source added to the blackboard through the BlackboardSystem
addKS
or createKS
methods, register these requests
automatically with the Auditory front-end.
- Setting up the requests
Inheriting knowledge sources need to put their requests in their call to the super-constructor:
obj@AuditoryFrontEndDepKS(requests)
, withrequests
being a cell array of structures each with fieldsname
, stating the requested signal name, andparams
, specifying the signal parameters. (Have a look at Available processors.)An example looks like this:
requests{1}.name = 'modulation'; requests{1}.params = genParStruct( ... 'nChannels', obj.amFreqChannels, ... 'am_type', 'filter', ... 'am_nFilters', obj.amChannels ... ); requests{2}.name = 'ratemap_magnitude'; requests{2}.params = genParStruct( ... 'nChannels', obj.freqChannels ... );
The
params
field always needs to be populated by a call to thegenParStruct
method.- Accessing signals
These requested signals can then be accessed by the knowledge source via the inherited
getAFEdata
method, which returns a map (with the indexes as in the request structure being the keys) of handles to the actual signals.An example, according to the requests example above, looks like this:
afeData = obj.getAFEdata(); modSobj = afeData(1); rmSobj = afeData(2); rmBlock = rmSobj.getSignalBlock(0.5,0);
A more elaborate description of the request parameter structure and the signal
objects can be found in the help for the Two!Ears Auditory Front-End. Have a look at the implementation of the GmmLocationKS
to see a real-world example of how to subclass AuditoryFrontEndDepKS
.