[Fluxus] Fluxa notes

Kassen signal.automatique at gmail.com
Thu Feb 10 14:31:54 PST 2011


>
>
> Would you want onset detection, or just start playing at time X, stop
> playing at time Y?
>
>
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).

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.

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.

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.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pawfal.org/pipermail/fluxus-pawfal.org/attachments/20110210/c910ed3b/attachment.html>


More information about the Fluxus mailing list