hi, I've done a very simple test, and it works fine!
https://vimeo.com/37914564 On 4 March 2012 15:45, Roman Haefeli <reduz...@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@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- Jordi Sala http://musa.poperbu.net
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list