Hi all
An improved version of [arduino] and its help patch is ready for testing and commenting. There is also a new [arduino-gui] class, that graphically emulates an Arduino board and is supposed to be very easy to use, especially for beginners.
Get it from here: https://github.com/reduzent/pduino
Some notes:
[arduino]
- got rid of many external dependencies
- now depends only on [comport] and [pdstring]
- fixed long-standing bug with wrongly reporting digital inputs
- improved performance for digital inputs (thanks to Ingo)
arduino-help.pd
- general overhaul
- updated to comply with Firmata v2.3
- improved sections for different pin modes
- added pin mode support table
- added reference off all arduino commands
- reflect supported modes for every pin in the documentation
- explain pull-up resistor features
- un-deprecate 'digitalIns' and 'analogIns' commands
[arduino-gui]
- new
- fully emulate Arduino board (only Firmata 2.2 and 2.3)
- easily generate valid arduino commands
- set pin mode and states with few mouse-clicks
- display current state for every pin
- requires Pd[-extended] >= 0.43
arduino-gui-help.pd
- new
- quickly explain [arduino-gui]
Please test and report back!
@Hans If no show stopper is found, do you mind if those updates and additions are added to pd-svn/externals/hardware/arduino?
Cheers Olsen & Roman
Sweet! I'll take some time, probably this week-end, to test it with my setup.
Pierre.
2012/2/28 Roman Haefeli reduzent@gmail.com
Hi all
An improved version of [arduino] and its help patch is ready for testing and commenting. There is also a new [arduino-gui] class, that graphically emulates an Arduino board and is supposed to be very easy to use, especially for beginners.
Get it from here: https://github.com/reduzent/pduino
Some notes:
[arduino]
- got rid of many external dependencies
- now depends only on [comport] and [pdstring]
- fixed long-standing bug with wrongly reporting digital inputs
- improved performance for digital inputs (thanks to Ingo)
arduino-help.pd
- general overhaul
- updated to comply with Firmata v2.3
- improved sections for different pin modes
- added pin mode support table
- added reference off all arduino commands
- reflect supported modes for every pin in the documentation
- explain pull-up resistor features
- un-deprecate 'digitalIns' and 'analogIns' commands
[arduino-gui]
- new
- fully emulate Arduino board (only Firmata 2.2 and 2.3)
- easily generate valid arduino commands
- set pin mode and states with few mouse-clicks
- display current state for every pin
- requires Pd[-extended] >= 0.43
arduino-gui-help.pd
- new
- quickly explain [arduino-gui]
Please test and report back!
@Hans If no show stopper is found, do you mind if those updates and additions are added to pd-svn/externals/hardware/arduino?
Cheers Olsen & Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sounds great Roman,
I have a gig tomorrow night so I don't want to mess with my setup right now. But I'll definitely give it whirl after that.
Thanks!
On Wed, Feb 29, 2012 at 12:12 AM, Pierre Massat pimassat@gmail.com wrote:
Sweet! I'll take some time, probably this week-end, to test it with my setup.
Pierre.
2012/2/28 Roman Haefeli reduzent@gmail.com
Hi all
An improved version of [arduino] and its help patch is ready for testing and commenting. There is also a new [arduino-gui] class, that graphically emulates an Arduino board and is supposed to be very easy to use, especially for beginners.
Get it from here: https://github.com/reduzent/pduino
Some notes:
[arduino]
- got rid of many external dependencies
- now depends only on [comport] and [pdstring]
- fixed long-standing bug with wrongly reporting digital inputs
- improved performance for digital inputs (thanks to Ingo)
arduino-help.pd
- general overhaul
- updated to comply with Firmata v2.3
- improved sections for different pin modes
- added pin mode support table
- added reference off all arduino commands
- reflect supported modes for every pin in the documentation
- explain pull-up resistor features
- un-deprecate 'digitalIns' and 'analogIns' commands
[arduino-gui]
- new
- fully emulate Arduino board (only Firmata 2.2 and 2.3)
- easily generate valid arduino commands
- set pin mode and states with few mouse-clicks
- display current state for every pin
- requires Pd[-extended] >= 0.43
arduino-gui-help.pd
- new
- quickly explain [arduino-gui]
Please test and report back!
@Hans If no show stopper is found, do you mind if those updates and additions are added to pd-svn/externals/hardware/arduino?
Cheers Olsen & Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey Roman,
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.
.hc
On Feb 28, 2012, at 3:15 AM, Roman Haefeli wrote:
Hi all
An improved version of [arduino] and its help patch is ready for testing and commenting. There is also a new [arduino-gui] class, that graphically emulates an Arduino board and is supposed to be very easy to use, especially for beginners.
Get it from here: https://github.com/reduzent/pduino
Some notes:
[arduino]
- got rid of many external dependencies
- now depends only on [comport] and [pdstring]
- fixed long-standing bug with wrongly reporting digital inputs
- improved performance for digital inputs (thanks to Ingo)
arduino-help.pd
- general overhaul
- updated to comply with Firmata v2.3
- improved sections for different pin modes
- added pin mode support table
- added reference off all arduino commands
- reflect supported modes for every pin in the documentation
- explain pull-up resistor features
- un-deprecate 'digitalIns' and 'analogIns' commands
[arduino-gui]
- new
- fully emulate Arduino board (only Firmata 2.2 and 2.3)
- easily generate valid arduino commands
- set pin mode and states with few mouse-clicks
- display current state for every pin
- requires Pd[-extended] >= 0.43
arduino-gui-help.pd
- new
- quickly explain [arduino-gui]
Please test and report back!
@Hans If no show stopper is found, do you mind if those updates and additions are added to pd-svn/externals/hardware/arduino?
Cheers Olsen & Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Programs should be written for people to read, and only incidentally for machines to execute.
- from Structure and Interpretation of Computer Programs
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
It won't really be a fork since I plan on making one more release, then I'm unlikely to touch the code again. So really, your development will be the active development.
I would prefer that you use a different name unless you are interested in providing strict compatibility with the current Pduino. Things like using namespace prefixes are one example of compatibility that it sounds like you are not interested in, for example. Pduino deliberately uses namespace prefixes because that's currently the only way to guarantee the correct object is being loaded. Using [declare -lib zexy] [makesymbol] does not currently guarantee that (tho it should).
.hc
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
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
hi,
I've done a very simple test, and it works fine!
On 4 March 2012 15:45, Roman Haefeli reduzent@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
On Mon, 2012-03-05 at 08:35 +0100, Jordi Sala wrote:
hi,
I've done a very simple test, and it works fine!
Cool! Thanks for that.
(Solely from watching the video, it's hard to judge whether everything is working as expected. I assume, you were able more easily to make sure that everything is correct, were you?)
Roman
On Mar 4, 2012, at 9:45 AM, Roman Haefeli 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.
Replacing [zexy/makesymbol] sounds like a good solution. I think that the [symbol Firmata_$1.$2( will produce the most readable version of this. "StandardFirmata 2 3" is not super clear, especially to newbies.
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.
I can't think of any off the top of my head, but I am sure they exist. The best approach for something like this, I think, is to try to make sure that the given output is exactly the same. So if the [zexy/makesymbol] code produces "Firmata_2.3", the updated code should as well, unless the problem is specifically because the message is like "Firmata_2.3".
.hc
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
¡El pueblo unido jamás será vencido!
On Tue, 2012-03-06 at 10:56 -0500, Hans-Christoph Steiner wrote:
On Mar 4, 2012, at 9:45 AM, Roman Haefeli wrote:
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.
Replacing [zexy/makesymbol] sounds like a good solution. I think that the [symbol Firmata_$1.$2( will produce the most readable version of this. "StandardFirmata 2 3" is not super clear, especially to newbies.
Why would like the help-patch to only show the version in some weird format instead of showing exactly what [arduino]'s right outlet is sending? Am I missing something here? It's easy to change, but I don't get your point here. If you insist, i'll change it.
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.
I can't think of any off the top of my head, but I am sure they exist. The best approach for something like this, I think, is to try to make sure that the given output is exactly the same. So if the [zexy/makesymbol] code produces "Firmata_2.3", the updated code should as well, unless the problem is specifically because the message is like "Firmata_2.3".
Sorry, if I am wrong, but I have the slight feeling, that you still think that something in [arduino] has changed. I can assure you that the updated [arduino] gives the _exact_ same output as the original one. That is, it still sends:
'firmware StandardFirmata 2 3'
'version 2 3'
to it's right outlet. Only the help-patch has changed (see above).
Please be assured, I wouldn't change any message format in [arduino] itself.
So, how we proceed?
Roman
yes, it works fine!
On 6 March 2012 17:12, Roman Haefeli reduzent@gmail.com wrote:
On Tue, 2012-03-06 at 10:56 -0500, Hans-Christoph Steiner wrote:
On Mar 4, 2012, at 9:45 AM, Roman Haefeli wrote:
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.
Replacing [zexy/makesymbol] sounds like a good solution. I think that the [symbol Firmata_$1.$2( will produce the most readable version of this. "StandardFirmata 2 3" is not super clear, especially to newbies.
Why would like the help-patch to only show the version in some weird format instead of showing exactly what [arduino]'s right outlet is sending? Am I missing something here? It's easy to change, but I don't get your point here. If you insist, i'll change it.
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.
I can't think of any off the top of my head, but I am sure they exist. The best approach for something like this, I think, is to try to make sure that the given output is exactly the same. So if the [zexy/makesymbol] code produces "Firmata_2.3", the updated code should as well, unless the problem is specifically because the message is like "Firmata_2.3".
Sorry, if I am wrong, but I have the slight feeling, that you still think that something in [arduino] has changed. I can assure you that the updated [arduino] gives the _exact_ same output as the original one. That is, it still sends:
'firmware StandardFirmata 2 3'
'version 2 3'
to it's right outlet. Only the help-patch has changed (see above).
Please be assured, I wouldn't change any message format in [arduino] itself.
So, how we proceed?
Roman
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Hans-Christoph Steiner -
Jordi Sala -
Pierre Massat -
Richie Cyngler -
Roman Haefeli