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 stream. 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. sqb On 18 May 2010 02:54, Robert Mann <r...@free.fr> 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. > > _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution