13 Feb
2016
13 Feb
'16
8:55 p.m.
This is something I did not know about Max. I presume that is only with signal objects as I don't recall seeing that with non-signal ones? Perhaps this would be an opportunity to revisit nlet code to make it more versatile? I have on pd-l2ork's TODO to explore implementing nlets that can split signal and non signal, as well as refuse to connect things that shouldn't be connected, which works only in some cases. Perhaps this calls to also report when something is connected into the nlet?
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
Director -- DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
ico@vt.edu
www.performingarts.vt.edu
disis.icat.vt.edu
l2ork.icat.vt.edu
ico.bukvic.net
On Feb 13, 2016 2:00 PM, "Alexandre Torres Porres" porres@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@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>