On Thu, 2011-09-15 at 13:19 -0400, Hans-Christoph Steiner wrote: > On Thu, 2011-09-15 at 18:43 +0200, Roman Haefeli wrote: > > On Thu, 2011-09-15 at 11:36 -0400, Hans-Christoph Steiner wrote: > > > On Thu, 2011-09-15 at 10:01 +0200, Roman Haefeli wrote: > > > > On Thu, 2011-09-15 at 09:44 +0200, Ingo wrote: > > > > > The reason why I didn't make an abstraction for the "debyte" is that I > > > > > wanted to keep the number of files and dependencies as low as > > > > > possible. I > > > > > think this was the original idea of the rewrite, right? > > > > > > > > Yeah, exactly. I would like to be able to install [arduino] also on a > > > > plain Pd-vanilla setup with the least amount of additional effort. > > > > [comport] will always be needed, of course. > > > > > > Well, now you can and trivially install all but one of the dependencies > > > for 'puredata' aka Pd vanilla using: > > > > > > apt-get install pd-cyclone pd-mapping pd-zexy > > > > > > Only moocow is missing. I'd bet it'll be much less work to package > > > moocow then to rewrite and manage a fork of arduino.pd. > > > > I'm not sure about this, but I mostly agree with you. When packaging > > arduino as a pd-lib.deb, it would be trivial to add the dependencies. > > > > However, I find I found some rather ugly stuff inside [arduino] that I > > definitely wanted to get rid of, such as [prepend] from cyclone. > > I think that prepend works better, that's why. No need for [list trim]. > With cyclone/prepend being in Pd-extended and Debian, it doesn't seem > like too hard a thing to install it when you need it. I'm open to being > proven wrong on cyclone's prepend working better.
It's probably again a matter of taste, but cyclone is one the libraries I dislike the most. It has ugly class names (some of them with upper case), inconsistent ordering of inlets, it's very much un-Pd-like, since this is even it's purpose (emulating max object classes). IMHO, if it can so easily avoided to be used, then I'd rather not use it at all. > > On the long run, I don't see the point in having two different [arduino] > > classes to be maintained. If at some point, improvements of both can be > > merged to one class, I'm all for it. Even if it means re-adding some > > externals. But for stuff that is very trivial to do with vanilla > > classes, I don't see the point in using externals. And no, I really > > don't think that adds a lot of maintenance load to the class. > > Maintenance is one part of it, another is so that you don't have to > copy-n-paste subpatches in cases like multiple [debytemask]s, you just > make as many instances as you need. As I said previously, there is a much cleaner approach, that doesn't even need many [debytemask] instances, which I implemented in the git version. > > Another good reason is that there are useful bits of code developed > while writing the arduino.pd object, why not share them as objects? Can you name one? I don't know, if [debytemask] was developed for the [arduino], but while it is generally a very useful class, it cannot be used in [arduino] as is. Roman _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
