polybuffer~ making glitch sound before playing buffer.

    Dec 15 2012 | 4:25 pm
    Hi all,
    I've recently made this 10 track player and it works fine yet I get a horrid glitch sound before it starts to play the chosen buffer or it takes a good 10 seconds to start!
    I've tried to find the solution but it's escaping me!
    Any help greatly appreciated.

    • Dec 15 2012 | 8:22 pm
      There were a couple problems. You had joined all the groove~ sync outs, but because they're signals, they added so the result was between 9.0 and 10.0 instead of the 0.0 to 1.0 you were expecting. Secondly, because of the way that the end was being detected using delta~, it was re-triggering madly. I swapped delta~ for change~. I also changed the groove~s to point to a dummy buffer and only get pointed to their real buffer after polybuffer~ creates them.
      All this said, the way I would approach this patch is to use poly~
    • Dec 17 2012 | 1:56 pm
      Thanks Chris,
      I'll get my head around this now.
    • Dec 17 2012 | 2:35 pm
      HI Chris,
      Just trying to work out how the 'sel' into 'change' works!
      If the the 'sel' argument matches the input then a bang is sent from the left inlet which then changes to a 0, this 0 tells the groove to start at 0.
      If the 'sel' argument doesn't match, a bang is sent from the right inlet and then converts to a 1. How does 'change' work here?
      The help file says it outputs a number if it is different to the stored number! Is the stored number the 1 from the message box above?
      So it only outputs the 1 if the signal doesn't match the 'sel' argument?
      This 1 then does what to the groove~ sng?
      Sorry for the questions I just really want to understand and abosrb all this new vocabulary.
    • Dec 17 2012 | 7:14 pm
      [sel] doesn't send a bang out it's right outlet. It sends the things that were'n selected for. The [sel 1] instance would send the ints 2..9 out the right outlet.
      I put the change there so that any given groove~ would only be "stopped" once, and not be re-stopped when each other groove~ was started. Thinking about that now, I see that that is misguided, as I would really want to set to the highest number in ms of the loaded sample, so that's a bug.
    • Dec 17 2012 | 7:56 pm
      cheers Chris
    • Dec 17 2012 | 9:26 pm
      Hi again Chris,
      Just pondering, what's the point of the 'dummy buffer'?
    • Dec 17 2012 | 11:44 pm
      The buffers that polybuffer~ creates don't exist when the groove~ objects are created, so they throw errors into the Max window at patch load time.