[PD] Pduino: Call for testing

Jordi Sala poperbu at gmail.com
Mon Mar 5 08:35:04 CET 2012


hi,

I've done a very simple test, and it works fine!

https://vimeo.com/37914564

On 4 March 2012 15:45, Roman Haefeli <reduzent at gmail.com> wrote:

> On Sat, 2012-03-03 at 22:27 -0800, Hans-Christoph Steiner wrote:
>
> > I would prefer that you use a different name unless you are interested
> > in providing strict compatibility with the current Pduino.
>
> Yes, actually I'm interested.
>
> >   Things like using namespace prefixes are one example of
> > compatibility that it sounds like you are not interested in, for
> > example.
>
> There is a conflict: Either it works only in Pd-extended setups, or you
> loose the advantage of using namespace prefixes. I solved that conflict
> by not using [makesymbol] at all.
>
> Some words about that particular case:
> Actually [zexy/makesymbol] wasn't ever used in [arduino], only in
> arduino-help.pd . There it's used to display the Firmware version in a
> GOP cnv object -> [zexy/makesymbol firmata_%s.%s]. This can be safely
> replaced nowadays by [symbol firmata_$1.$2(. However, I didn't even use
> that, because I thought it would be useful to display the whole Firmata
> specification there, not only the protocol version. It now displays
> something like:
>
> StandardFirmata 2 3
>
> and it does so with only using vanilla classes. Let me point that
> [arduino] itself is not all affected by this.
>
> > Pduino deliberately uses namespace prefixes because that's currently
> > the only way to guarantee the correct object is being loaded.
>
> Agreed.
>
> >  Using [declare -lib zexy]  [makesymbol] does not currently guarantee
> > that (tho it should).
>
> Yeah, I also agree that it should.
>
> Please, tell me about your further constraints, if there are any, and
> I'll see how I can comply with them.
>
> Roman
>
>
>
>
>
> > On Mar 3, 2012, at 6:47 AM, Roman Haefeli wrote:
> >
> > > Hi Hans
> > >
> > > On Fri, 2012-03-02 at 08:55 -0800, Hans-Christoph Steiner wrote:
> > >> I'm happy to see you working on this.  Since you are making a new
> > >> version, perhaps it makes sense to change the names.  Like maybe it
> > >> makes sense to change the object from [arduino] to [firmata]?  That's
> > >> something I thought about doing in the past.  This would also make it
> > >> easier for testers going forward because they could keep the old
> > >> Pduino installed and also use your new library.  I suppose then the
> > >> library would be called something besides Pduino too.
> > >>
> > >> But if you want to keep those names, that's fine by me.
> > >
> > > Actually, I prefer not to host a separate version/fork. I think the
> > > design of the protocol and its implementation in [arduino] is solid and
> > > I haven't messed at all with it. Our efforts for [arduino] were mainly
> > > focused on smallish issues with usability and portability. Our plans
> are
> > > to eventually push it into Debian as pd-arduino. For that goal, some
> > > changes like getting rid of name-spaced objects (for instance:
> > > [zexy/makesymbol], doesn't work in Debian with pd-zexy) and some other
> > > stuff were necessary. Plus, it got a bug fixed Ingo discovered a while
> > > ago. Still, the overall changes to [arduino] itself are rather smallish
> > > and I wouldn't expect any severe bugs. Also, I think we tested it quite
> > > well.
> > >
> > > The main effort, however, went into documentation and [arduino-gui] and
> > > to figure out the tiny details and differences between the several
> > > Firmata versions around in order to make the help-patch consistent as
> > > documentation and [arduino-gui] consistent in its behaviour.  I
> consider
> > > the updated help-patch a significant improvement (in that it covers all
> > > features of the firmware, is clear in which pin supports which mode,
> > > explains the differences in different firmware versions) and I wouldn't
> > > see a reason to keep to old one living.
> > >
> > > Personally, I'd much prefer not to host a separate fork and I am all
> for
> > > joining forces, not separating them. With your consent, I'd like to
> push
> > > the new version to the svn repository. We could wait to do so, until we
> > > got some positive reports from a few people, of course. There is really
> > > no hurry.  Also, I'd take responsibility for any issues and bugs
> related
> > > to Pduino (if that is what you want; I don't plan any 'hostile
> > > take-over').
> > >
> > > Finally, if we eventually agree on merging our git Pduino with the
> > > official pd-svn/externals/hardware/arduino, I'd like to bump the Pduino
> > > version to the Firmata version. As I understand, [arduino] is a plain
> > > implementation of the Firmata protocol, not less, not more. I think it
> > > would make sense to reflect the version of the protocol it implements
> in
> > > its own version. We could still add a bug-fix number, so changes to
> > > [arduino] without switching the prococol version could be reflected.
> > > Something like
> > >
> > > 2.3.1
> > > | | |
> > > | | Pduino bugfix version
> > > | protocol minor version
> > > protocol major version
> > >
> > > What do you think?
> > >
> > > Roman
> > >
> > >
> >
> >
> >
> >
> ----------------------------------------------------------------------------
> >
> > "[W]e have invented the technology to eliminate scarcity, but we are
> deliberately throwing it away to benefit those who profit from scarcity."
>      -John Gilmore
> >
> >
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>



-- 
Jordi Sala
http://musa.poperbu.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120305/df66c774/attachment-0001.htm>


More information about the Pd-list mailing list