<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.100" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2><FONT face="Times New Roman" size=3> Yes
you're right, using two arrays, writing and reading each
one<BR> alternatively could be a solution i hadn't thought about. But
that would<BR> mean that the samples i read from the (reading-)array would
always be 'one<BR> array' later than real time(a delay corresponding to the
size of the<BR> writing-array). Of course smaller arrays could be used
(which i would<BR>prefer not to as i want to be able to access for example,
fragments within the<BR>last 5 seconds), or as you suggested more smaller
arrays.<BR><BR> I was rather thinking if it could be possible to make
delread~ (or some<BR> other object or simple patch) behave like the
circular queue as described<BR>in Curtis Roads (The computer music
tutorial,p 433), with the posibility of<BR> several taps (reading-pointers)
which reading position i could control with<BR>(one-)sample precision. This
structure would allow to access samples from<BR>real time (in fact one sample
later than real time) to the time<BR>corresponding to the total length of
the queue.<BR><BR>> ----- Original Message -----<BR>> From: "Miller
Puckette" <</FONT><A href="mailto:mpuckett@man104-1.ucsd.edu"><FONT
face="Times New Roman" size=3>mpuckett@man104-1.ucsd.edu</FONT></A><FONT
face="Times New Roman" size=3>><BR>> To: "Gregorio Garc?a" <</FONT><A
href="mailto:ggkarman@airtel.net"><FONT face="Times New Roman"
size=3>ggkarman@airtel.net</FONT></A><FONT face="Times New Roman"
size=3>><BR>> Cc: "pd-list" <</FONT><A
href="mailto:pd-list@iem.kug.ac.at"><FONT face="Times New Roman"
size=3>pd-list@iem.kug.ac.at</FONT></A><FONT face="Times New Roman"
size=3>><BR>> Sent: Monday, August 27, 2001 7:54 PM<BR>> Subject: Re:
[pd] delread~<BR>><BR>><BR>> > Hi,<BR>> > I don't think you
need do do anything funny with block~. The easiest<BR>way<BR>> > to
proceed might be to maintain a pair of samples and alternately sample<BR>>
> each one while reading from the other. Alternatively, you can
maintain<BR>a<BR>> > larger collection of samples from more or less recent
input.<BR>> ><BR>> > Yes, you do have to specify the size of the
sample in advance, but that<BR>> doesn't<BR>> > mean you have to use
all of it. There are sampler patches in the<BR>> > "dsp examples"
(under "pure documentation") which might help you<BR>forward.<BR>>
><BR>> > cheers<BR>> > Miller<BR>> ><BR>> > On Sun,
Aug 26, 2001 at 04:55:49PM +0200, Gregorio Garc?a wrote:<BR>> > > Hi
list,<BR>> > ><BR>> > > Im trying to buid a patch that
processes live input. My wish is i<BR>could<BR>> have<BR>> > > some
kind of buffer where i could continuously write the input signal<BR>> >
> (something like a circular qeue?), and arbitrarily read fragments
of<BR>> sound<BR>> > > within that buffer. I thought of delwrite~/
delread~ pairs to<BR>implement<BR>> > > this, but i would like to be
able to specify the position and total<BR>> length<BR>> > > of the
audio fragments i want to read in samples (does this make<BR>> sense?).
Is<BR>> > > the delay amount limited to block size (64 samples? = DSP
cycle?)<BR>> multiples<BR>> > > (64samples, 128 samples, 194
samples, etc...)?<BR>> > ><BR>> > > Could i use
tabsend~/tabreceive~ for this purpose?. What is the usual<BR>> way of<BR>>
> > using tabsend~/tabreceive~ ? (could you point out an example?).
What<BR>> input<BR>> > > paramerters can tabreceive~ handle?<BR>>
> ><BR>> > > Is there a better way for doing this?<BR>>
> ><BR>> > > thnks<BR>> > ><BR>>
><BR>><BR>></FONT><BR><BR></FONT></DIV></BODY></HTML>