PlayObject-questions

[Stefan Westerfeld]

   Hi!

On Wed, Jul 24, 2002 at 02:00:33AM +0200, thomas.friedrichsmeier at ruhr-uni-bochum.de wrote:
> For a game I'm writing, I was in need of a 
> PlayObject that I can both loop and play 
> at different rates. [...] Ideally I would want to 
> be able to treat all common audio formats 
> the same - but don't feel like extending 
> every single type of PlayObject one by 
> one.

PlayObjects provide an interface to play back sound (or, nowerdays, videos),
and, to be able to interoperate with almost any existing library to do so,
they are only very loosely standarized. Thus, the implementations can differ
considerably (one PlayObject may decode data in a seperate thread, another
may do so in the main thread, on PlayObject might open an X11 window, another
might send events to a midi port).

So adding a "standarized" piece of loop code into this will not be possible.

However, it seems that for most audio formats, what you really want to have
is an abstraction to open it, and read it as floats. Upon this, generic code
can do the looping, seeking, caching and so on, without being file format
specific. In fact, this is the path followed by the new "DataHandle"
abstraction found in arts/flow/gsl. You have a loader which provides a
"DataHandle", which in turn can give you the data as floats.

Hans Meine has implemented an Arts::PlayObject on top of this, recently. This
is found as GSLPlayObject in the CVS. As the GSL-playback code (which is
intended for sample playback in the context of synthesis, really) can do
looping and resampling already, it should be straightforward to extend this
PlayObject to one which can loop and resample ogg, mp3 and wav files.

Another loader for the audiofile library could be inserted into GSL, then, so
that those wav files that contain encodings not supported by the GSLish loader
could still be loaded by the new PlayObject, so that no feature loss would
occur.

Note that GSL is "not-entierly-done-yet(tm)", but I think this is the "central
place" you are looking for to centralize decoding of all audio formats.

> I saw that there exists a 
> PitchablePlayObject, but I failed to find 
> out how to use it. How do you?

PitchablePlayObject is - as PlayObject - an interface. So the way to use it
is this:

 * obtain a PlayObject
 * cast it into a PitchablePlayObject

   Arts::PlayObject po = ...;
   Arts::PitchablePlayObject ppo = Arts::DynamicCast(po);

 * set the speed attribute to the relative playing speed

   if(!ppo.isNull()) /* cast succeeded */
     ppo.speed(2.0); /* play twice as fast */

If you want to _ensure_ you get a PlayObject which is pitchable upon creation,
you will need to do the TraderQuery for the object yourself. There you can
say: I would like to have a "PlayObject which can play mp3s and implements
the interface Arts::PitchablePlayObject".

> And would 
> it be possible to additionally have a 
> LoopablePlayObject? How?

Suggest an *interface* for it (that is, which additional functions/attributes
should a LoopablePlayObject have). Put that interface into the .idl file.

Implement the interface in those PlayObjects that do support looping. You
will have to do one-by-one, but given that the GSLPlayObject will support
{wav,mp3,ogg}, adding support to this single PlayObject might be sufficient.

> Let me add to this mail a few critical 
> comments on the documentations-pratice of 
> Arts, [...] And please do give documentation 
> a higher priority.

I see that documentation is a big weakness of aRts. I can only encourage you
to write as many mails as you need to write, either on the list or to me, until
you know the things you need to know. I know that the approach doesn't scale
very well, but well, if you want to, you might also work on the documentation
after you have understood something.

Longterm, there needs to be a better solution, but possibly this might be
solved alongside with other longterm plans for aRts (see strategy meeting
mail) ; but you are of course right. Writing a framework without a clear
concept of how it should be documented takes away quite some of the usefulness
of writing a framework in the first place.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan at space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-