[PD] Cyclone: List of Issues with existing objects by Alexandre Porres

[Alexandre Torres Porres]

>
> As Ivica mentioned, abstractions are preferable from an educational point
> of view. And they are easier to maintain... So I see no problem adding them
> just like [teeth~]. If performance gets an issue, it is always possible to
> code that object, or its critical part, in c.
>

The problem with teeth~ now is that it has no arguments. Ok, that's easy to
fix, but there's a problem managing arguments with abstractions, and this
is what I was trying to explain in response to Ivica's email.

For example, in [comb~], if you send a signal to an inlet, it overwrites
the argument value, but if you disconnect that signal connection it will
revert to the argument's value. That's how it works in Max too and I don't
know any other way to achieve this other than with an external.

Please find attached an example with comb~ that illustrates this, when you
disconnect the signal connection (value of 0) it'll restore the argument
value (0.99).

Anyway, this is a common behaviour for such objetcs, so even if it's cool
and easy to make an abstraction, ot's just best for the design if you code
an external.

Another issue I could point with an abstraction in Pd for [teeth~] is that
the delay objects are kinda buggy in Pd, where you can't really go up to
the specified delay lenght. I've already reported this by the way. So, a
more accurate delay network could be achieved with an external.

Moreover, it should be really easy to make a teeth~ external from the code
in  comb~

cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160213/485ab536/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: comb.pd
Type: application/octet-stream
Size: 433 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160213/485ab536/attachment.obj>