On 8/15/07, dan trueman
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! Yours, Kas.