[Stk] basic questions about play.cpp

Helena Troy helenatroy1@hotmail.com
Mon, 30 Jan 2006 19:46:15 +0000


thanks so much for your comprehensive answers and for the reference to 
"Thinking in C++" online.   They are a very big help.

helena

----Original Message Follows----
From: Richard Dobson <richarddobson@blueyonder.co.uk>
To: stk@ccrma.Stanford.EDU
Subject: Re: [Stk] basic questions about play.cpp
Date: Mon, 30 Jan 2006 18:57:21 +0000

Helena Troy wrote:

>Hello,
>
>I have still a few question about play.cpp.   (Did I pick a hard example to 
>start with?  Does anyone have a reccomendation of a good example to start 
>with?)
>

It' not ane specially hard example as examples go, but like most STK 
programs it does involve the selected audio API according to platform, and 
of course fluency with C++; do you have any comprehensive texts covering 
that (e.g. Soustrup, Deitel & Deitel)? If not, you could try "Thinking in 
C++", a free downloadable book:

http://mindview.net/Books/TICPP/ThinkingInCPP2e.html

  Some inline replies:


>1) - Is the second parameterof tick() (int buffersize) included in tick() 
>to conform with the typedef for "RtAudioCallback"?

yes. In this respect there is not any serious difference between C++ and C, 
except that C++ typically is more strict.

>
>2) - How is the first parameter (char buffer) initialized?  (I guess it 
>must come from the FileWaveIn object passed thru the dataPointer 
>parameterer,  but I really can't tell how this initialization happens)
>

In this example the buffer size is decided largely by the audio subsystem 
(See e.g. RTaudio.cpp; but STK can request a size). This in turn depends on 
what API is being used (DIrectSouhnd or ASIO on WIndows, OSS or Alsa on 
Linux, CoreAudio on OS X); in most cases the buffer is supplied  by the host 
audio subsytem, and not expressly allocated by STK at all; STK meremly asks 
the host how bug the buffer is.

For example, in the DirectSound version, the buffer is declared as :

	LPDIRECTSOUNDBUFFER buffer;

And this is eventually initialised with a call to DirectSound:

	// Obtain the primary buffer
     result = object->CreateSoundBuffer(&bufferDescription, &buffer, NULL);


In play.cpp, the relevant code is:

int bufferSize = RT_BUFFER_SIZE;
   try {
     dac = new RtAudio(0, channels, 0, 0, format, (int)Stk::sampleRate(), 
&bufferSize, 4);
   }

You could to use the debugger to step into all the dac->calls (including the 
constructor) to find out just where the buffer comes from.


>3) - The global StkFrames frames varible is declared at the beginning of 
>the code, but (why) doesn't it have to be instantiated somewhere in the 
>program with a call to 'new'?
>

This is a basic C++ question. "frames" is declared as a global variable  (in 
effect, on the stack - it is a full-blown object, not a pointer), and this 
uses the default constructor (the first one shown in the class definition in 
Stk.h) to initialse it to all zeros.

Later in play.cpp, it is initialised with a call to resize():

	// Resize the StkFrames object appropriately.
   	frames.resize( bufferSize, channels );

C++ new is used to allocate an object dynamically (on the heap). It is a 
fundamental matter to understand the difference. Funnily enough, C++ 
programmers go to some lengths to avoid direct calls to new in 
application-level code; they prefer to have as much allocation as possible 
handled inside objects (as demonstrated by STkFrames); which means 
everything can be declared as a local or global variable. It is impossible 
to explain this here - it is a fundamental principle of OOP, and books have 
been written about it!

>4) - Is function  of tick() to move a pointer along the audio file passed 
>to 'play' so that the system knows where to start when it needs to read the 
>next chunk of data from the file?   If you pass a very small file to play,  
>I guess tick might never be called?
>

You have pretty much got this. The pointer starts out at the beginning of 
the audio data (in effect position 0); so  tick() will always be called at 
least once. Study the RtWvIn class, together with FileRead.cpp; you will see 
that deep down it uses the standard stdio fopen/fread etc calls to read the 
file, parse the header, and find "position 0" of the audio data itself.



Richard Dobson





_______________________________________________
Stk mailing list
Stk@ccrma.stanford.edu
http://ccrma-mail.stanford.edu/mailman/listinfo/stk