Iohannes just merged an update to the external howto doc with this info.
On February 26, 2018 5:30:20 AM PST, Pierre Guillot <guillotpier...@gmail.com> wrote: >And sys_getblksize() always returns the global vector size (64). Within >an >external you need to know the vector size of the signals you receive >(using >sp[0]->s_n) because if the patch has a block object the vector size can >be >different from the global vector size. > >2018-02-26 14:24 GMT+01:00 Pierre Guillot <guillotpier...@gmail.com>: > >> Hi, >> As Miller explained previously, Pd reuse the inputs and outputs >vectors >> for optimization purposes so an input vector can correspond to an >output >> vector. When you write into an output vector, you can also write into >an >> input vector then when you read it after, you have false values. To >prevent >> that, in your example, you need to write the inputs' samples into a >> temporary vector before writing anything in an output vector (to >ensure >> that it doesn't overwrite an input). You should have a look to the >pull >> request that I created on your repo for multigate~. >> >> PS: The problem with mtx is in the perform method. The main loop goes >> beyond the vector size, you should simply remove it and move the >scope of >> the "gate" vector. >> >> Cheers, >> Pierre >> >> >> 2018-02-26 6:11 GMT+01:00 Alexandre Torres Porres <por...@gmail.com>: >> >>> 2018-02-25 6:45 GMT-03:00 IOhannes m zmölnig <zmoel...@iem.at>: >>> >>>> >>>> you probably should learn how to use a debugger >>> >>> >>> True! Enough fooling around... I should really learn how to use one >now >>> that I keep getting serious about this. But they're not so that easy >to get >>> started with for someone like me. I remember I wasn't very lucky >with it a >>> while back and just thought I'd let it go for then. But I see your >point >>> and it made me realize I gotta do something about it, thanks. >>> >>> #1 printf debugging. >>>> your code crashes? add printf() statements (or "post()" for that >>>> matter). >>> >>> >>> Yeah, that's all I really know how to do so far, it didn't help me >much >>> here. >>> >>> But anyway, I also have a not debugging issue, which would be how to >fix >>> this code to have its outlets flipped/reversed, see => >>> https://github.com/porres/pd-else/issues/161 >>> >>> This object is pretty stable, doesn't crash at all, but has this >issue. >>> I've been checking many externals and other examples, such as >>> cyclone/matrix~, the example one from Pierre, and also now yours >>> [matrix_*~] - and code above is actually modeled and derived after >>> [cyclone/gate~], so I guess enough checking other externals, cause >still no >>> luck for me... >>> >>> So the question to this list is if I can do something to get the >output >>> in the right order, from "1 to 6", instead of "6 to 1". If not a >simple >>> trick and edit to the current code, I see a way around would maybe >be to >>> have a temporary array and rearrange things over. But I also tried >all I >>> could think of (again also checking other externals) and nothing >>> worked... so I was hoping maybe I could get a hand on that at least. >>> >>> Thanks >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> Pd-dev@lists.iem.at >>> https://lists.puredata.info/listinfo/pd-dev >>> >>> >>
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
