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