sampler structure/efficiency question
I’m building/rebuidling kind of a sampler. i need about 8 buffers, but only one [play], [xplay].. so it won’t be polyphonic.
My question now is, is it more efficient to have the playing object insie a poly and mute all instances but one at a time or to just send a set buffer1, set buffer2 etc message to the playing object?
I tend to believe the second solution is better, what do you think?
Thanks a lot!
oh and another question. I am using polybuffer~ the first time. I can’t seem to find a message like (replace the file in buffer 3 with … .aif), but only append or read folder messages. Isn’t there anything like that? That would be a real pity.
You can use the send message:
send 3 replace … .aif
Ah! Thanks a lot!
With poly~ you can make a nice crossfade. Otherwise I don’t really see why you’d need 8 buffers. Because if you don’t care about interrupting the dsp chain then you might aswell just use one buffer and change the sample with the replace message.
I don’t think i interrupt the dsp chain when i change the buffer a groov object should read from, do i? seems to work really fast.
i’m planning to change the referenced buffer at quite high rates and i’m quite sure reading a new file in is the slowest option, isn’t it?
I mean my whole question is about efficience in the sense that i want it to react at hight rates and be as less CPU consuming as possible.
I’d recommend polybuffer~. It’s fast, since you’ll have already loaded the files, and you’re just changing the memory pointer for the current buffer. It uses more memory, but that’s not a big deal at all. It also means that if you do want something to overlap, you’re not going to create a click or gap as you change sound files.
I’d say this quote from Donald Knuth is really good to bear in mind regarding optimization:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
(and I’d highly recommend the Wikipedia page on program optimization as a primer)
As long as you’re not at the wall, you’re going to be a lot happier with a solution that works well musically than one that runs 5% faster. Easy to control code makes for better music, and saves you time now in terms of complexity, as well as in the future, in terms of maintenance and flexibility.
I’d also highly recommend using poly~. I think a lot of people avoid it unnecessarily because it adds a slight amount of complexity, but the rewards are substantial in that it actually gets rid of some of the complexity that people create trying to avoid using poly~. (voice-handling/allocation, overlapping, etc.) Once you learn the adsr~ + thispoly~ combo, you’re pretty much set. You can also very easily adapt your abstractions to use poly~.
The only way to know for sure if process A is more efficient than process B is to profile your code. Poly~ is a nice way of doing this since you can load up n copies of whatever with ease. I don’t see anything in what you’re describing that suggests a huge bottleneck with using poly~, so I’d say don’t worry too much about any costs from using poly~ here.
In general, I think that most signal processing patches should be implemented as a poly~ for all but the most trivial cases or unless there’s a highly compelling need otherwise. Here’s what you get:
- Overlapping and polyphony. It’s very rare that things don’t overlap, and when you need it, it’s already there.
- Not having to write your own extra handling code which will be buggy. (try it; it’s a PITA)
- Down-sampling/up-sampling/different vector sizes
- Almost as efficient for almost everything.
- Way more flexible, since you can also dynamically swap out poly~ patches.
- Parallel processing algorithms such as vocoders, spectral delay, etc. become trivial to implement and substantially more flexible. "16-band vocoder? Oh, you wanted 8 bands? Okay, let me change the argument to poly~…"
I’m a little bit zealous about the use of poly~, but it’s always served me well. It also helps to promote good software development practices like decoupling controls from DSP which makes things easier down the road and that is a good thing IMHO.
Ah, I understand. You’re right, changing the reference for the play object is way faster.
But you’ll still want to use poly~, at least two instances of them. Because when changing the reference you’ll get some discontinuity. With just two poly~ instances you’ll be able to make a crossfade. But it might of course be that you don’t care about little clicks.
Fisrt off, thanks a lot, i really appreciate you took the time t think about this!
About optimization, these are interesting thoughts, but i really want to do some optimization, this actually is a patcher that is.. hm i guess more than 4 years old and that i am continuously working on. now i am thinking about finally changing the structure of it since i need some CPU overhead for other features i want to implement.
Yes, i also tend to using poly, and it actually was my first thought too.
Anyways, maybe i even follow Peters suggestion and put the whole thiong inside a poly but still do the "sample change" vie reference to another buffer inside polybuffer~.
So the question that finally stays is, does it have a reason i am kind of skeptical about changing the buffer of a groove~play~ whatever object at very high rates?
(i will deal with clicking with windowing)
8 buffers and one play~ would be my choice, too.
of course changing the buffer to read from does not happen sample exact this way, but otherwise it is the best of all thinkable solutions.
".. is the best of all thinkable solutions."
sorry to be kinky about this, but since you say it that way..
What about having 8 [play~] instances inside poly~, use 8 buffers~(rather one polybuffer~ actually) and muting the voices not needed. one could stay sample accurate if one could unmute in advance. Maybe leading two having always two voices active. which would still be a vast improvement compared to the patcher as it is right now. And if i wanted to have crossfading at some point, it could be implemented easily. I really don’t care about crossfading in this situation, but this seems like a very common thing and having a good recipe for it is useful for many people i hope.
it would be worth a test, but i believe that putting 1-2 simple audio externals into a poly~
will double the CPU that takes when all of them are on.
okay, in your situation you might run only a max of two instances, but the poly~ itself
might still be an issue. plus it is making the patching lots more complicated.
8 play inside poly? i am not sure why. one (or two for the crossfade option) should be
and multiple buffer objects … do not really eat up cycles when nothing reads from them.
i cannot really comment on polybuffer, i have never used it and i dont think i would when
the aim is to just load multiple files.
I guess it really depends on a number of things:
What is the process triggering this? (i.e. what is the sample accurate process (oscillator/sah/?) that is playing the soundfiles/loops, or do you just want it to pretty accurate and not click?) Groove~ doesn’t trigger sample accurately, so I’m guessing it might be the latter; this is good because it’s easier.
If sample accuracy is absolutely important:
1. Are you always playing from the same predefined locations in the soundfiles? If yes, then use sfplay~/sflist~ with the preload message. You can trigger cues sample accurately. IIRC you can have around 255 cues or so. (though maybe more)
If no, then you could copy your files into one buffer. It would be really awesome if there were a convenient way of doing this, but you’d probably have to roll your own for the time being.
2. As for as optimizations go, it’s kind of hard to say without seeing your code (post it?) but, generally speaking, the core sound making parts are not always great candidates for optimization. For example, in a synth you don’t want to skimp on processing power for your oscillators or your filter(s). If anything, you’re much better off looking at doing things like downsampling adsr~ and LFOs (wrap them inside a poly~ patch!). That saves a ton of CPU, since for both of those things you can usually downsample by a factor of at least 16.
Poly~ really doesn’t introduce a ton of overhead. I write synths that are pretty heavy (6-7% CPU per vox), but when there are no voices playing, the CPU usage is very, very low. One thing that may be skewing the CPU usage that you’re seeing is that all voices are on by default in poly~. You can loadmess "mute 1" into all of your thispoly~ objects to get a more accurate sense of runtime overhead vs peak overhead. For whatever reason, adsr~ is inconsistent in that at load time it is at 0 but there’s no mute message from its 3rd outlet (whereas for the remainder of its life, this is NOT the case). I consider this a bug myself…
It’s good for things to be more efficient, but–as someone who as gone down that rabbit hole–you want to make sure you’re spending your time efficiently.
@roman, puh some misunderstanding..
I made a typo, i meant 1 play inside poly not 8, which is really a stupid point for a typo in this thread :),
what i meant are 8 poly instances, each with one play oject, of course. And, maybe having always 2 instances unmuted.
The whole playing engine doesn’t only consist of a play object and i did some tests, poly does cost something, but it isn’t a lot.
200 times in a patcher without any poly stuff i had ~36% average audio cpu
200 instances of the little patcher loaded inside of one poly i had 37 %
200 polys with one instance loaded i had 43%
patches are attached, a bit confusing naming though.. sorry
----------begin_max5_patcher---------- 7473.3oc2ctsaabkrF9Z6mBABruYiLAqpVG5UuuadNFDXPKQKyrooDDocblf IO6aJdPlJlJ6xSLl9C+23DwSp5h8++Zop65q9sW+pYu8tOuXyrq9et5eb0qd 0u85W8p8OziOvqN9yuZ1Gl+4qWMey9W1rqu6CeXw5sy9gCO21Eed69GO2t5+ 5zC9t6Vucyx+4hGeBy+wzwGd8G+vx0qVrc+Gjc7AWdy929cu8m+a0ZZ1Wdo2 8wsmdsoy9bWO+C6+bm82eX47Umd82Oe60ue45aeyCKtd6gCG2669MekmRO9e F8C+vOlt5md7s7ud8qe7e9gfG0qW7K6hvu5f99uki3zENhK0uiGwmNF2e.aV 9KGwm+dV7vwiyiGn69krb0hOs3gMKua8Yey7pYyu+9yd3Wc1a4wryOe29On1 O7zCsb8gGJ8zC8vhOs7z6ud3A2kye8om7Tf+2rQeeP66OBN8SV5wT4one2WQ 2t5tq+eWby4+Nlc28KVub88OrXytyJmu83urmd5aV7t4eb012b4ufd9y+t4W u3EeyW7agWM61GVdycqeLHd167wG9zut+wUkGOZJmenr+4WO+9K7V2r6n3ia d67GdL081U6+H7SO416ta0yepm91Z2IvyWu7Cy2tX6xCg5tyDN8jK+v8Orb8 1m8KZw5469Ld+lqe3tUqd1G0gm4SW3YtY2WnWu3WVdy12u+y57D4tW9x6O8E vrmxP2r71Ea197Ga67a277G4Y9Pmel14Jym83+YJzmqR+u+8qpm+Duv4Bekf 0O6INSz1m872vYxV6rm4vCu8Wu+3IAy1r7106Ny4oSB9S02ujF25V8f7tuWi j8erdtu1qN4scTq88Oad+6mu4tG1kRSeGyoVhQRst2.Zvd9hE+GHotZ9u96W s8Qgx+FIU6ERpkWNo5ARp+vUyd670298J45V6w+ay+Ocx86r92ZS54pCdVPC furSnINqJkCPszPXAbJ6phEPsLLoms1xljd.cFYUw7.FQ3AbJ6JiGPcZ2yZM OpnGP0XjU0xCn5H7.Nkc0wCHOomsVJCR5ATXjUEyCnhvC3T1UGOfosd.4ZUR OfAFYUw7.5H7.Nkc0wCXbROa0aRVSvVhQVUKOflgvC3T1UFOflOomsZCRVSv VlQVULO.FWZvSYWc7.l1qhUZPxZB1ZLxph4ALfvC3T1UGOfI8pXM1krjfsQD IUsb.FRDb.Nkbkw.XXRuDV8QIqG3fiHoJlAPlfAvojqNF.S50upmjrXfCUDI UwL.Pb+AdJ4piAvjdwqFLIqD3PGQRULC.D2bfmRtxX.zmzqbUyjrLfcCQRUK CfNh6LvSIWcL.lzKaU0krHf8BhjpXF.Hts.Okb0w.XRulUkrjEArOfHoJlA. h6IvSIWcL.lzqXUtHYQ.GSHRpZY.Lh3FB7TxUFCfwI8JV4UIKB3XFQRULC.D 2MfmRt5X.Ls2LfUIKB3XCQRULC.F2JfUwJB33jdEqZRVCvwQB4Toj+sDh6Cv lVU.rzqHXZWp0ER+Wl15p9krZIIjCPoOfBUf6Ruh3AzQP0N07.FYjU0xCXLg hUfx3ALZHnZmXd.Sa0U+RVULOfLJVApiGPAAU6TyCnxHqJlGPCEq.0wCX.AU 6TyCnyHqJlGvHJVAphGPMkPP0Ns7.pIiQVUJOfZxQwJPc7.xHnZmZd.EFYUw 7.pnXEnNd.MDTsSMOfAFYUw7.5nXEnNd.iHnZmXd.S7jD7orpVd.lghUfx3A XNAr1olEPFQRULGfBIVApiAPk.V6Ty.ngHoJlAv.IVApiAPm.V6Ty.XDQRUK C.OQhUfxX.3FAr1IlAf6HRphY.jIwJPcL.JDvZmZF.UDIUwL.ZjXEnNF.CDv ZmZF.cDIUwL.FIwJPYL.xIBXsSLCfrgHopkAP1IwJPcL.xDvZmZF.EDIUwL. pjXEnNF.MBXsSMCfADIUwL.5jXEnNF.iDvZmXF.kDhjpVF.EiDq.kw.n3.3Z mZ5+LgbpXx+BHVAJCa.bDrBbroDpPKNBTANlUhUnEGEo.GGEAVnNBPAplA.B NAJlAPFEl.kw.HifRfhY.jQ.IP0L.PwHPcL.PfHP0L.PPHP0L.PAHPcL.PvG P0L.PfGP0L.PQGPYL.JHfCnXF.EDrATLCfBJz.piA.Bx.plA.Bv.plA.Jt.p iA.Br.plA.Bp.plA.Jn.piA.Bl.JlAPEAR.Ey.nhhHfxX.TI.DP0z+D3AnZx eR3.TG0OAZ.pl5m.L.US8ShEf5n9IfBP0T+DHAnXp+FIP.Ji5uQfCfho9aDv .nZpeRT.TG0OAH.pl5m.C.US8SBAf5n9IP.P0T+D..nZpeR7+SF0+.A7+Il5 ef.8+DS8OPB9e5n9Iv9O0T+DP+mZpeRj+SG0OAv+ol5m.2+TS8SB6e5n9IP8 OwT+cBP+SL0emDy+jQ82Af7O0D+.H9mZZeP.+SEoetgf2e8pKj3O2Pv6utWD R9man38Wu2Ew..Au+Ty..Au+Dy.X.Eu+jw.X.Au+Dy.X.Au+Ty..Eu+zw..A u+Ty..Au+Ty..Eu+zw..Au+Ty..Au+Ty..Eu+jw.nif2ehY.zQv6OwL.5n38 mNF.H38mZF.H38mZF.n38mNF.H38mZF.H38mZF.n38mNF.H38mXF.iH38mXF .in38mLF.iD38mZ5eB79SM4OId+oi5m.u+TS8Sf2epo9Iw6OcT+D38mZpeB7 9SK0eIQh2epn9KIB79SK0eIQf2epo9Iw6OcT+D38mZpeB79SM0OId+oi5m.u +TS8Sf2epo9Iw6OYT+FAd+Il52Hv6OwT+FId+oi5m.u+TS8Sf2epo9Iw6OcT +D38mZpeB79SM0OId+oi5m.u+DS86D38mXpemDu+jQ86.38mZhe.79SMsOHd +Iys5SBAu+FJEktWeRH382f0T5V8Kgh2eC8jHF.H38mZF.H38mXF.FJd+IiA fgf2ehY.XH38mZF.n38mNF.H38mZF.H38mZF.n38mNF.H38mZF.H38mZF.n3 8mLF.NBd+IlAfif2ehY.3n38mNF.H38mZF.H38mZF.n38mNF.H38mZF.H38m ZF.n38mNF.H38mXF.YD79SLCfLJd+IiAPl.u+TS+Sf2epI+Iw6OcT+D38mZp eB79SM0OId+oi5m.u+TS8Sf2eho9Kj38mLp+BAd+Il5uPf2epo9Iw6OcT+D3 8mZpeB79SM0OId+oi5m.u+TS8Sf2epo9Iw6OYT+UB79SL0ek.u+DS8WIw6Oc T+D38mZpeB79SM0OId+oi5m.u+TS8Sf2epo9Iw6OcT+D38mXp+FAd+Il5uQh 2exn9a.38mZhe.79SMsOHd+ohz2I.ltVtojzGQJM0UB0mjH8WavkP5WIfjNs j9MDoToj9CjX7mJR+QBvnSKo+zNrjdJmJk1mwf84obqHheuhfueZI+8JB99o k92qn36mNF.H36mZF.H36mZF.n36mLF.MD78SLCfFB99IlAPCEe+zw..Ae+T y..Ae+Ty..Ee+zw..Ae+Ty..Ae+Ty..Ee+zw..Ae+Dy.X.Ae+Dy.X.Ee+jw. Xf.e+TS+SfuepI+Iw2OcT+D36mZpeB78SM0OI99oi5m.e+TS8Sfueho96j36 mLp+NA99Il5uSfuepo9Iw2OcT+D36mZpeB78SM0OI99oi5m.e+TS8Sfuepo9 Iw2OYT+iD36mXp+QB78SL0+HI99oi5m.e+TS8Sfuepo9Iw2OcT+D36mZpeB7 8SM0OI99oi5m.e+DiyOIB78SK0eNQhuepn9yI.78SMwO.99ol1GDe+TQ5aS6 ef5IloUckf6oMVIjTKiJg2SarQhxe0VRDCfABPoSMCfNgjpZF.ijX8mJF.9D +modjdZZY.3IiPRUKC.O4j38mNF.YBnoSMC.DPTTMCfJId+oiAPi.Z5Ty..A DEUy.nSh2e5X.LR.MchY.XHfnnXF.lQh2exX.XNAzzolA.BHJplAPgDu+zw. nR.McpY.f.hhpY.LPh2e5X.zIflN0L.P.QQwL.7DId+IiAfa.XSmX5em.CEU S9mAw6OcT+E.roSM0OAFJpl5uAh2e5n9G.vlN0T+DXnnZp+QP79SF0eNAfMc ho9yDXnnXp+rCh2e5n9y.XSmZpeBLTTM0eEDu+zQ82.vlN0T+DXnnZp+NHd+ oi5eD.a5DS8WHvPQwT+ECDu+jQ8Wb.roSM0OAFJpl5u.h2e5n9q.XSmZpeBL TTM0+.Hd+oi5uCfMcpo9IvPQwT+0DHd+Ii5uZSOb5DS7WAfPQ0z9YN79SFbe kmXd+k1eJZIkTB2W4JgjZ9.SJUA2WYH7963YrGvSq.F.SLu+rhhF.cBIU0L. fv6uimwphAPYh48m6BZ.TLBIUwL.JP382wyXkw.Xp48WRQCfBgjpZF.T38WR KCfIl2e4thF.CDRppY..g2eGOiUFCfIl2eEEKBXMQHoJlAPEBu+JZUDv5Dy6 uphEArlIjTUy..Bu+pZUDv5Dy6ulhEAr1HjTUy..Bu+ZZUDv5Ty6OEKBXcjP RULCfFEd+oUQ.aSKu+FTrFfMGPNUM4OCd+MnUE.aSKu+5JV.vVEPNUM0OCd+ 00p7esI8ZUMLpX0+Zc.4T0T+HtC.Oc9pJp+gok2eIEK82fAHmJl5efAu+RZU 3ugIl2eJV2ugBfbpZpeH79Sqp9MLs79yTrpeCC.xopo9Yv6OSqp9MLs79yUr pe8DfbpXp+NCd+4ZU0u9zx6urhU8qmAjSUS8yf2eYsp5WeZ48WQwp90a.xop o9Yv6uhVU8qOw79Swp90GAjSES8OBg2eZU0uwI8pSUUrnei9zmRUS6i3N8qJ UI+l1qLkMLtOa5stPZ+gJhbZIIj3efAr+NlayohFp+Il0eGPmnXp+NhbpVpe Hj96HGUEQ82mXP+cfahZo96FhbpTp+NDL+cDhppn9mXJ+c.Zhho9KHxoZo9g v3uiDTUE0+Ti3ujfp+AD4TsT+T.7WRJ0+Dy2urfU8aLgHmJk5eDBc+xRU0uw IFteEAq52XFQNUK0ODz9UjppeiSLY+pBV0uwFhbpVpeHb8qJUU+FmXr90Drp eiiHxoRo9sDDp90jpreVZho5mfk8yRNgbpXxeHT8Kok5eZo52PWQ0ekPNUL0 OCp9Mz0R8OsT8q2TT82IjSES8yfpecoJ6mYS50mpMJXY+LyHjS0R8aHta+Nl a0Q8OsT8K4Jp9KDxoho9YP0ujVU8ylXp9oXU+rAB4TwT+Pn5mVU8ylVp9YJV 0OOQHmpk52YP0OSqp94SKU+bEq5mmIjSES8yfpetVU8ymVp9kUrpediPNUL0 OCp9k0ppe9zd29UTrpe9HgbpVp+Lia1uhVU8KOsT8Swh9kc.oTwz9Ln5mTk7 aZm1bmnj1tsenDWubD4zjTb8JShpeVSC0eCAA5zR82FQjS0R8mHQ0OYT+UBD nSL0eCQNUJ0eafDU+jQ86DHPmXpeDjRTL0egDU+TQ8WGIPfNwT+ID4TsT+FI p9Ii5uQf.cZo9qCHxoRo9qcRT8SF0OBBzIl5ufHmpk5uRhpexn9SDHPmXpeC QNUK0uShpepn9KCDHPmVp+BBRIpk5uLRBpexn9K.3OmXh+JgTpVZ+FHh9Iiz 2..eNwj9NgTpVR+LHb9ohzOSf7bZI8yiDRoZI8SfX4mLR+J.ryIlzuQHkJkz OO.BjexH8c.LmSLoOAzHJlzu.hhepH8m1FO+HTzDS5mHjR0R5afP3mLR+F.Z yokz2GHjRkR56cP76SFoOATyIlzuPHkpkzuBBdexH8S.3LmXReiPJUKouChb epH8mV3xeDDZZI8MBrPTKouMBBaexH8AfXNwT9.3fnXBeNH6Klr+oeSyVsb8 hMG9.9i458+Nd74ubFeyce7gqOcjbZtueU5YGD2rKOub87sKua84uv9W8Be+ xatYw9Wy449aVtY9aWsXehNE57iu4XtGLl2O.1oDzsnI5JmXtFMlG3Dy4nwr yIl8nwbgSLmBFy8QNwbTeCNRvdX+YiSLOD8TiFmXNp8bmy5f8RzXNyIliZO2 AoAsnwLmsazCaOyYYvvaqiypfCQi4AN6PZHp87.mUtGhtSzAPmaD0ddfyxfC Q2I5.msaLD0ddfyxfsnaqqwY6FsvdcbVFrEcacMNa2nE0qqwYMkVzs003rci VTutFm0TZQ2VWkyZ2QkfbTf0vUEsBprn0v0EsAptn0vEFsNR5LjZ3nd.TTmC G0Nnn1CG0EPQcXqZPUHsFdeob1+esG2slTTOD97iFnnNraMnBkVCWozJnRkV CWqzJnhkVCWszJnxkV6wcqAsxX3xOVAU+wZ3BPVAUAxZ3RPVAUCxZ3hPVAUE xZ3xPVAUGxZ3BQVAUIxZXwHnyOBW9zJn5mVawcqAsxX3RnVAUC0Z3hnVAUE0 Z3xnVAUG0Z3BoVAUI0Z7RoBpVp03+4Wbh4Zb2ZPqlGegQRqLF+DDTmgDdWpU P6bpF1stBZkwZ3coVAsKjZb2ZPqLVBuiuBncgTB67U.sxXI5N9LP10kvVHER mVGdCeEPa3qD1BIS5z5vAMmXNGdCeEPa3KG11KCxAIGdCeYPa3KG+zZRmWG1 sNCZCe4va3KCZCe43t0fVYL9eQ.mX1CuIUGzlT8vt0NnUy8vkkzAsyIOrasC ZkQO7tTcP6BwC6V6fVYzBuiOCztPr3NefVYzBuiOP8w5khkWJpAsJiEdAcCz tPrvNefZktpEdGeIPqnG1tFjCRJtaMnUFSg2wWBztPRgcqSfVYLEdGeIP6BI E1sNAZkwTbKDRdHwcqAsxX3fFTLGsqKwDwkvMhTYjTTODNpGAE00vQcATTWB G0MPQsGNpMPQsENp4rVdIbS8T.0nIWJVdobcBTT2Bmqqfh5vNecPqxDtodJf ZzjKEKuTTCZUlvM0SATilD9dFBzsLzkxeuz4GfVYLbiHU.0bLWJVdonFzJig aDoBnli4RwxKE0fVYLbiHU.0nIWJVdonFzJiw+iF4DygaDoBnli4RwxKE0jx 0g2kJnli4RwxKE0fVYLbiHU.0nIWJVdonFzJigapmBnFM4RwxKkqAsxX3l5o .59J6RwxKE0fVkI7svWAz0H3RwxKE0fVkI7kioPZ2SgOsFTltD2sFzJiw2bc AztPJgcqKfVYrDdGeEP6BIb+SUJfVYrDdGeEP6BoD2sFzJiw+CY3Dy4v6RMC ZmSg6epBn9qqjCubdFz54g6epRlz40g2kZFztPB2+TEP8pVwCuiOGztP73Ne fVYzCuiOGztPB2KREP88UwCuiOGztPB2KREP88UwCuiOCzJ5gS0fViwh6VSJ pCuiOPL2nDt+oJf5UshEdGeFncgDt+oJf5UshEdGeFncgXwcqAsxX7MWyIlS g2kZBzNmB2+TEP8WWIEdWpIP6bJb+SU.0qZkT3sNk.sKjv8OUATupkCOhgxf FwP43c1CndUKGdDCkAMhgxg6rmLntnJGdDCkAMhgxg6rmLntnJGdDCkAMhgB CGNP7JK2i6Vafh5gvo5FnnNracmzYHkvQMncgDtajxf57qb3QLTFzHFJ2i6V CZkw3a3iSLGdrHkAMVjxg6FoLntUKGdrHkAMVjxg6FoLnN+JGdrHkAMVjxg6 FoLnN+JGdDCkAMhgxs3Nef7qCOhgxfFwP4vc1SFTWTkCOhgxfFwP4vc1SFTW TkCOhgxfFwPgAJNHFWmqwcqAsxX3QLTFzHFJWieBBnUFCOHExfljB4vciTtR RMFdGefnhYtF2sFzJiw+yu3DygQbRtPJpC6VCpa0xgaWsLn9UKGtsMxf5aib 3a8vLn68vb3aAmLn6Amb7KiDoqiTNtyGnUFi+mDP5uIH9RijVaL7LFJCZt2j C2YOYPcQUN7LFJCZFxD+DDPme3wcqAsxX3YLTFzbuIGtajxf57qb3YLTFzbu I6wEifVYL7LFJCZt2j83t0jb9BugONwb34hTFzr5IGtajxf5Vsb34hT1HcFR X2ZPc9UN7bQJCZt2jC2MRYPc9UN7LFJCZt2jSwc9.sxX3YLTFzbuIGtydxf5 hpb3YLTFzbuIGtydxf5hpb3YLjCZhrjiGzbh4ngLlH1i2+Tf5UMO7LFxAM2a 7v8OkCpW07vyXHGzbuwC2+TNndUyCOigbPy8FeLtUMImuvaQkSLGdtH4flUO d39mxA0ecd34hjCZV83g6eJGTup4gmKRdmjZLraMndUyCOigbPy8FeHtyGnU FCOigbPy8FObuH4f56KO7LFxAM2a7v8hjCpuu7vyXHGzLjI7kgFzUg1awcqA sxXKdplTtNraMndUyCOigbPy8FOb+S4f5UMO7LFxAM2a7Vb2ZPqLFVLBRKFd tH4flUOd39mxA0ecd34hjCZV83g6eJGTup4gmKRNn4diGt+obP8plGdFC4fl 6MdItyGnUFCOigbPy8FObuH4f56KO7LFxAM2a7v8hjCpuu7vyXHGzLjI7stL n6bYOG2sFzJigmwPNn4diGt+obP8plmieZMoyqC6VCpW07vyXHGzbuwieqNA pWjB2xFf5XCO7bQxAMqd73EtFz8BmGdtH4flUOd7MgP5pDDdtH4fl6Md39mx IsiuvyXHGzbuws3NefVYL7LFxAM2a7v8hjCpuu7vyXHGzbuwC2KRNn99xCOi gbPyPl310fbPRwcqAsxX3YLjCZt23g6eJGTup4gmwPNn4diGt+obP8plmhag PxCItaMnUFCGzfh4nPxGSDagmjSFnoKjEt+oLPcDnEdRNYijNCoDNpafhZOb TafhZKbTyYsbK7TQx.ModrdbmuDnntENWWAE0gc9.02WV3ohjAZR8Xg6EICT eeYgmJRFnodS3hRBpNY1Pb2ZPqLFdpHYflTOV39mx.0qZV3ohjAZR8Xg6eJC TupYgmJRFnI0iMD2sFzJiw+iF4DygmjSFnoKjEt+orFobc3coBZ5BYg6eJCT upYgmjSFnI0iEt+oLP8pV3KBcEzPTvBOJmLPiWHqF2tFzx4gGkSFnwKjEtAp LPMqlEdTNYfFuPV3Fnx.0rZV3Q4jAZT8Xk3NefVZL7XQxHsJS3Fnx.0rZV3w hjAZT8XgafJCTypYgGKRFnQ0iUh67AZUlviEICzn5wB2LRFnlUyBOVjLPij. KbyHYfZ7KK7zev.AqQKbyHYfZ7qv2EvfjhgQ4oAhUHlG2rFzBigwxhApuurv 8hjApuurvsXmA5d3yB2KRFn99xBe6RZjt5FgS0bBYKtYMonN7dTAMndrvUt1 .0pZV3ghjAZP8Xg23jApU0rvCEICzf5wr3l0fVXLbpFTLGdPNYfFtPV31mx. 0dcV3A4jAZ3BYgaeJCTqpYgGjSFnwdiEt8oLPspVXy5uWaA4oOhc+dtew5ce BW+qu454W+9iQ0U+zqOdr85CQ77Os3l2rKBVb812Le61GV91OtcwlSGd+1Se Xat9gk2eJnmM6zuksyucyyej2c25sua9grP57Gbyx+49Gz7eL8kf7cy+3psu 4huoaVd6tb0y+zO+Mrd9G1+Fl82eX47UO8Rtc0cuc9p8eSs3gmdMOK9dg244 e3mGsu9KI48+6gyL1mal81697wj0gb0rOL+yWuZ9lCYks2c6sqVb7WvtyddX 2u3sKd3MKV+32hmczNa8G+vx0qVrc+6yN9fK2+87S2HFO8Ju6ia+iuzCOz1e 89Sm9sb8tT2O8zu4cYikqu8MOr664Cufhm188vUkxi+6g++G+2Cmf7MdXtdw urKFOEfaW74Ceqcy7q+8SO3kOC34G19ENrKW9vNc1G6E+17O4Pt2e7eyC+kN j+vhMale6hu5X9cKWs5pMKW+W83N8M908W9t9aJkXoCmErOkTrG+Wq+88rf2 9w28tEO76WsyVY6U0uk7xEjA8KmV7WJs7tU2Me6Nu0Yuc95a+qkiFZ6O4wt3 oM6+jm83JCaN7lNkx9iqXbLw8+yMZ0KdA2d1K5qVh3qWd3q9JLb7jBDO8+MC mCYq42e+mV7vliej6ijcmP8y28vi+X6G1+iKWe3G2+IN6gEeZ4oWe80O9o8u d8+2E7psE -----------end_max5_patcher-----------
200 [poly~ 1]
----------begin_max5_patcher---------- 1494.3oc0cusaaZG..F+Z6mBjk1cYUbF7taOGSUUDahKU13HCoKcUMO6Cvw8 fZxZSSl+z2MnXBlv+e9zmIH3iyms3x82V2sH3OB9qfYy937Yyll03Llc+sms XW0sq1V0MsXKVse2t519EWb720Wea+z7SSB9sSy7p8s8cM+S83uHJ9Ug2O61 a10ztsteZEEc+LaVOc22e46983vkK9xht+l9SKa3Wsdaq1MsdW7mGZp1dZ4u tpe0aaZ27lC0q5ONbRJKG9KGTFNNMY5miG94fWOdO9z74iSt3mbP2ueyls0e 4O1ggMh95Cuots5xs0e8l3OdLV7viwSK6wY0+gqqONLVzLfcvqe7wYbQ9zHL 9zH7YLNaq+6gMxu6w10Uqt6o7Xa7CMtydAerMtXZzdbZRw+Gi4q2u8C2ELNs utqOH5Y9b6nGa7+nOt20roc.gO+P+SBnnvk4uJa3Y+4SOgXYpBhxOmDsrL0m PEmSgJGd8kNgJOmBULPiNgVdNEJOsTmPQgmSgxR78N0QQmSgRi88N0QwmSgR h78N0QImSghC88N0Qom0OsW3aTyzTe7qZIgHjlZUBgzTqRHjlZUBgzTaRnXj lZUBgzTqRHjlZUBgzTqRHhlZU.gzTWTlJhHhlZWBQzT6RHhlZWBQzTqRnDhl ZWBQzT6RHhlZWBQzT6RHflZW.wzTmkKhHjlZUBgzTqRHjlZUBgzTaRnTjlZU BgzTqRHjlZUBgzTqRHhlZU.wzTGVJhHjlZUBgzTqRHjlZUBgzTaRnLjlZUBg zTqRHjlZUBgzTqRHhlZU.gzTmWJ5PNOino1kPDM0tDhno1kPDM0pDJmno1kP DM0tDhno1kPDM0tDBno1EPLM0lNjyyQZpUIDRSsJgPZpUIDRSsIgJPZpUIDR SsJgPZpUIDRSsJgHZpUADSScnnC47BjlZUBgzTqRHjlZUBgzTaRnRjlZUBgz TqRHjlZUBgzTqRHhlZU.gzTmY5PNujno1kPDM0tDhno1kPDM0pDZIQSsKgHZ pcIDQSsKgHZpcIDPSsKfXZpiEcHmuDooVkPHM0pDBooVkPHM0hDZ3ieIZpUI DRSsJgPZpUIDRSsJgHZpEADytoNsvy25.YuTqBHhfZU.QzSqBHhbZS.grGpU ADQLsJfHZoUADQJsJf.JoU4CSIcpmuqAx9lVEPHkzl.Boj1DPHkzh.JBYGS6 RHjVZUBgDSqRHjZZUBQjSKBHlyyGogdNUnfbZ9PEPH4zl.BIm1DPH4zh.B4T 7gJfPhoMADRKsIfPRoMADQIsIePJoSJ7bBPA4j6gJfHJoUADQIsJfHJoMADx I1CU.QTRqBHhRZU.QTRqBHfRZS9vbMRLI1yo8DjKQhp.Boj1DPHkzl.BojVD PHWdDUADRIsIfPJoMADRIsIfHJoM4CRIc7ROGN4HWXDUADQIsJfHJoUADQIs IfPtnHpBHhRZU.QTRqBHhRZU.ATRaxmXlRZQGI4wHkzl.Boj1DPHkzl.BojV DPIHkzl.Boj1DPHkzl.Boj1DPDkzl7gojN1yQRdBRIsIfPJoMADRIsIfPJoE ATJRIsIfPJoMADRIsIfPJoMADQIsHehPJoiDcjjGQTRqBHhRZU.QTRqBHhRZ S.ESTRqBHhRZU.QTRqBHhRZU.ATRq5CwRQJoSEcgVOgnj1DPwDkzl.JhnjVD PHgzh7ofniVjO4DYzh7IinhVjOHQzuH9rqtqqZS82AzUMa2Fz0z9TfI9gNIR +Dk4WsKLJajg7jwooQiSiJeYeJyk2b0U0GtKX5ILYO2yiIOLKwOFKWsceU+h KF1JpZ277LZ4jNkQF9uX.7Uu9OeU0zZdw1l15ti2oSZMs9Fm+2ZV29aNr5zV 2w8n0vGEGD94sv0CL0zV02ru8aVpruYoday500SKvI4V2zUc415IpBevG+9Y 2hFeE5ObCp7Wby4nWUWe86qOzc+pbZKY3YSua+gwalewzMaZOdyo03hC0uu4 zxmMebs8o4+q5Ipnk -----------end_max5_patcher-----------
poly toplevel patcher
----------begin_max5_patcher---------- 389.3ocoTFsaCBBEF9Z8ofPxtqaArsa1c2dNVZVPEszffQvt10z9rO3XcyNa SVq2fgeN7y474A1GFfSza4FL5Uz6nff8gAAfjWH3z7.bIaapjYfvvo5xRtxh mztlku0B5SeA8PmXtVYMhu39EnQOQNIqZJEJI2BFQOIJxfsqSV+XD92.0M1t HI8bUwJAWwuUKXxt3qX1zUBUwG07TaawLMh3NW2oOy+YVrezKgV52xgvP+vj +YMWxMFVAePMmKjRjQntk5NZXcSIWtv6PTqjcWEus1vXzx6gIT5bOFddJfDJ vm36DIJ9mtTe.QRZxy40GQVtwhlOx9g3Kiknqgkbol4ZLcYASULNFs.nSLcT sMWgQUZ4tiH+HPoHBYjbZ1M19XDEJGDtS.sHp2EKJ4x2r.uwRg5uOt.N50Om aFcScZW90cm.Q9IEybjRnXVgV0Kn3yhYkHKiq5+hQlvvRjbfTjAYGqpZCu1b xRHSb++Vqq8SedBLUnZmBNhq4aDcwOOz61gvuwJk5jD -----------end_max5_patcher-----------
----------begin_max5_patcher---------- 374.3ocuT0saBCBF8Z5SAgKW5LEp0F2c64XwrPaYJlJz.nSmQe1G+zZzMWzY 27lujuCeb3bNP61H.pPtloQvmfu.AfsQ.fGxA.Z6AnEz0k0TseLjf8trXNJN rjgs13gkKM6g3N32jBil+AysDlLHoEVrbAWTyLdlvsf7p.AEye7v9sCZIrax jiXUPW3YE8rhSq6lugZJmwESeUwJMA2LL0drP7X2oCGNzUIICRfSb6XWTjqD 2OO+vdX1uwwju637evxcgS.xrogEbERymJr9FN4VxDblOL7ISJYP1eejzLip kJatjz2fgb+ClPMG+e7VooltYOzvzld9MRd54CFxEBlXHpfJl1q.JerqNhb1 .xSLplK95+S7z4vOM0zxkpxNQ14LXxA8UYyJtfZ3RwQCgOYlY7pJl33+QTw0 zhZlOuRN602UKGxUHm76ndvWidRuQ8Dt8nMMqXJcKmdoXecOWpbsih8sbQn0 yHRwVw6lOKxw1tnOADhn1kI -----------end_max5_patcher-----------
Thanks again peter!
Great stuff. Mainly about the adsr downsampling, what a hint, i would have never thought about that. So as you can see i am not too deep in the optimization trap :)
Its just, that i know a have been using this patch a long time and i will be using it for a long time onwards, and i know for sure it is quite inefficient right now. It needs a structural change and those are timeconsuming, so i try to use my time efficiently and talk to you guys on the forum before going about things.
And yes i am on this forum for too long time to not know that it’s really not great talking about patches without posting them, but this patch is really a whole lot bigger and messier than it sounds, so i will maybe post something if i made structural changes and cleaned it all up a bit.
Thanks a lot again, i’m really greatful and enjoy this alot,
have nice day all
I’d recommend polybuffer~ because it takes care of the numbering and the loading of a bunch of different soundfiles. Sure, you can use 8 buffer~ objects, but it’s always nice to avoid hardcoding.
Here’s something that I cooked up for one of my classes. It’s using polybuffer~, and it’s randomly picking a segment of a specified duration from one of however many files. I’ve got one of the early generations of MacBook Pro and it only takes 10-14% with 32 voices and this is without optimizing envelopes, etc. and with the generating metro set to 0 ms. It doesn’t do looping (I was using play~ for the class), but you can probably add that later.
Since your process might be dealing with note-ons, here’s an abstraction that I use all the time when dealing with poly~. My approach is to feed poly~ giant lists of parameters with the assumption that usually the only thing I care about on the note-off is that it’s a noteoff (hence the effect of this which is a lot like stripnote, but for additional parameters)
----------begin_max5_patcher---------- 835.3ocwXt0aaBCFF95jeEtb0pD0xG.iYR6hsq2+fpoIB3j3NhIBb5ZZU+uO iIzvpnDmCkbSR7WL1ueO90m3koS7lU7jnxC7Uv8fISdY5jI1P0Alrq7DuUIO klmTYqlmR72hYO3427WZwSZa3JQN.2FUsYUwFctPaeDxtnMgzaWKZ5OuYIpE d9.OOvu1Uk4EJsJYksBdeuTljC9QQdVa6tNQmtTpV76RQptoQvbJLjEGiY9. BECQwQw9.ZLDYJifn2ZZYlsQMZ+NLsiPkp2qyZQTIe1JBLAhpi95zo0e3edP RCjfY.Y+Xh9QXRpz0TpkV0EOCfwMLhfh4Xe.NfXXGKfFY9MBMHxH8hL7mOxJ kKVHJA4f7izcc1NqHDjynLJwGDigLFhGP8AL9fbBek3zy4fRwhwFQDNjPihX FDQB4PZbHFaLVg3AYD5JM86luAP8SH7Py8tTqNghfA73PjAVT5P.J9JwmqiG pKhb1Cw+rQTSd11KKs9.SXwihxs55T.HxqDfunJzh6JTUfBU91ats8ARTl+H QKKT1GqelhbiJTLCxh3TbfYYZNLHH.Ex57y93SzfKCkVrZkv0L5DfmsGOxYZ 68P8fCRDLpccFVsuvUNv5kCnd3vOkUZPwbvZoo2AOJxKRk5sfB8RQIt4KRyW TfPm5MFdpDUFnov74U2d7lnNKOeJlnvKfI5covkiZsiPGMU5b.nSAJANCk2T 3kKoslyiNiMydP0IaHL1jUgD2SVpyIaixtb6EsQsNI8OlyKKOx8i1cZ4ybi6 NK3DatKAkGvLGRNhLzdRjq2Q+pxkoB.Yj25tCjXDHmywn5aRPFjR3Scmaai4 kKUu+9pVkUG++QWUwlxz1Tc2dAf8RJSTokp21h992TWm5rTlkITcmckIqRlk KroS+CgtpFhCpgNZpA6fZHilZ3NnlnwiMHGjS3nNTgOjMd77wXWrNVDhGO8b H9vGM4PbYzZ7lYgcYYmfwUNXWLOiidhcwKOhqJScPO7wczhb.4De.4rRlstv b5rp12xFFF199H4wv.b.099HioPztK.uO9999CRplCIjrds4BIU6DlMeLmj5 ghx5hLeaQoponUWdkhGks0OZZcq85z+AdpEUh. -----------end_max5_patcher-----------
no, i got you , i got you, of course one per instance.
but why anyway? when you dont want to run them all at the same time. the play could be outside the poly just fine.
and then i also dont see the point of having the 8 buffers in a poly, as turning them off when not needed wont save much.
i would put them inside polys so i can mute them, i mean it does make some dififference if i have 8 [play~] s and really a good load of other calculation running, or if i have them inside poly, or even polys(strange idea, i’m getting tired, its 2 am here) and mute 7 or six of them, no? So actually just because i now i don’t want them all at the same time, and at the moment the CPU is doing the work as if i needed them to.
and again, i was/am a bit sceptical about just switching the referred buffer, also because i can’t do it at signal rate.
yeah, putting 8 buffers inside one poly, using one buffer per poly instance and all that jazz is.. i don’t know, i would just keep the buffers out of the poly buisiness, doesn’t seem to make sense, maybe i said something misleading somewhere up there. Polybuffer is an option, maybe i wrote poly buffer instead of [polybuffer~] ?
edit: i wanted to add that my little play~ patch is actually consisting of a regular xplay~ object and additionally there already is a poly with two instances inside there which does some granular stuff (two instances! thats why i want to optimize), so you can at least assume 8 plays~ really mean 8*3 play~s and more..
you cannot switch the buffer at samplingrate using poly either, because turning off and on the poly happens only at the beginning of a vector, just as it would with groove~, for example.
yes i just thought if i knew what poly instance would be active next, i can unmute it before and have everyhing still running at samplerate.
So just to be clear again, this would be the [poly mygrrovepatch 8] sollution with the buffers outside of course.