<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="h5"><br>
</div></div>Would you want onset detection, or just start playing at time X, stop<br>
playing at time Y?<br><br></blockquote><div><br></div><div>I'd say start& stop. Probably as fractions of the file's length. This may need a way of polling files for length, but that's not the hard bit. That's useful on it's own, already, and not the hard bit (the numbers are there already, after all, just not as variables).</div>
<div><br></div><div>Transient detection is then probably the next step (if we take Nick's lead, which I found to be a good idea in ChucK) but unless live audio input is anticipated I'd say it would be far more efficient to perform transient analysis on files once and not as a node. That should save significant amounts of CPU, over time. Such a feature could return a list of transients that the start&stop feature could then take as a input. That's straightforward as a strategy and should be modular enough to allow for a lot of creativity.</div>
<div><br></div><div>I've been thinking about how much sense live input would make in Fluxa. I think it'd be fun, but it doesn't seem to fit especially well with how (seq ) works. I'm not a 100% sure here. There are more options in the larger scale because transient detection of incoming audio could also be highly relevant as a input to visualisations, in addition to the (gh ) bands. From transient detection we could go on to attempting to divine the BPM of the material. That's also interesting and somewhat related.</div>
<div><br></div><div>Thanks for looking into this. I'm open to there being way better ideas too, this is just what I came up with. D&B with acid sounds is fun, chopping stuff up then recursing is fun (especially in Scheme), I think it makes sense, but there might be better ways of looking at this.</div>
<div><br></div><div>Yours,</div><div>Kas.</div></div>