[chuck-users] LiSa SndBuf rate bug?

mike clemow gelfmuse at gmail.com
Sat Nov 15 13:53:15 EST 2008


I should have read the comment at the top anyway.

Thanks, Dan!

-Mike

On Sat, Nov 15, 2008 at 1:51 PM, mike clemow <gelfmuse at gmail.com> wrote:
> Okay, if I use a mono file, this works.  I guess there's something
> about the way we're populating the LiSa object with the stereo file
> that is only copying half the samples over somehow.  I'll keep at
> it...
>
> -Mike
>
> On Sat, Nov 15, 2008 at 1:44 PM, mike clemow <gelfmuse at gmail.com> wrote:
>> Yup!  That was definitely the problem with the speed.  Okay, cool, I'm
>> not crazy.  ;-)
>>
>> I still only get the first half of the SndBuf in the LiSa object,
>> however.  I'm trying to tease out why.
>>
>> -Mike
>>
>> On Sat, Nov 15, 2008 at 1:31 PM, Daniel Trueman <dtrueman at princeton.edu> wrote:
>>> so, something like this should work for stereo and greater files:
>>> //ugens
>>> SndBuf buf;
>>> LiSa lisa => dac;
>>> //change this path to your own sample
>>> "/Applications/Max5/examples/sounds/cello-f2.aif" => buf.read;
>>> //set lisa buffer size to sample size
>>> ( buf.samples() / buf.channels() )::samp => lisa.duration;
>>> //transfer values from SndBuf to LiSa
>>> for ( 0 => int i; i < buf.samples() / buf.channels(); i++ ) {
>>>
>>>
>>>
>>>     (buf.valueAt(i * buf.channels()), i::samp) => lisa.valueAt;
>>>
>>>
>>>
>>> }
>>> //party on...
>>> 1  => lisa.play;
>>> 2. => lisa.rate;
>>> //hang on until it's done...
>>> lisa.duration() * 0.5  => now;
>>> i've posted this on the LiSa examples wiki.
>>> dt
>>>
>>> On Nov 15, 2008, at 1:02 PM, mike clemow wrote:
>>>
>>> I just downloaded the newest miniAudicle (0.1.3.9) and experience the
>>> same behavior as before at 44100hz sampling rate.
>>> -Mike
>>> On Sat, Nov 15, 2008 at 12:52 PM, mike clemow <gelfmuse at gmail.com> wrote:
>>>
>>> I'm on Mac OS X 10.4.11 running at 44100.  However, it doesn't change
>>> if I change the sampling rate.  I'm using Chuck 1.2.1.2 on the command
>>> line.
>>> hrm...
>>> -Mike
>>> On Sat, Nov 15, 2008 at 12:41 PM, Daniel Trueman <dtrueman at princeton.edu>
>>> wrote:
>>>
>>> what platform are you on, and what sampling rate are you running at?
>>> dt
>>> On Nov 15, 2008, at 12:30 PM, Daniel Trueman wrote:
>>>
>>> hmmm... not sure what's going on. the example works as expected for me,
>>> and as you describe how it should work (plays the whole file through at
>>> twice speed), using the most recent release of miniaudicle and chuck. and
>>> the last line should be lisa.duration() * 0.5 => now, though that shouldn't
>>> affect what you hear.
>>> dt
>>> On Nov 15, 2008, at 12:16 PM, mike clemow wrote:
>>>
>>> Hi Dan,
>>> I guess what I'm trying to say is that, when I run this example, I
>>> only get the first half of the SndBuf into LiSa and it plays back at
>>> half-speed when the rate is set to 1.  It seems to me, that this isn't
>>> right.  Since, the example came with the rate set to 2 in order to
>>> play back at normal speed, I assumed that you guys knew about this.
>>> buf.samples() * 1::samp => lisa.duration;
>>> This should (however you choose to write it) create a buffer equal in
>>> size to the SndBuf.
>>> for ( 0 => int i; i < buf.samples(); i++ ) {
>>>        //args are sample value and sample index (dur must be integral in
>>> samples)
>>>        lisa.valueAt(buf.valueAt(i), i::samp);
>>> }
>>> Here, I understand we're copying all the samples from SndBuf into LiSa.
>>> 1  => lisa.play;
>>> 2. => lisa.rate;
>>> Playing back with a rate of 2 should make it play back twice as fast
>>> as normal, if I understand this correctly, however, it doesn't seem to
>>> do so.
>>> lisa.duration() => now;
>>> This should advance time long enough to hear the whole thing.  This is
>>> true, but only because we have only the first half of the SndBuf in
>>> LiSa, and we hear it twice.  This doesn't seem right to me, unless I'm
>>> missing something.
>>> -Mike
>>>
>>>
>>> On Fri, Nov 14, 2008 at 9:24 PM, dan trueman <dtrueman at princeton.edu>
>>> wrote:
>>>
>>> 'tis an example. change the line:
>>> 2. => lisa.rate;
>>> to whatever you want to get a different rate. just make sure you change:
>>> lisa.duration() * 0.5 => now;
>>> to an appropriate value as well, to make sure it plays long enough....
>>> dt
>>> On Nov 14, 2008, at 8:10 PM, mike clemow wrote:
>>>
>>> Hey folks,
>>> In the below example (which you will all find in the LiSa-SndBuf.ck
>>> file in examples in your installation), after populating the buffer in
>>> the LiSa object with the values of the samples from SndBuf, the rate
>>> of the LiSa object is set equal to 2. in order to play back normally.
>>> Why is it not 1?  Why this should be the case makes little sense to me
>>> and I respectfully submit this as a bug, unless someone can provide a
>>> reasonable explanation.
>>> Thoughts?
>>> -Mike
>>>
>>> -----
>>> //ugens
>>> SndBuf buf;
>>> LiSa lisa => dac;
>>> //change this path to your own sample
>>> "/Users/dan/Files/Chuck/LiSa_examples/TomVega.wav" => buf.read;
>>> //set lisa buffer size to sample size
>>> buf.samples() * 1::samp => lisa.duration;
>>> //transfer values from SndBuf to LiSa
>>> for ( 0 => int i; i < buf.samples(); i++ ) {
>>>       //args are sample value and sample index (dur must be integral in
>>> samples)
>>>       lisa.valueAt(buf.valueAt(i), i::samp);
>>> }
>>> //party on...
>>> 1  => lisa.play;
>>> 2. => lisa.rate;
>>> //look at some of the data
>>> //returns value at given time, with linear interpolation
>>> <<< Std.rand2f( 0., lisa.duration() / 1::samp ) :: samp  =>
>>> lisa.valueAt
>>>
>>> ;
>>>
>>> //hang on until it's done...
>>> lisa.duration() * 0.5 => now;
>>> --
>>> http://michaelclemow.com
>>> http://semiotech.org
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>>
>>>
>>> --
>>> http://michaelclemow.com
>>> http://semiotech.org
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>>
>>>
>>> --
>>> http://michaelclemow.com
>>> http://semiotech.org
>>>
>>>
>>>
>>> --
>>> http://michaelclemow.com
>>> http://semiotech.org
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>>
>>
>>
>>
>> --
>> http://michaelclemow.com
>> http://semiotech.org
>>
>
>
>
> --
> http://michaelclemow.com
> http://semiotech.org
>



-- 
http://michaelclemow.com
http://semiotech.org


More information about the chuck-users mailing list