Getting an Audio Plugin Created ( was RE: [audio] Call for an updated enhanced quicktime audio library ora small audio complementary library!)

stephen barncard stephenREVOLUTION2 at
Tue May 18 12:44:56 EDT 2010

I think the below should be added to "Set1 -  BASIC AUDIO "trim" functions"

*f16  -  load, save and play audio from a variable*

Imagine an array with sounds!

Echo/Reverb, IMHO, is hard to do well and be efficient at the same time.
Most likely would be cheesy anyway, and this should be saved for plugins.

If one is talking about fading in fading out, crossfade, etc then we have to
have this one at the start

f17 - multiple asynchronous audio streams

"stream" meaning an individual thread of sound, not necessarily an internet

I thought I saw a mention of some audio functions being done in RevTalk.
 I'd say that wouldn't be possible - audio is real-time and binary.

One other mention - *Digital audio is dangerous when it runs wild.* The
worst case is a blast of digital noise at full scale, which is many db above
the usual operating level. Some users of DAW software have heard this
occasionally - I myself have experienced this when running Digital Performer
on a drive that ran out of space while recording -  It's the worst noise
I've ever heard, and the most painful and you NEVER want to experience it.
It can easily blow ears, headphones and speakers, mostly tweeters.

I would suggest to any of those out there considering writing code for audio
for the first time to make sure your monitoring system and your ears are
protected - get a cheap audio limiter to put across the audio output for
testing, so it absorbs the increase in level when things get out of hand -
and they always will if you are messing with the bits, just like code
crashes during development. Just expect it.

The people that commercial audio software like Digidesign have to be
continually on the lookout for Full Scale Output and take strenuous steps to
make sure it NEVER HAPPENS. Imagine doing an overdub with headphones on and
then this ear-splitting noise happens when they punch into record.  Ouch.

One more issue is sample rate.   We've reached an audio plateau at 24 bits/
96k sample rate.
This is 120 db of dynamic range, folks, with a sample rate that allows
easier filtering, and disk usage that is reasonable. 120 db, by the way, is
waaaaaay below the actual noise floor of the surrounding analog electronics!

 I know of very few people that record with bit width beyond 24, or samples
beyond 96k. This means one can record transients detectable up to 44khz !
Faster sample rates are more  demanding of processing resources without that
much sonic improvement. It's cool to say that your DAW can 'do' 192k, but at
the loss of how many tracks?

For that reason, limits should be set now to target the 24/96 ceiling and
not worry about performance at rates beyond that. Nobody uses it.


On 18 May 2010 02:54, Robert Mann <rman at> wrote:

> Thanks all for your contributions. I propose to set up somewhere a wiki
> page
> so that all interested parties can  append a specification document with
> suggestions, reactions and so on.. ??
> It sounds a good idea to set the boundaries between several "levels" of
> librairies and raw some specifications subsets consequently. In practice It
> can be a good way to start and see if things go well.
> Feedbacks :
> 1) Please do append at this stage with your ideas but do refer to fNumbers
> that should not change. If you add, add a fNumber. Yhanks.

More information about the Use-livecode mailing list