buffer~ problems

    May 20 2006 | 12:28 pm
    Hi folks,
    I'm struggling to do 2 seemingly simple things with a buffer:
    1. resize the buffer after recording into it, without deleting the recording like the 'size' message,
    2. write the file to a specific location automatically after the resize.
    These operations should be completely automatic, as its for an installation that I wont be at all the time.
    Thanks for any advise!

    • May 20 2006 | 12:53 pm
      > 1. resize the buffer after recording into it, without deleting the recording like the 'size' message,
      Why do you want to resize the buffer~ after recording ?????
      Anyway, save the buffer~ as sounfile, resize buffer~, reload, rewrite...
      Or use buf.Op to copy the content of your buffer~ into a temp one.
    • May 20 2006 | 12:58 pm
      I tried to do the same thing a while back; it doesn't work. Resizing the buffer seems to re-alot the necessary memory, erradicating the memory it had (and your recording). What you need is enough memory beforehand. If you know that you will be recording, say, maximum 12 seconds of sound, just set the buffer to be more than that and resize by controlling the playback parameters instead of changing the buffer. For my own purposes, I went to over to using stutter for alot of "precording" work.
    • May 20 2006 | 1:44 pm
      On 20 May 2006, at 13:28, Sam Barker wrote:
      > 2. write the file to a specific location automatically after the > resize.
      If you use Thomas Grill's xrecord ( http://grrrr.org.ext ), there's an outlet that gives a bang when record is finished. You can use this to bang the write message to buffer. If you have to use record~, you'll have to use the sync output and detect record end from that. For instance (there are probably better ways...)
    • May 20 2006 | 3:53 pm
      Thanks for that...
      I should to explain a little better. To summarise as briefly as possible, I have a microphone and a push button (acting as a toggle for a gate~) in a corridor, inviting members of the public to make a sound ito it. This sound is then manipulated and redistributed around 6 speakers in the ceiling along its length.
      It occured to me that this this would make a great library of sounds, so what i want is an automated process to store what is input through the mic.
      I wanted to resize the buffer because the participants will record sounds of varying lengths, up to ten seconds.
      I think I've solved the issue of resizing.. or rather sidestepped it be recording the samples sequentially onto a larger buffer of say 10 minutes, rather than each sample being saved individually.
      What I'm still stuck with is writing each buffer~ to a specific folder when it is full, and with a different filename to the last so as not to overwrite...
      Thanks again for the help!
    • May 20 2006 | 4:13 pm
    • May 20 2006 | 4:16 pm
      When writing the file the default folder include the date/time in the file name. this will guarantee a unique file name file saved, as long as you don't set your clock back...
      It will also allow for easy organization of your files (they will be alpha-numerically sequential as they were saved),so you don't necessarily need to have a lot of separate folders.
    • May 20 2006 | 6:39 pm
      Have a look at the Quickrecord patch in the Extras folder, specifically, the sub patcher 'quickie', Cheers Roger
    • May 20 2006 | 8:53 pm
      problem solved.
      sprintf and waveform~ did the job nicely.
    • May 20 2006 | 9:16 pm
      you might be able to find something useful in this patch (though you'd have to apply an appropriate bang on end of record to do the actual save). This is a patch I put together for assembling several sounds into a large buffer, then copying only as much of the buffer as is recorded over to another buffer to trim the file, and then saving the new sound file. There may be a few 3rd party objects you need to find...