[chuck-users] Lisa behaving strangely?
signal.automatique at gmail.com
Wed Aug 15 15:02:01 EDT 2007
On 8/15/07, dan trueman <dtrueman at princeton.edu> wrote:
> hi, i just noticed this part of your email. i actually don't regard this
> as a bug, though i may be able to be convinced otherwise. a very slight
> modification to your code works fine:
Yes, I noticed that it does work with a slight modification, I am using
exactly this right now.
Either way; you made LiSa so if you say this is not a bug then clearly it
isn't. I can just say why I was so surpised by it; I was manipulating some
sequenced beats and needed a versatile sampler to remix and restructure
those while improvising. I'm using a set of LiSa's and those are repeating
quanitised fragments, reversing single hits and so on in various forms. For
reversals I went about in the most straightforward way (as I saw it);
setting the start point to the end of the buffer (which itself was
quantised, back then, for saftety I now increased the maximum size and made
the loop-point exlplicid) and setting the rate to -1. Perhaps all of this is
naive but to me, unaware of the whole reasoning behind and internal
structure of LiSa these seemed like reasonable asumptions. Then nothing
happened and I had to eliminate possible causes.
I'm entirely open to the perspective that this is not a bug but in that case
I would say that it's still behaviour that seems counter-intuitive to me and
that -so far- I can't see the purpose of this behaviour. If this is how LiSa
should act then based on my surprise at this I'd say it would be good to put
a note about this in a future entry in the manual section on LiSa.
As I wrote before; I'm also a surprised at LiSa not playing back any sound
when the start point of a reversed (and perhaps a forward as well?) playing
voice is also the loop-end point while looping is switched off. This forces
the programer to take the loop-point into account and place the loop-end
point out of harm's way before starting non-looped playback. In a situation
where quantised time periods are used it's not unlikely that start-points
and loop-points will tend to end up in identical positions in consecutive
forms of playback.
This too can be easily worked around but this too is surprising to me which
is why I reported them.
i can understand that this might seem awkward, and i'll look at the source
> code to see if there might be a good way to change this that isn't too
> painful. in any case, you should be able to get consistent behavior with
> this work around.
Yes, thanks, it works fine.
duration read and voiceGain is just about done, and should make it in to the
> next version, at least!
Many thanks for your time and efford!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users