[PD] pduino rewrite

[Roman Haefeli]

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