Difference between revisions of "Mmc-august-2012/Lab2"

From CCRMA Wiki
Jump to: navigation, search
(Multi Sample)
(Bonus Round (optional))
 
(One intermediate revision by the same user not shown)
Line 15: Line 15:
 
What sort of user interface will support these manipulations? Consider whether that UI is '''discrete''' (has a small number of specific states, e.g. a button) or '''continuous''' (conceptually has an "infinite" number of states, e.g. a slider), and whether each individual sample has its own effects control or if a single control is shared between some or all samples.  
 
What sort of user interface will support these manipulations? Consider whether that UI is '''discrete''' (has a small number of specific states, e.g. a button) or '''continuous''' (conceptually has an "infinite" number of states, e.g. a slider), and whether each individual sample has its own effects control or if a single control is shared between some or all samples.  
  
Playback rate is probably the "most expressive" effect that is easy to implement here, but some other options include using STK's PitShift (pitch shift without time stretch), NRev/PRCRev/JCRev (reverb), or Chorus. You could also implement your own effects -- distortion or comb filters would be cool -- ask Spencer if you are interested in these.  
+
Playback rate is probably the "most expressive" effect that is easy to implement here, but some other options include using STK's PitShift (pitch shift without time stretch), NRev/PRCRev/JCRev (reverb), or Chorus. You could also implement your own effects -- echo feedback, distortion, and/or comb filters would be cool -- ask Spencer if you are interested in these.  
  
In terms of code structure, changing the playback rate is pretty simple, provided you already have a C++ class encapsulating the notion of a Sample. If you add  
+
In terms of code structure, changing the playback rate is pretty simple, provided you already have a C++ class encapsulating the notion of a Sample. If you add
  
 
== Bonus Round (optional) ==
 
== Bonus Round (optional) ==
 
* Instead of playing back the samples when triggered by the user, construct a '''sequencer'''. The most common (and boring) type of sequencer is the '''step sequencer''', but other alternative sequencer types exist, or perhaps have yet to be invented(!).
 
* Instead of playing back the samples when triggered by the user, construct a '''sequencer'''. The most common (and boring) type of sequencer is the '''step sequencer''', but other alternative sequencer types exist, or perhaps have yet to be invented(!).
 +
* Implement some more of the FX listed above.

Latest revision as of 00:04, 14 August 2012

Lab 2 - Sampler

In this lab we will create a live audio sampler. This sampler should be able to record short snippets of audio input into a WAV file, and then play these files back when triggered by the user.

MonoSample

Using the techniques learned in class today, build an app that can record a short snippet of audio input from the device's microphone and replay this snippet. Start by creating a new "single-view application" and add MoAudio, AudioToolbox.framework, and CoreAudio.framework as before. You will also want to use the FileWvIn and FileWvOut classes in STK. To incorporate these into your project, simple drag the entire STK folder from audioStuff into your project, and include FileWvIn.h and FileWvOut.h in whichever files use those classes.

Come up with a UI and audio code to record a sample, play it back some number of times, and re-record the sample as desired. Try to structure your code modularly -- for example, create a C++ class for the Sample that handles all of the logic of initializing, recording, and playing the sample. You'll be glad you did this in the next part of the lab.

MultiSample

Extend MonoSample to record more than one sample -- anywhere between 4 and 9 samples is good, depending on how you much you can fit into the UI without clutter (the screen size of your device in will come into play here). In terms of code, you should basically be able to make a few instances of your Sample class, and then have some simple logic to route UI input to the right instance.

FX

Add a way to manipulate the samples when they are played back. One super easy/super cheap way to do this is to change the playback rate of the file -- the same as playing a record faster or slower. FileWvIn has a method called setRate() which changes the playback rate.

What sort of user interface will support these manipulations? Consider whether that UI is discrete (has a small number of specific states, e.g. a button) or continuous (conceptually has an "infinite" number of states, e.g. a slider), and whether each individual sample has its own effects control or if a single control is shared between some or all samples.

Playback rate is probably the "most expressive" effect that is easy to implement here, but some other options include using STK's PitShift (pitch shift without time stretch), NRev/PRCRev/JCRev (reverb), or Chorus. You could also implement your own effects -- echo feedback, distortion, and/or comb filters would be cool -- ask Spencer if you are interested in these.

In terms of code structure, changing the playback rate is pretty simple, provided you already have a C++ class encapsulating the notion of a Sample. If you add

Bonus Round (optional)

  • Instead of playing back the samples when triggered by the user, construct a sequencer. The most common (and boring) type of sequencer is the step sequencer, but other alternative sequencer types exist, or perhaps have yet to be invented(!).
  • Implement some more of the FX listed above.