Buffer~ initialization causes DSP to stop
Dec 19 2011 | 7:43 pm
Hey,
I am wondering if it is possible to avoid DSP drop-outs when initializing a new buffer~, for a example in a dynamic poly~ patch? I need to dynamically create buffers but this issue ruins all the effort. Any ideas?
- Dec 19 2011 | 10:55 pmA quick search of the forum reveals this:Brendan
- Dec 19 2011 | 11:45 pmWell, I am using oo objects and all the poly~ goodness already however my question remains unanswered. I don't want the initilization of buffer~ to stop DSP, that's the problem.I might just create one poly~ to hold hundreds of buffers (so it would one-off event) to assign them to whatever I need later, hmmm...
- Dec 20 2011 | 1:37 amAre you using Max 6?How come creating buffer~s is interrupting audio? May we please see a patch?Cheers-A
- Dec 20 2011 | 2:47 amyes, I am using Max 6.My patch is a bit too big and dependent on parent patchers so I can't paste it here however I can only replicate DSP drop-out when deleting a buffer~ but not creating it, does it happen to you as well?What happens when you delete the buffer in the patch below?
- Dec 20 2011 | 9:43 amIf I try your patch in Max6, there is indeed a short dropout when I delete the buff buffer. In Max5, the dsp stops definitively after the following sequence: deleting the buffer, undo, deleting the buffer again.It may be related to this previous topic: https://cycling74.com/forums/the-dsp-stops-when-a-buffer-is-deletedIn Max6, this behavior seems to have been corrected.p
