Apr 20, 2006 at 2:24am
right, can anyone tell me categorically if a buffer can be written on, then re-written over with a longer file? cuz i am at my wits end trying to create a system whereby the user can record as long as they like, then loop instantly the results
Apr 20, 2006 at 10:54am
You can set the buffer size with a message. If you don’t specify a size as
Apr 20, 2006 at 11:36am
isn’t it easier that u just set a large buffer to record into?
it’s like LISA by http://www.Steim.org concept, if I am not totally wrong…
large buffer…playback zones..
Apr 20, 2006 at 7:51pm
When you resize the buffer object, it erases the content. If you don’t resize it, it only records for the length it was set up to record. If you want to record something with an unlimited size (well; until your hard drive spills over…) you have to record it to disk. (Of course, if we are lucky, someone has written a nice external which does this. There are, however, certain basic IT restrictions which make this difficult.) Writing to RAM (whether it is a buffer object or stutter or whatever) is the only way to have it available with the minimal amount of latency.
Do you really want to loop material which is more than, say, 20 seconds long? Think about it; most of Chopin’s etudes don’t last more than about two minutes. If you do (more in the direction of concepts, extremely slow music or installations) then is it important that the loop starts directly after the recording? To tell the truth, I never used a buffer which is more than three minutes long. I just assume that it would work.
So; the basic facts:
–looping with predefined buffer objects means you have to tell the groove object (or whatever) where to loop (measure it with a timer or cputime while recording)
–looping with sfrecord has inherent latencies.
–looping with tapin and tapout is the easiest (particularly now that I know about the freeze command) but precludes any pitchbend possibilities or the possibility to dynamically change the length of the loop.
–looping with stutter gives good results, but you also have to measure what you are recording and feed it to the object when you end the loop. This means that the lengths of loops which are meant to be synchronized need to be factors of the original length, and that the phasor controlling the playback must either be the same or synchronized.
All of this is gradually leading up to a sort of general looping patch with all of the possible desires covered, but, as with all of us, the object is the music and not the programming. I build patches as I need them, not for their own sake.
Apr 20, 2006 at 8:27pm
just a thought: what I am getting at is that, no, there is no way to dynamically resize a buffer and write to it at the same time. The workaround is simple; just use a buffer which is larger than what you might possibly want to record, and resize the loop length rather than the buffer. That’s why I keep harping on the stutter object; it is easy to use and takes away some of the work you would otherwise have to do.
On the musical side of things: one basic question which comes up from time to time is “How long can a loop be before the audience can’t make out that it is a loop?” (Here in southern Spain, the answer is not representative; the Murcian audience has little patience.) In my own, very personal opinion, a sixteen-second loop is already bordering on the extreme. The loop then becomes a sort of ostinado which has more theoretical value than acoustic. I like to use a great number and variety of loops in some of my pieces, but I prefer to think of them as samples; recordings which I can trigger at any other time in the piece without latency, but not that I need them to continually loop. (Looping is, for, me a cheap and easy way to make an audience realize that I am reusing live material as opposed to using playback. Otherwise, the structures which are possible with dynamic sampling are much more interesting.)
You must be logged in to reply to this topic.