[CM] sound-loop-info / mus_sound_loop_info

[Michael Klingbeil]

I would agree that reading every sample twice is not ideal. It is of 
course possible to avoid that by just reading the new samples and 
shifting the old ones over (or to completely avoid copying by using a 
circular buffer). The buffering code becomes more complicated.

I tried getting/setting mus-increment on a file->frame gen but it 
doesn't seem to support that.

CM> (setf x (make-file->frame "source:pno;18-pno01A0.aif"))
#<file->frame: fil: source:pno;18-pno01A0.aif>
CM> x
#<file->frame: fil: source:pno;18-pno01A0.aif>
CM> (mus-increment x)
No applicable method for args:
  (#<file->frame: fil: source:pno;18-pno01A0.aif>)
  to #<STANDARD-GENERIC-FUNCTION MUS-INCREMENT #x87FFF66>
    [Condition of type SIMPLE-ERROR]

Barring a reworking of the buffer mechanism that supports 
multi-direction reading, I guess it would be nice if file->frame, 
file->sample, etc. would support mus-increment.


At 6:48 AM -0700 5/25/07, Bill Schottstaedt wrote:
>  > newloc = (int)(samp - (gen->file_buffer_size * .5));
>
>Thanks for the interesting suggestion. The original plan was that
>readin would handle that kind of operation, setting the "dir" field --
>this is the same, I think, as using the mus-increment function
>with the file->frame generator, as you mention.  I'd rather not
>make the change you suggest because it means that every sample
>is read twice ("read" here can include data type conversions, etc).
>Does mus-increment fix the problem?
>
>>  Also, just curious why is the file descriptor opened/closed every
>>  time the buffer is refilled? Wouldn't this be a performance hit?
>
>I didn't see any difference in my timing tests, and the current way
>avoids any OS limits on open files, and is cleaner if something
>goes wrong -- if a computation is interrupted (say you hit a bug
>during instrument development), you don't have to worry about
>dangling files, and at least some portion of your output is probably
>saved.
>
>_______________________________________________
>Cmdist mailing list
>Cmdist@ccrma.stanford.edu
>http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist