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:

...

...

Rhodey r => LiSa l => dac; second => l.duration; 1 => l.record; 1 => r.noteOn; second => now; 0 => l.record; 0 => l.loop; second - 1::samp => l.playPos; -1 => l.rate; 1 => l.play; second => now;

...

...

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. duration read and voiceGain is just about done, and should make it in to the next version, at least! dan

...

...

I have a slight issue with LiSa when she's supposed to play backwards.> Let's assume for a second we want to record a single piano note, then play it back *once* in reverse; ---------------------- Rhodey r => LiSa l => dac;

second => l.duration;

1 => l.record; 1 => r.noteOn;

second => now;

0 => l.record;

0 => l.loop; second => l.playPos; -1 => l.rate; 1 => l.play;

second => now; ---------------

The above looks entirely correct to me, however, it won't generate a sound. for

.999::second => l.playPos;

it will work just fine and it will also work fine when .loop is turned on but turning loop on for one-shot samples isn't always convenient.

I believe this to be a bug, probably related to the way in which LiSa> determines when she is supposed to stop playing. When you, Dan, have a moment, could you please look into this?

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

jah, i understand your points. like i said, i'll take a look at the source and i may be able to fix some/all of these easily, but it could also get ugly and take a while.... thanks for the useful comments! dan On Aug 15, 2007, at 3:02 PM, Kassen wrote:

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

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

ok i spoke too soon. it looks like it was super easy to address both these concerns (duration => loopEnd causing a total stop, and playback depending on loop points when not in loop mode) and i've got fixes in the next version. hopefully i didn't break anything else! and also, hopefully nobody has grown dependent on the earlier non- functionality... best, dan On Aug 15, 2007, at 3:02 PM, Kassen wrote:

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

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

I've tried installing 1.2.0.8., however the chuck in my usr/bin is the old one. How do I replace it? I tried to build chuck from the source but the make command is not recognized. Help! -van