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
[email protected]
http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
_______________________________________________
Cmdist mailing list
[email protected]
http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist
