Hi Andy,
Your script looks good. A simple example with some of the advanced features.
On Wed, Mar 5, 2008 at 11:22 PM, Andy <[EMAIL PROTECTED]> wrote:
> What I'd like is:
> day track
> randomly decide if i should play a jingle or not
> day track
> randomly decide if i should play a jingle or not
> etc
Currently you have an average of 1 jingle for 1 song. I think what you
ask now is that there are never two jingles in a row. There are a
couple of ways to achieve that.
One of the earliest tricks was the delay() operator: instead of
putting jingles in your random() node, use delay(1.,jingles). With the
delay() around it, it will act as jingles, except that the
availability of a second jingle will be masked until 1 sec after the
broadcasting of the first. In effect, you'll get a day track after any
jingle. You can put an higher delay: with 10 seconds for example,
you'll have the guarantee that if after a jingle a day tracks lasts
only 5 seconds, there will be no jingle after it, and hence another
day track.
Another possibility is to use the "single" parameter. I was surprised
to see that it is only available in switch(). I'll have to think why I
only implemented it there and not in the base class of both switch(),
fallback() and random(). Anyway, there is a solution with switch():
switch(single=[true,false], # the first child can't emit twice in a row
[ (random.bool, jingle), # 50% chance to choose jingles, when
repetition is allowed, i.e. after day tracks
({true},day) ]) # it's always possible to choose a day track
The second solution is a bit more complex. But it also has a slightly
different behaviour, really based on track repetitions whatever the
durations, while the first one is more about durations. Sometimes it
matters: if not, choose the simplest.
> ## normalise and compress the audio
> radio = nrj(radio)
By the way, we recently realized (on the Dolebraï radio) that
normalize() -- used inside nrj() -- can saturate. Actually we should
have opened a ticket about that in order to stress Sam and Vincent,
who wrote the operator. Instead I started using replay-gain:
precompute the ideal gain per track (using mp3gain and vorbisgain) and
use it. It gives a very nice listening experience, and avoids the
problems of dynamic normalization -- not only saturation, but also
some inherents to dynamicity. The recipe is not so simple as it
involves a couple elements, and I plan to document it eventually. If
you're interested, encourage me and it'll come sooner :p
Have fun.
--
David