I have it! Since these are sampled, you'd have a
sort of pointilistic painting (or cube?)
that you could zoom around in, and whatever
is underneath is the current sample, so you'd have
infinitely many pieces and travel around in them.
All in real-time of-course, so you'd only actually
have to
I'm not sure I understand your question, but you want
to evaluate the offsets outside the do-loop (i.e. at
the time the instrument is called, not on every sample).
A "sufficiently intelligent" optimizer could recognize
that those entire expressions are not changing, and pull
them out of the loop
> "B" == Rujo2eW1CriLhL8O writes:
B> After the expansion, you have
B> (let ((FS 29761)) (round (* (/ *clm-srate* FS) smpl)))
B> at a dozen or more places.
So you're telling me i want read-time evaluation then, not read-time
expansion? Replacing an expression with its value
After the expansion, you have
(let ((FS 29761)) (round (* (/ *clm-srate* FS) smpl)))
at a dozen or more places. The optimizer can probably get rid of the
let,
but it is unhappy about *clm-srate*. It can't be certain it's
compatible
with round, or that it's constant during the loop (the
> "B" == bil:
B> I think the macro version is slower -- s7 does not currently
B> expand macros when first encountered; you can use
B> define-expansion for that, but the speedup is not great.
If (define-expansion expr) expands expr at read-time, why is it slower
(at run-time) than
