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

[Matt Barber]

It would be useful to make a list of things objects often do that
abstractions can't​ (or can't do easily).


1) Variable numbers of xlets (except with initbang and dynamic patching,
which is tough to rely on for a library like cyclone) - e.g. [trigger].

2) Main signal inlets that also take messages (e.g. [tabread4~]).

3) Signal inlets which are initialized by an argument and can be set by a
float, where the argument/float value returns if the signal is disconnected
(e.g. [osc~].

4) Inlets which take signals or messages depending on the argument (e.g.
[*~ ] vs [*~ 0.5]).


You can all think of others.


On Sat, Feb 13, 2016 at 1:59 PM, Alexandre Torres Porres <porres at gmail.com>
wrote:

> 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
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20160213/90cf51ef/attachment.html>