[PD-dev] [PD] Fwd: external help, please

[Alex Norman]

Iohannes just merged an update to the external howto doc with this info.

On February 26, 2018 5:30:20 AM PST, Pierre Guillot <guillotpierre6 at 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 <guillotpierre6 at 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 <porres at gmail.com>:
>>
>>> 2018-02-25 6:45 GMT-03:00 IOhannes m zmölnig <zmoelnig at 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 at lists.iem.at
>>> https://lists.puredata.info/listinfo/pd-dev
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20180226/e5de884d/attachment.html>