Forums > MaxMSP

polybuffer~ making glitch sound before playing buffer.

December 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.

– Pasted Max Patch, click to expand. –

December 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~

– Pasted Max Patch, click to expand. –

December 17, 2012 | 1:56 pm

Thanks Chris,

I’ll get my head around this now.


December 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.

Thanks


December 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.


December 17, 2012 | 7:56 pm

cheers Chris


December 17, 2012 | 9:26 pm

Hi again Chris,

Just pondering, what’s the point of the ‘dummy buffer’?


December 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.


Viewing 8 posts - 1 through 8 (of 8 total)