[PD] MP3Play-- arguments...

[nullpointer]

Hi All,

The MP3Play object from IEMLIB
Has anyone used it to control mp3 playback at different rates
(can you speed up/slowdown) or by directly controlling the readpoint (and
reading chunks granular style)?

Thanks
T.

http://www.nullpointer.co.uk
http://www.dividebyzero.org
http://www.orphanrecords.co.uk
________________________________________________________
C:\AUTOEXEC.BAT
C:\REM [Header]
C:\>
C:\>PATH=C:\PERL\BIN;C:\WINDOWS\COMMAND;\C:jdk1.2.2\bin
________________________________________________________

(all suffixes enabled)

-----Original Message-----
From: Krzysztof Czaja <czaja at chopin.edu.pl>
To: pd-list <pd-list at iem.kug.ac.at>
Date: 01 October 2001 16:07
Subject: [PD] poly-musings again (and dispatching anything)


>hi,
>
>after rereading my discussion with pix, I think there are few
>points I must clear up.
>
>1. My `notsocute' example, patched up in haste, was meant to
>illustrate my general doubts, and not to be used as a nqpoly~
>replacement.  On the other hand, any Pd-instrument designer
>would welcome a simple access to poly~'s functionality.
>
>2. I was wrong, arguing that an addition of a request to return
>a single voice to the free voices pool of PureData's poly would
>cause an incompatibility with max.  Even if we seriously cared
>for such compatibility, `clear' message to poly is PureData's
>extra addition to max-poly, which has only `stop' message.
>
>But anyway I was right about simplicity of such addition.  The
>proof is in x_midi.c.diff attachment, which adds a float argument
>to `clear' message.  If this argument's value $n$ is in the range
>[1..<number-of-voices>] then voice$_n$ is returned to the pool.
>In this version an argumentless `clear' works as it used to.
>
>The question remains, if this simple addition does not introduce
>unnecessary ambiguity to the meaning of poly.  Currently stopping
>a voice means stopping the oldest voice playing a note of
>a specified pitch, if there is any such voice.  Stopping a voice
>number n is something conceptually different.  Maybe it is better
>to add a separate object class `pool'?  OK, there could be an
>extern...
>
>#if 0 // this is hackery
>3. ... or, if none of the above is available, the remaining
>technique would be to cheat existing poly, forcing it to store
>noteons with pitch always equal to voice number -- as I did in
>notsocute.pd, and which is a very inefficient way of doing
>something pretty simple.  This trickery is factored out into the
>attached abstraction `pooly.pd'.  The interface of poly remains
>in pooly (with quite the same functionality), and there are two
>extensions for handling the voice pool: a `bang' message to choose
>a voice (in stealing mode or not), and a `clear <n>' message to
>return voice n to the pool.  But beware, this abstraction plays
>nasty tricks...
>#endif
>
>4. Of course the `pitch' input to poly may have any meaning, not
>necessarily directly interpreted as a single parameter of a note,
>but instead, for example, mapped to a parameter vector, or to any
>other mechanism of generating parameter values.  A user of poly
>should think rather of playing/stopping a note of some arbitrarily
>choosen cathegory, which can be pitch or anything else.
>
>5. One thing that is really troublesome in designing poly~-alike
>abstraction is a dispatching scheme, since there is no `forward'
>object class in Pd.  We need to feed the choosen voice with
>parameters.  This voice's number is a variable.  Since, of course,
>it is impossible to [route] into as many destinations as we wish,
>the only way is to use global send/receive.  But if we wanted to
>choose send's destination dynamically, we are stuck with a message
>box, and the number of parameters must be kept constant -- we
>cannot dispatch anything.  If, on the other hand, we need variable
>number of parameters, then they will have to be sent to all voices,
>preceded by another message opening a spigot in the voice being
>current destination (one can make variations of this theme, like
>passing a message through a chain of destinations, until it is
>spigoted into the proper one).  This is clumsy, unreliable and
>highly inefficient.
>
>Whoever knows of any other way (using max/forward excluded),
>please give me a clue.
>
>Krzysztof