Open bartkrekelberg opened 3 years ago
@bartkrekelberg Yep, that's a fair point. I don't have any issue with that, though I also think leaving it as a plugin has advantages. e.g. logging of values, string functions etc. and might allow more flexibility for unforeseen future uses (perhaps derived classes that want to set up the sound in a particular way or do some processing beforeTrial etc.).
An alternative solution is for the sound
plugin to be added to cic by default in the cic constructor, unless explicitly told not too via an argument.
The sound plugin is really something that is rarely used on its own, but rather in support of other plugins. (Tell tale sign is that it doesn't have the usual beforeXX afterXX member functions).
So maybe it should be part of cic (calling it cic.sound would allow for backward compatibility) and
A future modification?