(set abuffer, 0) --- [groove~ ]

    Jan 21 2011 | 3:24 am
    if i send groove~ a message that says:
    (set abuffer, 0)
    What is that 0 for? I am encountering it in an old patch and looking at the reference is not really helping me. I though it might be a way to set the instep (set the playback position to 0) but if i load a long soundfile and change that 0 to say, 5 it doesn't start reading from 5 seconds in.
    I don't have, or see any other examples of this kind of compound message either in the docs or anywhere else on my hard drive.
    Seems silly to start a whole new thread about this but i seriously at a loss. It isn't loop or loopinterp since they would have keywords before them, it isn't 1 as in "do it" sine goove is controlled by a sig and well, 0 would make no sense.
    This is killing me… what in god's name is this 0? Why is it there, what does it do, why do i need it, why is this not in the help?
    [corn~ ] --> [fused~ ]
    I know I am gonna be horribly embarrassed by this but if i don't find out it will drive me up a wall.

    • Jan 21 2011 | 7:35 am
      a comma in a message box will separate messages. The 0 is an integer. What an integer, sent to groove~, does, is explained in the reference (converted to float) and what a float does is explained in the help file and in the reference... You tried the correct thing with putting in a different number, but I doubt that you can hear the difference of 5 ms... Almost all timings in MSP are defined as ms...
    • Jan 21 2011 | 10:56 am
      As stefantiedje says, it is there in the helpfile, though your comma in the message confused you. Here's a quick patch describing what the integer to [groove~] left inlet is doing:
    • Jan 21 2011 | 9:25 pm
      it's in the help file it's in the help file it's in the help file it's in the help file it's in the help file it's in the help file it's in the help file it's in the help file
      Okay yeah, but clearly my problem is that I didn't understand the help file correctly. Not that i am unaware of its existence.
      These 2 seemingly incongruous facts are what threw me off:
      integers are converted to floats timings in are defined as ms
      If you are measuring small rocks in centimeters you want to use floating point numbers to get meaningful precision. If you are measuring things in millimeters you might be okay with integers, unless you work for NASA.
      The idea that groove converts integers to floats *and* still is in ms is unintuitive to me. So as stefantiedje pointed out my attempts to grok the behavior by changing the integers fed to groove led only to further confusion.
      Whatever. I am dumb. I usually use play~ & sfplay~ so groove is odd to me.
      Thanks for taking the time to reply. It confirms that we are all insane (or that my intuition is as reliable as mail service in Italy).
    • Jan 21 2011 | 9:36 pm
      This also incidentally explains why playing reverse doesn't always work in my patch... likely i need to bang info~ and get the end time and use a [t i -1 ] and send that to groove to make sure it starts playing from the end of the file... or some such. Sending 0 and -1 would yield a playback length of 0.
      will try.
    • Jan 21 2011 | 10:33 pm
      yes, [groove~] is, at times, if not odd, then certainly a little un-intuitive in this respect; there was a recent thread here that went into more detail about [groove~]'s play-speed/direction.
      Forgive me for just 'scanning' your original post, rather than digging for the deeper meaning, anyway....
    • Jan 21 2011 | 11:17 pm
      no not all. i meant my response to be self mocking & light hearted. I am always grateful when people take the time to respond.
      ps. to play backwards you send sig a negative #.... I am trying to make a reverse flag which would just take my speed and just make it - So far my strategy is to always make a negative number and then use [abs 0.] to flip it positive. There must be some better way to do flip a number negative no?
      thanks again.
    • Jan 21 2011 | 11:49 pm
      This seems to work. With some minor concerns that in rare cases we could get numbers out of the range 0-1 w/ random 100000 * 0.00001. Also i suppose 0 is a possibility.... I suppose I should tweak this so that >. 1 doesn't come about though this is all really jus to test the main envent which is:
      abs 0. * -1. to flip a number 0. to 1. neg.
      I went to public school.