-Designing new LooperClip class and buffer interaction
This commit is contained in:
parent
f13486e857
commit
d3cbd3c516
3 changed files with 34 additions and 2 deletions
|
@ -31,7 +31,7 @@ class AudioBuffer
|
|||
numBeats = b;
|
||||
}
|
||||
|
||||
std::vector<float>& get()
|
||||
std::vector<float>& getData()
|
||||
{
|
||||
return buffer;
|
||||
}
|
||||
|
|
|
@ -151,7 +151,7 @@ void Looper::updateControllers()
|
|||
|
||||
void Looper::setSample(int sc, AudioBuffer* ab)
|
||||
{
|
||||
vector<float>& buf = ab->get();
|
||||
vector<float>& buf = ab->getData();
|
||||
if ( buf.size() > SAMPLE_SIZE )
|
||||
{
|
||||
EventGuiPrint e( "Looper setSample() ERROR size > incoming sample" );
|
||||
|
|
|
@ -15,6 +15,38 @@ class AudioBuffer;
|
|||
|
||||
using namespace std;
|
||||
|
||||
/** LooperClip
|
||||
* Represents each clip that a looper can playback. The core of the audio
|
||||
* samples is stored in AudioBuffer objects which are dynamically resized. The
|
||||
* base size of a AudioBuffer is 1 second's worth, after which larger buffers
|
||||
* will be requested.
|
||||
* The transition between AudioBuffer instances is seamless: when the clip is
|
||||
* running out, the new one is requested. Upon its arrival the current data is
|
||||
* copied, and the old buffer is returned for deallocation.
|
||||
*
|
||||
* This system allows for arbitrary length recordings, without huge
|
||||
* pre-allocated buffers while it is still quite simple.
|
||||
*
|
||||
* Each clip has its properties like length and bars/beats, so the Looper knows
|
||||
* to dynamically stretch / process the audio appropriately.
|
||||
**/
|
||||
class LooperClip
|
||||
{
|
||||
public:
|
||||
LooperClip()
|
||||
{
|
||||
buffer = 0;
|
||||
}
|
||||
|
||||
void setRequestedBuffer( AudioBuffer* ab )
|
||||
{
|
||||
|
||||
}
|
||||
|
||||
private:
|
||||
AudioBuffer* buffer;
|
||||
};
|
||||
|
||||
class Looper : public Observer, public AudioProcessor
|
||||
{
|
||||
public:
|
||||
|
|
Loading…
Reference in a new issue