Re: [PD] pduino
On Mon, 2014-03-24 at 19:19 +0100, ro...@dds.nl wrote: i'm trying to use Pduino-0.5 and/or pduino-master (from reduzent) with Windows 7 and Arduino Uno. i don't get anything with [info( or [firmware( or [version(. it's possible to pulse all outputs, i.e. it's visible on Led13. toggling Led13 in Pduino only gives a short flash on the Led. the GUI in pduino-master seems to do nothing, except connecting through [comport] what am i missing? Pduino assumes there is the Firmata firmware installed on the Arduino board. I _think_ many recent Arduinos come with the Firmata firmware pre-installed. If that is not the case, you can install it yourself with the Arduino IDE. If [firmware( returns nothing, I would guess there is no Firmata installed. If you are sure Firmata is installed, please give us more details: * Version of Firmata ? * Board model? * Pd distro / version? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino
sorry for the noise. i did not realize Standard Firmata is a specific 'sketch' which is in the examples. thx, rolf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pduino
i'm trying to use Pduino-0.5 and/or pduino-master (from reduzent) with Windows 7 and Arduino Uno. i don't get anything with [info( or [firmware( or [version(. it's possible to pulse all outputs, i.e. it's visible on Led13. toggling Led13 in Pduino only gives a short flash on the Led. the GUI in pduino-master seems to do nothing, except connecting through [comport] what am i missing? rolf ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] PDuino/Firmata - arduino object - PWM servo problem
Solved the problem - has nothing to do with the PD object but only with the behaviour of the Arduino servo library: On boards other than the Mega, use of the library disables analogWrite() (PWM) functionality on pins 9 and 10, whether or not there is a Servo on those pins. http://arduino.cc/en/Reference/Servo Best, Maciej Am 30.04.2013 um 21:09 schrieb Maciej Sledziecki: Hello, I´m running StandardFirmata 2.3. on Arduino Uno with PD extended 0.43.4 on MacBookPro / MacOSX 10.6.8. What I´m trying to do, is to drive two pins (9 10) in pwm mode and at least two others (5 6) in servo mode. The pwm works fine - but only until I set one of the other pins to servo - then the diode that should be dimmed by pwm is either ON when receiving analog 1 or OFF when receiving any other value. The only way to get back to pwm again, is to close the arduino comport an reopen it again. Is there a way to avoid this and to drive different pins in different modes at the same time? Thanks and best, Maciej ___ 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
[PD] PDuino/Firmata - arduino object - PWM servo problem
Hello, I´m running StandardFirmata 2.3. on Arduino Uno with PD extended 0.43.4 on MacBookPro / MacOSX 10.6.8. What I´m trying to do, is to drive two pins (9 10) in pwm mode and at least two others (5 6) in servo mode. The pwm works fine - but only until I set one of the other pins to servo - then the diode that should be dimmed by pwm is either ON when receiving analog 1 or OFF when receiving any other value. The only way to get back to pwm again, is to close the arduino comport an reopen it again. Is there a way to avoid this and to drive different pins in different modes at the same time? Thanks and best, Maciej ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pduino download?
Hi Hans, Is this still the right link for downloading Pduino? http://at.or.at/hans/pd/Pduino-0.5.zip It's currently timing out (found on this page: http://puredata.info/downloads/pduino/releases/0.5). thanks, Phil Stone ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino download?
DNS troubles. Its fixed, but it might take a day or so to expire in your DNS cache. pduino is now also included in Pd-extended 0.43.4. .hc On 01/20/2013 03:01 AM, Phil Stone wrote: Hi Hans, Is this still the right link for downloading Pduino? http://at.or.at/hans/pd/Pduino-0.5.zip It's currently timing out (found on this page: http://puredata.info/downloads/pduino/releases/0.5). thanks, Phil Stone ___ 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
Re: [PD] pduino patch help
Ej Drake you've to put the arduino.pd abstraction and all other patches you're refering within the same folder where you saved your patch. Another problemo is your patch is refering to [arduino] and [Arduino] - notice the upper and the lower case - guess it should be lowercase [arduino] only! the argument within the [arduino] in your case f.e. [arduino 1] is the port that will be opened by loading the patch. You can get the info aboutthe availiable ports by sending a [devices( message to the [arduino] and/or reading the arduino-help.pd. hth ø btw the pduino rewrite by roman myself might make your life easier as it provides a more graphical approach for pduino called arduino-gui.pd - you'll find it here https://github.com/reduzent/pduino On 05/04/2012 11:04 PM, Drake Schutt wrote: you'll find my patch attached! On Fri, May 4, 2012 at 2:04 PM, Hans-Christoph Steiner h...@at.or.at mailto:h...@at.or.at wrote: Attach the patch, then we can take a look , attached pd patches arewelcome, common and even encouraged here! :-D .hc On May 4, 2012, at 2:59 PM, Drake Schutt wrote: I've got a fairly simple patch that I got help from someone on the list in building. It just takes midi data from 16 drum pads and routes the bangs to different output pins. The pins then trigger a seperate solenoids with the arduino board. These solenoids hit actual drums. I thought the pd patch was working last week and the [digital 0 0] message box was displaying different numbers when different drum pads were triggered. I then updated the firmata library because I thought I should. The [digital 0 0] box then stopped displaying numbers according to midiinput data. Would someone mind looking at my patch and seeing if something is wrong? I don't know a whole lot about pd. I can send it off list, I doubt there's attachments here. Thanks, Drake ___ Pd-list@iem.at mailto: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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pduino patch help
I've got a fairly simple patch that I got help from someone on the list in building. It just takes midi data from 16 drum pads and routes the bangs to different output pins. The pins then trigger a seperate solenoids with the arduino board. These solenoids hit actual drums. I thought the pd patch was working last week and the [digital 0 0] message box was displaying different numbers when different drum pads were triggered. I then updated the firmata library because I thought I should. The [digital 0 0] box then stopped displaying numbers according to midi input data. Would someone mind looking at my patch and seeing if something is wrong? I don't know a whole lot about pd. I can send it off list, I doubt there's attachments here. Thanks, Drake ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patch help
Attach the patch, then we can take a look , attached pd patches are welcome, common and even encouraged here! :-D .hc On May 4, 2012, at 2:59 PM, Drake Schutt wrote: I've got a fairly simple patch that I got help from someone on the list in building. It just takes midi data from 16 drum pads and routes the bangs to different output pins. The pins then trigger a seperate solenoids with the arduino board. These solenoids hit actual drums. I thought the pd patch was working last week and the [digital 0 0] message box was displaying different numbers when different drum pads were triggered. I then updated the firmata library because I thought I should. The [digital 0 0] box then stopped displaying numbers according to midi input data. Would someone mind looking at my patch and seeing if something is wrong? I don't know a whole lot about pd. I can send it off list, I doubt there's attachments here. Thanks, Drake ___ 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
Re: [PD] pduino patch help
Hello, in fact you can put attachments here on the list. I am sorry but I am not really helpful on this matter, as I am myself also trying to get some piezo-triggerings onto Pd through Arduino and are still learning around this. I wouldn´t mind take a look at the patch - but as said before - I am not sure I could be to so much help. All the best, Björn Eriksson On Fri, May 4, 2012 at 8:59 PM, Drake Schutt drak...@gmail.com wrote: I've got a fairly simple patch that I got help from someone on the list in building. It just takes midi data from 16 drum pads and routes the bangs to different output pins. The pins then trigger a seperate solenoids with the arduino board. These solenoids hit actual drums. I thought the pd patch was working last week and the [digital 0 0] message box was displaying different numbers when different drum pads were triggered. I then updated the firmata library because I thought I should. The [digital 0 0] box then stopped displaying numbers according to midi input data. Would someone mind looking at my patch and seeing if something is wrong? I don't know a whole lot about pd. I can send it off list, I doubt there's attachments here. Thanks, Drake ___ 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
Re: [PD] pduino patch help
you'll find my patch attached! On Fri, May 4, 2012 at 2:04 PM, Hans-Christoph Steiner h...@at.or.atwrote: Attach the patch, then we can take a look , attached pd patches are welcome, common and even encouraged here! :-D .hc On May 4, 2012, at 2:59 PM, Drake Schutt wrote: I've got a fairly simple patch that I got help from someone on the list in building. It just takes midi data from 16 drum pads and routes the bangs to different output pins. The pins then trigger a seperate solenoids with the arduino board. These solenoids hit actual drums. I thought the pd patch was working last week and the [digital 0 0] message box was displaying different numbers when different drum pads were triggered. I then updated the firmata library because I thought I should. The [digital 0 0] box then stopped displaying numbers according to midi input data. Would someone mind looking at my patch and seeing if something is wrong? I don't know a whole lot about pd. I can send it off list, I doubt there's attachments here. Thanks, Drake ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list v2.pd Description: Binary data ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
So I added support for Pd-extended to load arduino/arduino.pd when creating [arduino]. Now yo can drop the arduino/ folder into the standard install location and then create [arduino]. It should be in the beta builds as of yesterday. .hc On Apr 10, 2012, at 1:31 PM, Hans-Christoph Steiner wrote: I see what you are doing now. Pd only works like that for binary objects, not abstractions, i.e. : - extra/comport/comport.pd_linux can be loaded as [comport] - extra/arduino/arduino.pd triggers that 1000 error when loaded as [arduino] As an aside, you really shouldn't put stuff directly into extra/ but instead use the standard install paths: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files .hc On Apr 10, 2012, at 12:23 PM, Patrice Colet wrote: I've extracted the zip file content into this empty folder I've created: C:\Program Files (x86)\pd\extra\arduino I've added arduino folder to path in preferences and started pd by double-clicking on the C:\Program Files (x86)\pd\extra\arduino\arduino-help.pd In the doubt I've updated pdx to 20120410, also tried to create [arduino] object in a naked patch, same result. hope it helps - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 17:16:36 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 15:54 +0200, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? It's supposed to work for all version that Hans' version is supposed to work for. At least it would work with = 0.42. Can you give us more information about the path of Pd-extended installation, the Pduino installation and how you started Pd-extended and how you opened arduino-help.pd ? Thanks for your report 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 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
Great you rock, let's eat the omlet ^^ Colet Patrice - Mail original - De: Hans-Christoph Steiner h...@at.or.at À: Patrice Colet colet.patr...@free.fr, pd-list pd-list@iem.at Envoyé: Mardi 17 Avril 2012 19:03:00 Objet: Re: [PD] pduino patches on pdx So I added support for Pd-extended to load arduino/arduino.pd when creating [arduino]. Now yo can drop the arduino/ folder into the standard install location and then create [arduino]. It should be in the beta builds as of yesterday. .hc On Apr 10, 2012, at 1:31 PM, Hans-Christoph Steiner wrote: I see what you are doing now. Pd only works like that for binary objects, not abstractions, i.e. : - extra/comport/comport.pd_linux can be loaded as [comport] - extra/arduino/arduino.pd triggers that 1000 error when loaded as [arduino] As an aside, you really shouldn't put stuff directly into extra/ but instead use the standard install paths: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files .hc On Apr 10, 2012, at 12:23 PM, Patrice Colet wrote: I've extracted the zip file content into this empty folder I've created: C:\Program Files (x86)\pd\extra\arduino I've added arduino folder to path in preferences and started pd by double-clicking on the C:\Program Files (x86)\pd\extra\arduino\arduino-help.pd In the doubt I've updated pdx to 20120410, also tried to create [arduino] object in a naked patch, same result. hope it helps - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 17:16:36 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 15:54 +0200, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? It's supposed to work for all version that Hans' version is supposed to work for. At least it would work with = 0.42. Can you give us more information about the path of Pd-extended installation, the Pduino installation and how you started Pd-extended and how you opened arduino-help.pd ? Thanks for your report 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 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
Basically every library in Pd-extended is in libdir format, and from what I've seen, most people have no problem using non-vanilla objects in Pd-extended. Yes, in 0.43 development there were some problems related to libdirs, but you got to break some eggs to make an omelet. Now everything works again. .hc On Apr 12, 2012, at 11:53 AM, Patrice Colet wrote: I'm sorry to say that, it's just a mirror of my ignorance, but I think that libdir is confusing, useless, and unstable like I said to the list in another thread, please prove me I'm wrong ;) Colet Patrice - Mail original - De: Hans-Christoph Steiner h...@at.or.at À: Patrice Colet colet.patr...@free.fr Cc: pd-list pd-list@iem.at Envoyé: Jeudi 12 Avril 2012 17:03:26 Objet: Re: [PD] pduino patches on pdx Why's that? .hc On Apr 12, 2012, at 10:46 AM, Patrice Colet wrote: I just hope libdir will never go into vanilla ^^ Colet Patrice - Mail original - De: Hans-Christoph Steiner h...@at.or.at À: Patrice Colet colet.patr...@free.fr Cc: pd-list pd-list@iem.at, Roman Haefeli reduz...@gmail.com Envoyé: Jeudi 12 Avril 2012 04:49:32 Objet: Re: [PD] pduino patches on pdx It would affect vanilla if you have the libdir loader running in it. Its related to that. .hc On Apr 11, 2012, at 7:57 PM, Patrice Colet wrote: I've switched back to vanilla, no bug anymore :D Colet Patrice - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 22:42:54 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 10:17 -0400, Hans-Christoph Steiner wrote: On Apr 10, 2012, at 9:54 AM, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino What is the point of your remark, if the problem described isn't in any way related to the used version? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic http://at.or.at/hans/ It is convenient to imagine a power beyond us because that means we don't have to examine our own lives., from The Idols of Environmentalism, by Curtis White ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
I just hope libdir will never go into vanilla ^^ Colet Patrice - Mail original - De: Hans-Christoph Steiner h...@at.or.at À: Patrice Colet colet.patr...@free.fr Cc: pd-list pd-list@iem.at, Roman Haefeli reduz...@gmail.com Envoyé: Jeudi 12 Avril 2012 04:49:32 Objet: Re: [PD] pduino patches on pdx It would affect vanilla if you have the libdir loader running in it. Its related to that. .hc On Apr 11, 2012, at 7:57 PM, Patrice Colet wrote: I've switched back to vanilla, no bug anymore :D Colet Patrice - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 22:42:54 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 10:17 -0400, Hans-Christoph Steiner wrote: On Apr 10, 2012, at 9:54 AM, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino What is the point of your remark, if the problem described isn't in any way related to the used version? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
Why's that? .hc On Apr 12, 2012, at 10:46 AM, Patrice Colet wrote: I just hope libdir will never go into vanilla ^^ Colet Patrice - Mail original - De: Hans-Christoph Steiner h...@at.or.at À: Patrice Colet colet.patr...@free.fr Cc: pd-list pd-list@iem.at, Roman Haefeli reduz...@gmail.com Envoyé: Jeudi 12 Avril 2012 04:49:32 Objet: Re: [PD] pduino patches on pdx It would affect vanilla if you have the libdir loader running in it. Its related to that. .hc On Apr 11, 2012, at 7:57 PM, Patrice Colet wrote: I've switched back to vanilla, no bug anymore :D Colet Patrice - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 22:42:54 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 10:17 -0400, Hans-Christoph Steiner wrote: On Apr 10, 2012, at 9:54 AM, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino What is the point of your remark, if the problem described isn't in any way related to the used version? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
On Wed, 2012-04-11 at 22:49 -0400, Hans-Christoph Steiner wrote: It would affect vanilla if you have the libdir loader running in it. Its related to that. I think I experienced once also problem with maximum object loading depth 1000 reached and this was on Pd-vanilla without libdir. So probably there is still a problem outside of libdir? I'll post again, when I figured out how to exactly reproduce the situation. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
I'm sorry to say that, it's just a mirror of my ignorance, but I think that libdir is confusing, useless, and unstable like I said to the list in another thread, please prove me I'm wrong ;) Colet Patrice - Mail original - De: Hans-Christoph Steiner h...@at.or.at À: Patrice Colet colet.patr...@free.fr Cc: pd-list pd-list@iem.at Envoyé: Jeudi 12 Avril 2012 17:03:26 Objet: Re: [PD] pduino patches on pdx Why's that? .hc On Apr 12, 2012, at 10:46 AM, Patrice Colet wrote: I just hope libdir will never go into vanilla ^^ Colet Patrice - Mail original - De: Hans-Christoph Steiner h...@at.or.at À: Patrice Colet colet.patr...@free.fr Cc: pd-list pd-list@iem.at, Roman Haefeli reduz...@gmail.com Envoyé: Jeudi 12 Avril 2012 04:49:32 Objet: Re: [PD] pduino patches on pdx It would affect vanilla if you have the libdir loader running in it. Its related to that. .hc On Apr 11, 2012, at 7:57 PM, Patrice Colet wrote: I've switched back to vanilla, no bug anymore :D Colet Patrice - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 22:42:54 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 10:17 -0400, Hans-Christoph Steiner wrote: On Apr 10, 2012, at 9:54 AM, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino What is the point of your remark, if the problem described isn't in any way related to the used version? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic http://at.or.at/hans/ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
I've switched back to vanilla, no bug anymore :D Colet Patrice - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 22:42:54 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 10:17 -0400, Hans-Christoph Steiner wrote: On Apr 10, 2012, at 9:54 AM, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino What is the point of your remark, if the problem described isn't in any way related to the used version? 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
Re: [PD] pduino patches on pdx
It would affect vanilla if you have the libdir loader running in it. Its related to that. .hc On Apr 11, 2012, at 7:57 PM, Patrice Colet wrote: I've switched back to vanilla, no bug anymore :D Colet Patrice - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 22:42:54 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 10:17 -0400, Hans-Christoph Steiner wrote: On Apr 10, 2012, at 9:54 AM, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino What is the point of your remark, if the problem described isn't in any way related to the used version? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list Access to computers should be unlimited and total. - the hacker ethic ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pduino patches on pdx
Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? Colet Patrice * why the pdx release version isn't simply in a comment object? It's a pain in the ass for retyping it ^^ ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
On Apr 10, 2012, at 9:54 AM, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino Colet Patrice * why the pdx release version isn't simply in a comment object? It's a pain in the ass for retyping it ^^ Good idea, I'll do that. .hc I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. --Bjarne Stroustrup (creator of C++) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
On Tue, 2012-04-10 at 15:54 +0200, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? It's supposed to work for all version that Hans' version is supposed to work for. At least it would work with = 0.42. Can you give us more information about the path of Pd-extended installation, the Pduino installation and how you started Pd-extended and how you opened arduino-help.pd ? Thanks for your report Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
Colet Patrice - Mail original - De: Hans-Christoph Steiner h...@at.or.at FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino Yes, very interesting, I have all digital outputs and analog in working correctly with my arduino NG, but once digital pins are set to inputs they don't detect the voltage I'm sending, using standard firmata. I'll try soon with a diecimila... Colet Patrice * why the pdx release version isn't simply in a comment object? It's a pain in the ass for retyping it ^^ Good idea, I'll do that. Thanks a lot!:) .hc I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone. --Bjarne Stroustrup (creator of C++) ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
I've extracted the zip file content into this empty folder I've created: C:\Program Files (x86)\pd\extra\arduino I've added arduino folder to path in preferences and started pd by double-clicking on the C:\Program Files (x86)\pd\extra\arduino\arduino-help.pd In the doubt I've updated pdx to 20120410, also tried to create [arduino] object in a naked patch, same result. hope it helps - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 17:16:36 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 15:54 +0200, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? It's supposed to work for all version that Hans' version is supposed to work for. At least it would work with = 0.42. Can you give us more information about the path of Pd-extended installation, the Pduino installation and how you started Pd-extended and how you opened arduino-help.pd ? Thanks for your report 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
Re: [PD] pduino patches on pdx
I see what you are doing now. Pd only works like that for binary objects, not abstractions, i.e. : - extra/comport/comport.pd_linux can be loaded as [comport] - extra/arduino/arduino.pd triggers that 1000 error when loaded as [arduino] As an aside, you really shouldn't put stuff directly into extra/ but instead use the standard install paths: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files .hc On Apr 10, 2012, at 12:23 PM, Patrice Colet wrote: I've extracted the zip file content into this empty folder I've created: C:\Program Files (x86)\pd\extra\arduino I've added arduino folder to path in preferences and started pd by double-clicking on the C:\Program Files (x86)\pd\extra\arduino\arduino-help.pd In the doubt I've updated pdx to 20120410, also tried to create [arduino] object in a naked patch, same result. hope it helps - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 17:16:36 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 15:54 +0200, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? It's supposed to work for all version that Hans' version is supposed to work for. At least it would work with = 0.42. Can you give us more information about the path of Pd-extended installation, the Pduino installation and how you started Pd-extended and how you opened arduino-help.pd ? Thanks for your report 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 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
arf ok, I really dislike to have all files scattered everywhere in the computer thanks again. Colet Patrice - Mail original - De: Hans-Christoph Steiner h...@at.or.at À: Patrice Colet colet.patr...@free.fr Cc: pd-list pd-list@iem.at Envoyé: Mardi 10 Avril 2012 19:31:08 Objet: Re: [PD] pduino patches on pdx I see what you are doing now. Pd only works like that for binary objects, not abstractions, i.e. : - extra/comport/comport.pd_linux can be loaded as [comport] - extra/arduino/arduino.pd triggers that 1000 error when loaded as [arduino] As an aside, you really shouldn't put stuff directly into extra/ but instead use the standard install paths: http://puredata.info/docs/faq/how-do-i-install-externals-and-help-files .hc On Apr 10, 2012, at 12:23 PM, Patrice Colet wrote: I've extracted the zip file content into this empty folder I've created: C:\Program Files (x86)\pd\extra\arduino I've added arduino folder to path in preferences and started pd by double-clicking on the C:\Program Files (x86)\pd\extra\arduino\arduino-help.pd In the doubt I've updated pdx to 20120410, also tried to create [arduino] object in a naked patch, same result. hope it helps - Mail original - De: Roman Haefeli reduz...@gmail.com À: pd-list@iem.at Envoyé: Mardi 10 Avril 2012 17:16:36 Objet: Re: [PD] pduino patches on pdx On Tue, 2012-04-10 at 15:54 +0200, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? It's supposed to work for all version that Hans' version is supposed to work for. At least it would work with = 0.42. Can you give us more information about the path of Pd-extended installation, the Pduino installation and how you started Pd-extended and how you opened arduino-help.pd ? Thanks for your report 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 If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
On Tue, 2012-04-10 at 10:17 -0400, Hans-Christoph Steiner wrote: On Apr 10, 2012, at 9:54 AM, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino What is the point of your remark, if the problem described isn't in any way related to the used version? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
On Tue, 2012-04-10 at 13:31 -0400, Hans-Christoph Steiner wrote: I see what you are doing now. Pd only works like that for binary objects, not abstractions, i.e. : - extra/comport/comport.pd_linux can be loaded as [comport] - extra/arduino/arduino.pd triggers that 1000 error when loaded as [arduino] Woult it be possible to allow that as well for abstraction? Probably it is a feature, but to me it looks like a bug. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
On Apr 10, 2012, at 4:42 PM, Roman Haefeli wrote: On Tue, 2012-04-10 at 10:17 -0400, Hans-Christoph Steiner wrote: On Apr 10, 2012, at 9:54 AM, Patrice Colet wrote: Hello, I've downloaded a zip at this url: https://github.com/reduzent/pduino to get arduino patches for the 0.43.1-extended-20111221* release I've got installed in my vista box. When I'm launching an help patch I've got this error message in console: maximum object loading depth 1000 reached arduino ... couldn't create I suppose it's not directly related with arduino patches but I don't often open abs with thousands of objects inside ;) On which version of pdx is it supposed to work? FYI, that version of Pduino is a development version. If you want the current stable release, then use this release: http://puredata.info/downloads/pduino What is the point of your remark, if the problem described isn't in any way related to the used version? Sorry, I forgot the cause. That's just my default answer ;) .hc ¡El pueblo unido jamás será vencido! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino patches on pdx
On Apr 10, 2012, at 4:44 PM, Roman Haefeli wrote: On Tue, 2012-04-10 at 13:31 -0400, Hans-Christoph Steiner wrote: I see what you are doing now. Pd only works like that for binary objects, not abstractions, i.e. : - extra/comport/comport.pd_linux can be loaded as [comport] - extra/arduino/arduino.pd triggers that 1000 error when loaded as [arduino] Woult it be possible to allow that as well for abstraction? Probably it is a feature, but to me it looks like a bug. It looks like a bug to me too, I'll look and see if I can fix it. .hc Making boring techno music is really easy with modern tools, but with live coding, boring techno is much harder. - Chris McCormick ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pduino: Call for testing
On Mon, 2012-03-05 at 08:35 +0100, Jordi Sala wrote: hi, I've done a very simple test, and it works fine! https://vimeo.com/37914564 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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pduino: Call for testing
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
Re: [PD] Pduino: Call for testing
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
Re: [PD] Pduino: Call for testing
yes, it works fine! On 6 March 2012 17:12, Roman Haefeli reduz...@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 -- Jordi Sala http://musa.poperbu.net ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pduino: Call for testing
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
Re: [PD] Pduino: Call for testing
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
Re: [PD] Pduino: Call for testing
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pduino: Call for testing
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pduino: Call for testing
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 ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] Pduino: Call for testing
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
Re: [PD] Pduino: Call for testing
Sweet! I'll take some time, probably this week-end, to test it with my setup. Pierre. 2012/2/28 Roman Haefeli reduz...@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
Re: [PD] Pduino: Call for testing
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 pimas...@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 reduz...@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 -- Richie www.glitchpop.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
heho i just put my attempt for a solution considering this pin numbering confusion into github: https://github.com/reduzent/pduino take a look if time and leisure permitting - I'm herewith opening the suggestion box! thanks in advance salutis ø On 11/09/2011 09:54 AM, olsen wrote: Thanks Hans for making this thing clear - I'll try to find an adequate solution for the rewritten pduino-help asap! best ø On 11/03/2011 03:39 PM, Hans-Christoph Steiner wrote: That confusion originates from the Arduino numbering scheme itself, since it uses A0 for analog pins in analog mode, but then it uses a number when using the same pin for digital things. I think one way to represent this might be to allow the use of A0-A7 pin names in addition to the numbers, but then the confusing thing would be that the analog messages would then be [analog 14 0.2352(. So that's why I thought to try to use only the numbers, no A0-A7, and try to make that as understandable as possible. .hc On Nov 3, 2011, at 6:57 AM, olsen wrote: yo bonitos due to the pduino rewrite I've to reanimate this threat ;) I would like to remove the ambiguity and confusion about this old and new way of enabling the analog pins. old way of enabling the analog 0 pin is sending the following to the arduino object: [analogIns 0 1( enabling the same pin(analog 0) the new school way: [pinMode 14 analog( is this correct? if so what's a bit byte confusing for people is that in the new way pin 14 equals the analog 0 pin - guess this is a peculiarity of firmata? isn't there a possability to use f.e. A0-A5 for adressing the analog pins? thanks for info salutis ø On 06/17/2011 10:52 AM, olsen wrote: On 06/17/2011 12:24 AM, Matteo Sisti Sette wrote: On 06/16/2011 05:44 PM, olsen wrote: it's all in the arduino-help.pd by Gerda Strobl and Georg Holzmann! Which one??? Not the one that is distributed together with [arduino] and [arduino-test] at http://at.or.at/hans/pd/objects.html, right? yo it's in Pduino-0.5beta8 linked on this page in the last subpatch [pd SWITCHING-INPUTS] you'll find the apropriate messages. There I find the same analogIns messages that are supposed to be the old ones (but are the only ones I've found that work for analog pins with the latest version of Firmata) jep i agree they're the same - i think it's a matter of wrong denotation so due to my knowledge there's nothing like old and newer messages - the current 'contemporary' message for enabling the analog inputs is: [analogIns pinumber 1=on; 0=off( f.e. to enable analog pin 1: [analogIns 1 1( correct me if i'm wrong! i don't know why this is commented with (optional) I must have another version of the help patch, as I don't see such a comment right behind the [pd SWITCHING-INPUTS] is a comment - example of switching inputs on and off (optional) How are the messages you're talking about? i guess it's a firmata peculiarity that you've explicit have to enable the analog pins as in arduino they are enabled by default - but correct me if i'm wrong. Yes, I guess what you have to explicitly enable is to have the firmware _send_ the values to the computer. It would be undesirable to have a constant flood of values of all pins whether you use them or not. jep right so with firmata the analogIns have to be enabled explicitly to use them. i think the (optional) comment somehow makes it ambiguous. as told i'll try to consider this in the improvements we're working on! salutis ø -- ETs DNA will not be televised http://hasa-labs.org There is no way to peace, peace is the way. -A.J. Muste -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
Thanks Hans for making this thing clear - I'll try to find an adequate solution for the rewritten pduino-help asap! best ø On 11/03/2011 03:39 PM, Hans-Christoph Steiner wrote: That confusion originates from the Arduino numbering scheme itself, since it uses A0 for analog pins in analog mode, but then it uses a number when using the same pin for digital things. I think one way to represent this might be to allow the use of A0-A7 pin names in addition to the numbers, but then the confusing thing would be that the analog messages would then be [analog 14 0.2352(. So that's why I thought to try to use only the numbers, no A0-A7, and try to make that as understandable as possible. .hc On Nov 3, 2011, at 6:57 AM, olsen wrote: yo bonitos due to the pduino rewrite I've to reanimate this threat ;) I would like to remove the ambiguity and confusion about this old and new way of enabling the analog pins. old way of enabling the analog 0 pin is sending the following to the arduino object: [analogIns 0 1( enabling the same pin(analog 0) the new school way: [pinMode 14 analog( is this correct? if so what's a bit byte confusing for people is that in the new way pin 14 equals the analog 0 pin - guess this is a peculiarity of firmata? isn't there a possability to use f.e. A0-A5 for adressing the analog pins? thanks for info salutis ø On 06/17/2011 10:52 AM, olsen wrote: On 06/17/2011 12:24 AM, Matteo Sisti Sette wrote: On 06/16/2011 05:44 PM, olsen wrote: it's all in the arduino-help.pd by Gerda Strobl and Georg Holzmann! Which one??? Not the one that is distributed together with [arduino] and [arduino-test] at http://at.or.at/hans/pd/objects.html, right? yo it's in Pduino-0.5beta8 linked on this page in the last subpatch [pd SWITCHING-INPUTS] you'll find the apropriate messages. There I find the same analogIns messages that are supposed to be the old ones (but are the only ones I've found that work for analog pins with the latest version of Firmata) jep i agree they're the same - i think it's a matter of wrong denotation so due to my knowledge there's nothing like old and newer messages - the current 'contemporary' message for enabling the analog inputs is: [analogIns pinumber 1=on; 0=off( f.e. to enable analog pin 1: [analogIns 1 1( correct me if i'm wrong! i don't know why this is commented with (optional) I must have another version of the help patch, as I don't see such a comment right behind the [pd SWITCHING-INPUTS] is a comment - example of switching inputs on and off (optional) How are the messages you're talking about? i guess it's a firmata peculiarity that you've explicit have to enable the analog pins as in arduino they are enabled by default - but correct me if i'm wrong. Yes, I guess what you have to explicitly enable is to have the firmware _send_ the values to the computer. It would be undesirable to have a constant flood of values of all pins whether you use them or not. jep right so with firmata the analogIns have to be enabled explicitly to use them. i think the (optional) comment somehow makes it ambiguous. as told i'll try to consider this in the improvements we're working on! salutis ø -- ETs DNA will not be televised http://hasa-labs.org There is no way to peace, peace is the way. -A.J. Muste -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
yo bonitos due to the pduino rewrite I've to reanimate this threat ;) I would like to remove the ambiguity and confusion about this old and new way of enabling the analog pins. old way of enabling the analog 0 pin is sending the following to the arduino object: [analogIns 0 1( enabling the same pin(analog 0) the new school way: [pinMode 14 analog( is this correct? if so what's a bit byte confusing for people is that in the new way pin 14 equals the analog 0 pin - guess this is a peculiarity of firmata? isn't there a possability to use f.e. A0-A5 for adressing the analog pins? thanks for info salutis ø On 06/17/2011 10:52 AM, olsen wrote: On 06/17/2011 12:24 AM, Matteo Sisti Sette wrote: On 06/16/2011 05:44 PM, olsen wrote: it's all in the arduino-help.pd by Gerda Strobl and Georg Holzmann! Which one??? Not the one that is distributed together with [arduino] and [arduino-test] at http://at.or.at/hans/pd/objects.html, right? yo it's in Pduino-0.5beta8 linked on this page in the last subpatch [pd SWITCHING-INPUTS] you'll find the apropriate messages. There I find the same analogIns messages that are supposed to be the old ones (but are the only ones I've found that work for analog pins with the latest version of Firmata) jep i agree they're the same - i think it's a matter of wrong denotation so due to my knowledge there's nothing like old and newer messages - the current 'contemporary' message for enabling the analog inputs is: [analogIns pinumber 1=on; 0=off( f.e. to enable analog pin 1: [analogIns 1 1( correct me if i'm wrong! i don't know why this is commented with (optional) I must have another version of the help patch, as I don't see such a comment right behind the [pd SWITCHING-INPUTS] is a comment - example of switching inputs on and off (optional) How are the messages you're talking about? i guess it's a firmata peculiarity that you've explicit have to enable the analog pins as in arduino they are enabled by default - but correct me if i'm wrong. Yes, I guess what you have to explicitly enable is to have the firmware _send_ the values to the computer. It would be undesirable to have a constant flood of values of all pins whether you use them or not. jep right so with firmata the analogIns have to be enabled explicitly to use them. i think the (optional) comment somehow makes it ambiguous. as told i'll try to consider this in the improvements we're working on! salutis ø -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
That confusion originates from the Arduino numbering scheme itself, since it uses A0 for analog pins in analog mode, but then it uses a number when using the same pin for digital things. I think one way to represent this might be to allow the use of A0-A7 pin names in addition to the numbers, but then the confusing thing would be that the analog messages would then be [analog 14 0.2352(. So that's why I thought to try to use only the numbers, no A0-A7, and try to make that as understandable as possible. .hc On Nov 3, 2011, at 6:57 AM, olsen wrote: yo bonitos due to the pduino rewrite I've to reanimate this threat ;) I would like to remove the ambiguity and confusion about this old and new way of enabling the analog pins. old way of enabling the analog 0 pin is sending the following to the arduino object: [analogIns 0 1( enabling the same pin(analog 0) the new school way: [pinMode 14 analog( is this correct? if so what's a bit byte confusing for people is that in the new way pin 14 equals the analog 0 pin - guess this is a peculiarity of firmata? isn't there a possability to use f.e. A0-A5 for adressing the analog pins? thanks for info salutis ø On 06/17/2011 10:52 AM, olsen wrote: On 06/17/2011 12:24 AM, Matteo Sisti Sette wrote: On 06/16/2011 05:44 PM, olsen wrote: it's all in the arduino-help.pd by Gerda Strobl and Georg Holzmann! Which one??? Not the one that is distributed together with [arduino] and [arduino-test] at http://at.or.at/hans/pd/objects.html, right? yo it's in Pduino-0.5beta8 linked on this page in the last subpatch [pd SWITCHING-INPUTS] you'll find the apropriate messages. There I find the same analogIns messages that are supposed to be the old ones (but are the only ones I've found that work for analog pins with the latest version of Firmata) jep i agree they're the same - i think it's a matter of wrong denotation so due to my knowledge there's nothing like old and newer messages - the current 'contemporary' message for enabling the analog inputs is: [analogIns pinumber 1=on; 0=off( f.e. to enable analog pin 1: [analogIns 1 1( correct me if i'm wrong! i don't know why this is commented with (optional) I must have another version of the help patch, as I don't see such a comment right behind the [pd SWITCHING-INPUTS] is a comment - example of switching inputs on and off (optional) How are the messages you're talking about? i guess it's a firmata peculiarity that you've explicit have to enable the analog pins as in arduino they are enabled by default - but correct me if i'm wrong. Yes, I guess what you have to explicitly enable is to have the firmware _send_ the values to the computer. It would be undesirable to have a constant flood of values of all pins whether you use them or not. jep right so with firmata the analogIns have to be enabled explicitly to use them. i think the (optional) comment somehow makes it ambiguous. as told i'll try to consider this in the improvements we're working on! salutis ø -- ETs DNA will not be televised http://hasa-labs.org There is no way to peace, peace is the way. -A.J. Muste ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino/comport on osx powerpc freeze
Ej Hans Thanks for your reply. It works now - guess the computer arduino just needed some rest... best ø On Fri, Oct 28, 2011 at 1:10 AM, Hans-Christoph Steiner h...@at.or.at wrote: You might want to confirm that its not an electrical problem. Try another Arduino on that computer. If the Arduino shortcircuits, that shuts down the USB connection, which makes Pd crash. .hc On Thursday, October 27, 2011 6:19 PM, olsen sesselastron...@googlemail.com wrote: Buenas I'm currently giving a class using the pduino. One of the students has a Powerpc with OSX 10.04. As soon as he sends a message to the arduino/comport the patch freezes and pd has to be killed. The installed ftdi driver is the current one coming with arduino-022. Anyone experinced similar issues or has an idea how to solve this? thanks salutis ø -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ETs DNA will not be televised ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino/comport on osx powerpc freeze
Phew. Sounds like it was a short circuit on the arduino board setup. .hc On Oct 28, 2011, at 9:31 AM, olsen wolf wrote: Ej Hans Thanks for your reply. It works now - guess the computer arduino just needed some rest... best ø On Fri, Oct 28, 2011 at 1:10 AM, Hans-Christoph Steiner h...@at.or.at wrote: You might want to confirm that its not an electrical problem. Try another Arduino on that computer. If the Arduino shortcircuits, that shuts down the USB connection, which makes Pd crash. .hc On Thursday, October 27, 2011 6:19 PM, olsen sesselastron...@googlemail.com wrote: Buenas I'm currently giving a class using the pduino. One of the students has a Powerpc with OSX 10.04. As soon as he sends a message to the arduino/comport the patch freezes and pd has to be killed. The installed ftdi driver is the current one coming with arduino-022. Anyone experinced similar issues or has an idea how to solve this? thanks salutis ø -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list -- ETs DNA will not be televised Looking at things from a more basic level, you can come up with a more direct solution... It may sound small in theory, but it in practice, it can change entire economies. - Amy Smith ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] pduino/comport on osx powerpc freeze
Buenas I'm currently giving a class using the pduino. One of the students has a Powerpc with OSX 10.04. As soon as he sends a message to the arduino/comport the patch freezes and pd has to be killed. The installed ftdi driver is the current one coming with arduino-022. Anyone experinced similar issues or has an idea how to solve this? thanks salutis ø -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino/comport on osx powerpc freeze
You might want to confirm that its not an electrical problem. Try another Arduino on that computer. If the Arduino shortcircuits, that shuts down the USB connection, which makes Pd crash. .hc On Thursday, October 27, 2011 6:19 PM, olsen sesselastron...@googlemail.com wrote: Buenas I'm currently giving a class using the pduino. One of the students has a Powerpc with OSX 10.04. As soon as he sends a message to the arduino/comport the patch freezes and pd has to be killed. The installed ftdi driver is the current one coming with arduino-022. Anyone experinced similar issues or has an idea how to solve this? thanks salutis ø -- ETs DNA will not be televised http://hasa-labs.org ___ 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
Re: [PD] pduino rewrite
Wow, I just compared your version of [pd digital message] with mine and yours takes only 180ms to process 100 of messages, while mine uses over 8s. Frankly, I wouldn't have expected such a big difference Let me dig into this. Roman On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [ 4] and [ 2] shouldn't take more than a minute. The main difference to Romans approach is that it uses more fixed code to end up doing less when actually working. BTW I think Romans approach makes generally more sense for most cases since it is scalable and does not need any different code for any number of pins (up to 128 in the current version) which makes it much simpler to use. I have attached a patch that shows the difference between the two debyte methods. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I was told that it is. Bit shifting and bit mask matching is supposed to be faster than integer division and modulo with an arbitrary (inclusive non-power-of-two integers). However, I can't tell you whether they are really faster in the real world. But you should be able to test it in your own setup with [realtime]. Start [realtime], let [mod 8]-[div 4] process 1 million numbers in 0 logical time, stop [realtime]. Do the same with a [ 4]-[ 2] chain and compare the results. I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [ 4] and [ 2] shouldn't take more than a minute. You could also test the whole [pd digital message] subpatch with the above mentioned approach. Frankly, I'm not yet convinced that those little improvements in [arduino] will significantly improve the overall Pd performance. Using one less tilde object somewhere in your patch would save some order of magnitudes of CPU power more of what you ever will be able to squeeze out of the [arduino]. Message processing is usually so cheap compared to signal processing, that most often it's hardly worth to focus on the message processing part, unless you deal with message rates of several thousands per second. This is certainly not always true, but in my own experience it most often is. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Fri, 2011-09-16 at 11:32 +0200, Roman Haefeli wrote: On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I was told that it is. Bit shifting and bit mask matching is supposed to be faster than integer division and modulo with an arbitrary (inclusive non-power-of-two integers). It turns out that difference is not significant. On my box, processing 100 floats takes ~160ms ([mod],[div]) vs. ~150 ([],[]). Probably all the message parsing overhead is consuming more than the actual computation of the numbers. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Wow, I just compared your version of [pd digital message] with mine and yours takes only 180ms to process 100 of messages, while mine uses over 8s. Frankly, I wouldn't have expected such a big difference Let me dig into this. Roman That's more than I would have expected, too! I would have been guessing it could be up to 10x as fast but not 50x. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Roman, Frankly, I'm not yet convinced that those little improvements in [arduino] will significantly improve the overall Pd performance. Here's the reason why I started really to simplify any patch, no matter if audio or control objects: I have been programming for about 4 years on one single patch (fulltime - only with breaks to get the hardware/OS going and sampling/editing sampled instruments). You can imagine the amount of code that is in the patch by now. When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). At a certain point (about 2 years ago) the machine was completely overloaded! Then I measured that a EWI-USB wind controller can send up to 500 midi CC messages per second. I had a function that could multiply the messages to six different midi channels. That makes it 3,000 messages floating around. The sample voices have at least 500 [receive] objects (there are close to 500 parameters per voice). There were 16 voices which adds up to 8,000 [receive] objects. Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. That should be as much data shifting around only for checking [receive] objects as it would take to move the data of several hundreds of audio channels around. The first fix was easy: assigning the parameter to receive from midi Ch01 if voices are stacked. That cut the message transfer by 6. The second fix was to replace the wireless sends with hard wired patch chords. That took care of most of the rest. The machine was working again. Unfortunately this second fix took 3-4 full months!!! This is when I decided to think about efficiency in running mode first. If you have a piece of code that has to check between 10 different options and in a certain case only two options are available then it is worth it copying the object and take out all unnecessary options. It's more work while programming but it saves in this particular example several hundred percent cpu time when running. When such a programming style is used consistently I am sure you can get at least double or more of the performance of a computer. Even with messages where you would think they are not too heavy. Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 16. September 2011 11:32 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@iem.at Betreff: Re: AW: AW: AW: [PD] pduino rewrite On Fri, 2011-09-16 at 05:57 +0200, Ingo wrote: The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I was told that it is. Bit shifting and bit mask matching is supposed to be faster than integer division and modulo with an arbitrary (inclusive non-power-of-two integers). However, I can't tell you whether they are really faster in the real world. But you should be able to test it in your own setup with [realtime]. Start [realtime], let [mod 8]-[div 4] process 1 million numbers in 0 logical time, stop [realtime]. Do the same with a [ 4]-[ 2] chain and compare the results. I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [ 4] and [ 2] shouldn't take more than a minute. You could also test the whole [pd digital message] subpatch with the above mentioned approach. Frankly, I'm not yet convinced that those little improvements in [arduino] will significantly improve the overall Pd performance. Using one less tilde object somewhere in your patch would save some order of magnitudes of CPU power more of what you ever will be able to squeeze out of the [arduino]. Message processing is usually so cheap compared to signal processing, that most often it's hardly worth to focus
Re: [PD] pduino rewrite
To make sure boards that are larger than 56 digital in pins you should copy a couple more of these objects to go up to 128. Of course since [] and [] seems to be slightly faster that would be the choice. To be even more efficient the object [pd route digital/analog] should be bypassed by adding the addresses [144 145 146 ... 151] to the route object inside the parent patch making it [route 249 240 144 145 146 147 148 149 150 151]. The last outlet goes into [pd route digital/analog]. The [route 0 1 2 3 4 5 6 7] inside the [pd digital messages] should be replace by 8 individual inlets. BTW you could keep going on with this forever ... All I wanted originally was to get the correct messages coming out of the patch ... Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 16. September 2011 14:44 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@iem.at Betreff: Re: AW: AW: AW: AW: [PD] pduino rewrite On Fri, 2011-09-16 at 14:05 +0200, Ingo wrote: Wow, I just compared your version of [pd digital message] with mine and yours takes only 180ms to process 100 of messages, while mine uses over 8s. Frankly, I wouldn't have expected such a big difference Let me dig into this. Roman That's more than I would have expected, too! I would have been guessing it could be up to 10x as fast but not 50x. I think I'm going to put your much more efficient version into the git version. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Ingo, On 16/09/11 13:02, Ingo wrote: When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). [snip] Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. [snip] The second fix was to replace the wireless sends with hard wired patch chords. Faced with this scenario I would probably have tried dynamic sends, so the data determines which receive gets the message. For example: ... | [pack f f f f f f] | [ ; r-$1-$2-$3 $4 $5 $6 ( [r r-1-4-7] | [unpack f f f] | ... [r r-27-63-49] | [unpack f f f] | And using nested abstractions you could create the receives based on $args, and if you need lots of voices you could use dynamic patching to instantiate them. Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Claude, When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). [snip] Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. [snip] The second fix was to replace the wireless sends with hard wired patch chords. Faced with this scenario I would probably have tried dynamic sends, so the data determines which receive gets the message. For example: ... | [pack f f f f f f] | [ ; r-$1-$2-$3 $4 $5 $6 ( [r r-1-4-7] | [unpack f f f] | ... [r r-27-63-49] | [unpack f f f] | That would imply that you know which midi CC message gets there when since the left inlet of [pack] needs to be banged. Or it would be delayed until the left inlet receives a new message (if at all). Or you would have to bang the left inlet every time another one comes in. That would even multiply the data transfer. Last solution would be a fixed send timing every couple of milliseconds. That would multiply the average data transfer and lower the timing resolution. And using nested abstractions you could create the receives based on $args $args have to listen to all sent messages also. You are simply expanding the name with the $arg. When you have 10 voices all [receive]s of all 10 voices will have to listen for every [send] message to determine whether it is for them or not. Doesn't matter if the name starts with $0-. and if you need lots of voices you could use dynamic patching to instantiate them. To initialize sample-voices like the ones I am using Pd takes about ten seconds. If you want to play a piano chord that has one note more than current voices are present you don't really want to wait 10 seconds, do you? And afterwards are you going to erase that voice again? This would again interrupt the audio stream. Anyway audio calculation can be turned off with the [switch~] object. [receive] objects cannot be made inactive ever. The only way to do this would be to split up the voices over several independent patches which communicate over [netsend/netreceive] or [osc]. This makes audio communication very difficult and it would be very hard to keep all of those thousands of tables updated in all patches. It's just simply more efficient to address the data directly by wired connections only to the destination that needs the data. Looks messy but works better! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Actually, packing an id before the actual data and using a route object to distribute all separate destinations from one single [receive] - [route] - parameters would do the trick. Maybe that's what you meant? I just cannot picture a [route] object with up to 500 outlets, yet. But there might be ways to organize it using a small number of [receive] and a small number of [route] and sub-[route] objects. However, it would take just as much time to rewrite an existing patch like this as it takes to hardwire the sends. I still think that these considerations need to be made when starting to write any kind of code because problems only start showing up when it's almost too late. Once the patch gets kinda huge fixing will become very time consuming. Optimizing any code to the least amount of parsing data/messages around is the key for doing any complex patches. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Freitag, 16. September 2011 16:42 An: 'Claude Heiland-Allen'; pd-list@iem.at Betreff: Re: [PD] pduino rewrite Hi Claude, When I started I thought it was very convenient to use wireless [send/receive] objects to send midi data to the sample-voices (which it is). [snip] Sending 3,000 messages to 8,000 [receive] objects adds up to 24 million times per second that the individual [receive] objects had to check whether the message was meant to be for them or not. [snip] The second fix was to replace the wireless sends with hard wired patch chords. Faced with this scenario I would probably have tried dynamic sends, so the data determines which receive gets the message. For example: ... | [pack f f f f f f] | [ ; r-$1-$2-$3 $4 $5 $6 ( [r r-1-4-7] | [unpack f f f] | ... [r r-27-63-49] | [unpack f f f] | That would imply that you know which midi CC message gets there when since the left inlet of [pack] needs to be banged. Or it would be delayed until the left inlet receives a new message (if at all). Or you would have to bang the left inlet every time another one comes in. That would even multiply the data transfer. Last solution would be a fixed send timing every couple of milliseconds. That would multiply the average data transfer and lower the timing resolution. And using nested abstractions you could create the receives based on $args $args have to listen to all sent messages also. You are simply expanding the name with the $arg. When you have 10 voices all [receive]s of all 10 voices will have to listen for every [send] message to determine whether it is for them or not. Doesn't matter if the name starts with $0-. and if you need lots of voices you could use dynamic patching to instantiate them. To initialize sample-voices like the ones I am using Pd takes about ten seconds. If you want to play a piano chord that has one note more than current voices are present you don't really want to wait 10 seconds, do you? And afterwards are you going to erase that voice again? This would again interrupt the audio stream. Anyway audio calculation can be turned off with the [switch~] object. [receive] objects cannot be made inactive ever. The only way to do this would be to split up the voices over several independent patches which communicate over [netsend/netreceive] or [osc]. This makes audio communication very difficult and it would be very hard to keep all of those thousands of tables updated in all patches. It's just simply more efficient to address the data directly by wired connections only to the destination that needs the data. Looks messy but works better! Ingo ___ 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
Re: [PD] pduino rewrite
Hi Ingo Thanks for testing! On Thu, 2011-09-15 at 05:23 +0200, Ingo wrote: Hi Roman, the new version works great! I'm glad to hear that. I made myself some testing objects around it. Maybe that could be useful if you guys ever get around fixing the help patch. I'll have a look. Thanks. I still think the version using individual debyte masks is far more efficient than this one. But as you pointed out this one is more scalable and might take care of boards coming in the future (I have just seen a mega clone with 70 or 72 digital inputs). Most people don't use incremental wheels timed to 1-2 ms - like I do - anyway. So efficiency shouldn't matter in 99.9% of the cases. I generally think it does matter. However, i don't have any concerns that the additional table look up causes an efficiency problem. Table lookups are usually very fast. It's probably a matter of taste, but I often find myself looking for an 'algorithmic' solution instead of copying very similar code several times around, even if the former is a bit less efficient than the latter. In this case, if using several [pd debytemask], it'd be nice to use an abstraction instead. However, if the original [mapping/debytemask] would be used, every (-1) instance would require a row of 8 [+ 8] objects, [+ 16], [+ 24], etc. respectively. So it would either end up with a lot of additional objects below all [debytemask] instances or multiple manually crafted [pd debytemask] with each containing slightly different code (as you implemented it) would be required. The additional [pd polychange] with table lookup is made of just a handful of objects. However, if it ever turns out, that in your setup the [arduino] abstraction eats a significant amount of CPU power (what I really doubt), I'll happily replace it by your version of [pd digital messages] if it helps. And yes, the goal should be to cover also 'edge' cases like your incremental wheel. The more use cases work well with Firmata / [arduino] the better. Roman -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Hans-Christoph Steiner Gesendet: Mittwoch, 14. September 2011 22:33 An: Roman Haefeli Cc: pd-list@iem.at Betreff: Re: [PD] pduino rewrite As Ingo pointed out, one bug is that [mapping/debytemask] has the [change] object for each outlet. So probably the way to fix this is to make a bunch of [mapping/debytemask] objects for all the possible digital ports. [arduino] should only output on change of digital input, and it receives the digital information one byte/port at a time, i.e. 8 pins. Another approach would be to have an array of all of the previous values which are then compared to the current before outputting. .hc On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote: Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered, which is under all circumstances only triggered once after all the [pd debytemask] messages have fired. Actually, the order should be inversed, so that all messages from [pd debytemask] go the _left_ inlet of [+ ], and the summand is sent the _right_ inlet before. This is what I did in the patch you find attached. I rather have my version going into [arduino], since it is much less code than yours. From what I can tell, they both produce similar output, but as I said, I haven't had the chance to test it in real-world circumstances with a real arduino. So, please test and report back. I guess the main reason nobody (including me) has noticed this bug yet, is that you won't trigger it, if you only test one digital in at once. Changing the state of only one input at a time makes it seem, that all inputs work correctly. Only when changing states of several inputs at the same time, you will receive only a single digital messages, which is obviously wrong. I'm happy now that you kept bugging about this. It took me a while to (hopefully) understand the problem. Thanks for your persistence. *) There is no [debytemask] abstraction
Re: [PD] pduino rewrite
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? Anyway what can be done is add a simple offset number like I did it somewhere on my testing patch. Then you can copy as many instances as needed and offset them. Maybe multiplying by 8 first. But then again it's more objects and calculations than are really necessary. I am using it like this with only two objects for the Duemilanove. Your version with the table has 59 objects while my duplicated version has 73 objects for a Duemilanove while needing a lot less calculations, a fraction of the message transfers and no table lookups or writes. But as I had mentioned - I doubt that efficiency will play a role in just about any case for the arduino's digital pins. Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Donnerstag, 15. September 2011 08:44 An: Ingo Cc: 'Hans-Christoph Steiner'; pd-list@iem.at Betreff: Re: AW: [PD] pduino rewrite Hi Ingo Thanks for testing! On Thu, 2011-09-15 at 05:23 +0200, Ingo wrote: Hi Roman, the new version works great! I'm glad to hear that. I made myself some testing objects around it. Maybe that could be useful if you guys ever get around fixing the help patch. I'll have a look. Thanks. I still think the version using individual debyte masks is far more efficient than this one. But as you pointed out this one is more scalable and might take care of boards coming in the future (I have just seen a mega clone with 70 or 72 digital inputs). Most people don't use incremental wheels timed to 1-2 ms - like I do - anyway. So efficiency shouldn't matter in 99.9% of the cases. I generally think it does matter. However, i don't have any concerns that the additional table look up causes an efficiency problem. Table lookups are usually very fast. It's probably a matter of taste, but I often find myself looking for an 'algorithmic' solution instead of copying very similar code several times around, even if the former is a bit less efficient than the latter. In this case, if using several [pd debytemask], it'd be nice to use an abstraction instead. However, if the original [mapping/debytemask] would be used, every (-1) instance would require a row of 8 [+ 8] objects, [+ 16], [+ 24], etc. respectively. So it would either end up with a lot of additional objects below all [debytemask] instances or multiple manually crafted [pd debytemask] with each containing slightly different code (as you implemented it) would be required. The additional [pd polychange] with table lookup is made of just a handful of objects. However, if it ever turns out, that in your setup the [arduino] abstraction eats a significant amount of CPU power (what I really doubt), I'll happily replace it by your version of [pd digital messages] if it helps. And yes, the goal should be to cover also 'edge' cases like your incremental wheel. The more use cases work well with Firmata / [arduino] the better. Roman -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Hans-Christoph Steiner Gesendet: Mittwoch, 14. September 2011 22:33 An: Roman Haefeli Cc: pd-list@iem.at Betreff: Re: [PD] pduino rewrite As Ingo pointed out, one bug is that [mapping/debytemask] has the [change] object for each outlet. So probably the way to fix this is to make a bunch of [mapping/debytemask] objects for all the possible digital ports. [arduino] should only output on change of digital input, and it receives the digital information one byte/port at a time, i.e. 8 pins. Another approach would be to have an array of all of the previous values which are then compared to the current before outputting. .hc On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote: Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered
Re: [PD] pduino rewrite
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. Anyway what can be done is add a simple offset number like I did it somewhere on my testing patch. Then you can copy as many instances as needed and offset them. Maybe multiplying by 8 first. But then again it's more objects and calculations than are really necessary. I am using it like this with only two objects for the Duemilanove. Your version with the table has 59 objects while my duplicated version has 73 objects for a Duemilanove while needing a lot less calculations, a fraction of the message transfers and no table lookups or writes. Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
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. .hc Anyway what can be done is add a simple offset number like I did it somewhere on my testing patch. Then you can copy as many instances as needed and offset them. Maybe multiplying by 8 first. But then again it's more objects and calculations than are really necessary. I am using it like this with only two objects for the Duemilanove. Your version with the table has 59 objects while my duplicated version has 73 objects for a Duemilanove while needing a lot less calculations, a fraction of the message transfers and no table lookups or writes. Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 10:20 +0200, Ingo wrote: Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo If you want efficiency in this object, you should implement it in C. That should not be hard to do since the Firmata code is C++, but coded mostly in a C style. So you can get all of the parsing and message generating code from Firmata.cpp and StandardFirmata.pde, and make a compiled object out of it. And Ingo, if you implement a fixed the [debytemask] approach, I'll included it in the Pduino arduino.pd. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
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. 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. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Hans, unfortunately I am not really good at C or C++ so I have to stick with simplifying within Pd until I get there. But I am actually working on it so I'll be able to replace certain objects in my patches by more efficient externals. Anyway, I think in the case of simplifying the pduino patch another external would be rather contra productive. The optimized multiple debytemasks (up to 56 input pins) as a Pd-patch are attached. I just called it differently because this was taken from an old display keypad patch that I had done before. I am using this in my remote control unit and it's working perfectly. Ingo -Ursprüngliche Nachricht- Von: Hans-Christoph Steiner [mailto:h...@at.or.at] Gesendet: Donnerstag, 15. September 2011 17:48 An: Ingo Cc: 'Roman Haefeli'; pd-list@iem.at Betreff: Re: AW: [PD] pduino rewrite On Thu, 2011-09-15 at 10:20 +0200, Ingo wrote: Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo If you want efficiency in this object, you should implement it in C. That should not be hard to do since the Firmata code is C++, but coded mostly in a C style. So you can get all of the parsing and message generating code from Firmata.cpp and StandardFirmata.pde, and make a compiled object out of it. And Ingo, if you implement a fixed the [debytemask] approach, I'll included it in the Pduino arduino.pd. .hc #N canvas 504 92 321 208 10; #N canvas 606 345 294 266 digital_messages 1; #X obj 43 16 inlet; #X obj 43 237 outlet; #X obj 43 43 route 0 1 2 3 4 5 6; #N canvas 1386 0 534 360 resolve-bits_32-39 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 32 \$1; #X msg 80 216 digital 33 \$1; #X msg 140 196 digital 34 \$1; #X msg 200 216 digital 35 \$1; #X msg 260 196 digital 36 \$1; #X msg 320 216 digital 37 \$1; #X msg 380 196 digital 38 \$1; #X msg 440 216 digital 39 \$1; #X obj 440 129 mod 256; #X connect 0 0 24 0; #X connect 2 0 15 0; #X connect 3 0 14 0; #X connect 4 0 13 0; #X connect 5 0 12 0; #X connect 6 0 11 0; #X connect 7 0 9 0; #X connect 8 0 16 0; #X connect 9 0 17 0; #X connect 10 0 23 0; #X connect 11 0 18 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 25 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 2 0; #X connect 24 0 3 0; #X connect 24 0 4 0; #X connect 24 0 5 0; #X connect 24 0 6 0; #X connect 24 0 8 0; #X connect 24 0 7 0; #X connect 24 0 33 0; #X connect 25 0 1 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 10 0; #X restore 106 150 pd resolve-bits_32-39; #N canvas 1386 0 534 360 resolve-bits_0-7 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169
Re: [PD] pduino rewrite
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. 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. Another good reason is that there are useful bits of code developed while writing the arduino.pd object, why not share them as objects? .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 18:54 +0200, Ingo wrote: Hi Hans, unfortunately I am not really good at C or C++ so I have to stick with simplifying within Pd until I get there. But I am actually working on it so I'll be able to replace certain objects in my patches by more efficient externals. Anyway, I think in the case of simplifying the pduino patch another external would be rather contra productive. Makes sense, I think having it as a Pd abstraction is good too, I did write it that way rather than in C :) I was just saying that C would be more efficient. The optimized multiple debytemasks (up to 56 input pins) as a Pd-patch are attached. I just called it differently because this was taken from an old display keypad patch that I had done before. I am using this in my remote control unit and it's working perfectly. The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Ingo -Ursprüngliche Nachricht- Von: Hans-Christoph Steiner [mailto:h...@at.or.at] Gesendet: Donnerstag, 15. September 2011 17:48 An: Ingo Cc: 'Roman Haefeli'; pd-list@iem.at Betreff: Re: AW: [PD] pduino rewrite On Thu, 2011-09-15 at 10:20 +0200, Ingo wrote: Interesting. How did you quantify the amount of message transfers? What makes it differ so much, like you say? I simply (roughly) counted the numbers of objects the calculation including all sub processes have to pass until you get the final result. (Unfortunately I cannot tell how heavy each of these calculations is compared to another one.) I started this a while ago since I am running my machines always at the very limit that they can handle. Which is why I started cutting down the number of processes needed to get something done wherever possible. Saving 20% of the calculations in a machine that's at the limit can make quite a difference. Of course it's the audio processes that are heavier than the control processes. I remember a discussion here a while ago about how heavy the actual message transfer is. So keeping calculations as simple and straight forward all of the time will keep the machines from getting overloaded earlier than necessary. Which again reminds me that I have to redo lots of old stuff for efficiency - never ending story! Ingo If you want efficiency in this object, you should implement it in C. That should not be hard to do since the Firmata code is C++, but coded mostly in a C style. So you can get all of the parsing and message generating code from Firmata.cpp and StandardFirmata.pde, and make a compiled object out of it. And Ingo, if you implement a fixed the [debytemask] approach, I'll included it in the Pduino arduino.pd. .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
On Thu, 2011-09-15 at 13:29 -0400, Hans-Christoph Steiner wrote: On Thu, 2011-09-15 at 18:54 +0200, Ingo wrote: Hi Hans, unfortunately I am not really good at C or C++ so I have to stick with simplifying within Pd until I get there. But I am actually working on it so I'll be able to replace certain objects in my patches by more efficient externals. Anyway, I think in the case of simplifying the pduino patch another external would be rather contra productive. Makes sense, I think having it as a Pd abstraction is good too, I did write it that way rather than in C :) I was just saying that C would be more efficient. The optimized multiple debytemasks (up to 56 input pins) as a Pd-patch are attached. I just called it differently because this was taken from an old display keypad patch that I had done before. I am using this in my remote control unit and it's working perfectly. The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. But then you need a row of [+ 8] ([+ 16], [+ 24]) for each instance of debytemask. So, it's still tedious work, whether you're using an abstraction or copies of the subpatch. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
The [change -1] is a great idea, I just committed that to bytemask.pd and debytemask.pd. But the [pd resolve-bits_0-7] abstractions seem quite labor-intensive, but they work. I think it would work better to use multiple instances of [debytemask]. .hc Not sure what you mean by labor-intensive, Hans. Are you talking about manually changing 8 numbers per object (which took me less than 1 minute for 56 channels) or are you talking about cpu processing? Which leads me to the next question: is the Boolean approach using [ 4] and [ 2] more cpu friendly than using [mod 8] and [div 4]? I don't know how Pd handles such calculations and how it talks to the cpu. I'd be really very interested to find out if there is a difference. Since the pin numbers are predefined when you are using a [route] object to sort out the groups I don't see the point why the pin number should be calculated again (in this case of multiple instances). This is why I hardcoded them into the message boxes. I put the two approaches next to each other to see how much simpler my approach is object wise and calculation wise. Still with the question mark which calculation method is more cpu friendly. Anyway changing [mod 8] and [div 4] to [ 4] and [ 2] shouldn't take more than a minute. The main difference to Romans approach is that it uses more fixed code to end up doing less when actually working. BTW I think Romans approach makes generally more sense for most cases since it is scalable and does not need any different code for any number of pins (up to 128 in the current version) which makes it much simpler to use. I have attached a patch that shows the difference between the two debyte methods. Ingo #N canvas 317 0 1025 801 10; #X obj 238 619 cnv 15 370 140 empty empty empty 20 12 0 14 -262130 -66577 0; #X floatatom 253 633 5 0 255 0 - - -; #X floatatom 253 685 5 0 0 0 - - -; #X floatatom 303 685 5 0 0 0 - - -; #X floatatom 253 731 5 0 0 0 - - -; #X floatatom 303 731 5 0 0 0 - - -; #X obj 253 665 mod 8; #X obj 253 704 div 4; #X obj 303 665 4; #X obj 303 705 2; #X text 362 628 Question:; #X obj 540 79 cnv 15 350 100 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 659 376 cnv 15 170 180 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 190 582 outlet; #X obj 190 55 route 0 1 2 3 4 5 6; #X obj 190 28 inlet; #X obj 690 495 +; #X msg 690 535 digital \$1 \$2; #X obj 690 515 pack float float; #X obj 690 378 unpack float float; #X obj 690 82 t a a; #X msg 717 102 \$1; #X msg 690 102 \$2; #X obj 690 55 route 0 1 2 3 4 5 6; #X obj 690 28 inlet; #X obj 550 159 trigger float float float float float float float float ; #X obj 690 582 outlet; #X obj 659 619 cnv 15 170 140 empty empty empty 20 12 0 14 -232576 -66577 0; #X text 668 663 There is no need to; #X obj 959 193 cnv 15 50 50 empty empty empty 20 12 0 14 -232576 -66577 0; #X obj 972 199 15; #X obj 972 220 * 8; #X text 668 726 selects this pin group.; #X text 668 711 The route object already; #X text 362 648 is the 1st calculation using [mod] and; #X text 362 663 [div] heavier on cpu cycles than [ 4]; #X text 362 678 and [ 2] due to different processor; #X text 362 693 instructions?; #X text 687 6 debyte; #X text 668 691 defined by the firmata.; #X text 668 676 calculate the pin number; #X text 668 628 The objects marked here; #X text 668 643 are not necessary.; #X obj 336 722 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 336 682 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 4 188 cnv 15 920 120 empty empty empty 20 12 0 14 -233017 -66577 0; #X obj 370 206 mod 128; #X obj 310 206 mod 64; #X obj 250 206 mod 32; #X obj 190 206 mod 16; #X obj 130 206 mod 8; #X obj 70 206 mod 4; #X obj 10 206 mod 2; #X obj 70 226 div 2; #X obj 430 226 div 128; #X obj 130 226 div 4; #X obj 190 226 div 8; #X obj 250 226 div 16; #X obj 310 226 div 32; #X obj 370 226 div 64; #X obj 10 246 change -1; #X obj 70 246 change -1; #X obj 130 246 change -1; #X obj 190 246 change -1; #X obj 250 246 change -1; #X obj 310 246 change -1; #X obj 370 246 change -1; #X obj 430 246 change -1; #X msg 10 266 digital 0 \$1; #X msg 70 286 digital 1 \$1; #X msg 130 266 digital 2 \$1; #X msg 190 286 digital 3 \$1; #X msg 250 266 digital 4 \$1; #X msg 310 286 digital 5 \$1; #X msg 370 266 digital 6 \$1; #X msg 430 286 digital 7 \$1; #X obj 430 206 mod 256; #X msg 550 264 0 \$1; #X msg 596 284 1 \$1; #X msg 643 265 2 \$1; #X msg 690 284 3 \$1; #X msg 736 266 4 \$1; #X msg 783 284 5 \$1; #X msg 830 267 6 \$1; #X msg 877 284 7 \$1; #X obj 550 206 1; #X obj 596 205 2; #X obj 643 205 4; #X obj 690 205 8; #X obj 736 205 16; #X obj 783 205 32; #X obj 830 205 64; #X obj 877 205 128; #X obj 596 225 1; #X obj 643 225 2; #X obj 690 225 3; #X obj 736 225 4; #X obj 783 225 5; #X obj 830 225 6; #X obj 877 225 7; #X obj 550 244 change; #X obj 596 245 change; #X obj 643 245 change; #X obj 690 245 change; #X obj 736 246 change; #X obj 783 247 change; #X obj 830 247 change; #X obj 877
Re: [PD] pduino rewrite
Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered, which is under all circumstances only triggered once after all the [pd debytemask] messages have fired. Actually, the order should be inversed, so that all messages from [pd debytemask] go the _left_ inlet of [+ ], and the summand is sent the _right_ inlet before. This is what I did in the patch you find attached. I rather have my version going into [arduino], since it is much less code than yours. From what I can tell, they both produce similar output, but as I said, I haven't had the chance to test it in real-world circumstances with a real arduino. So, please test and report back. I guess the main reason nobody (including me) has noticed this bug yet, is that you won't trigger it, if you only test one digital in at once. Changing the state of only one input at a time makes it seem, that all inputs work correctly. Only when changing states of several inputs at the same time, you will receive only a single digital messages, which is obviously wrong. I'm happy now that you kept bugging about this. It took me a while to (hopefully) understand the problem. Thanks for your persistence. *) There is no [debytemask] abstraction anymore in the git version of [arduino]. I replaced it by a subpatch. Roman On Sun, 2011-09-11 at 06:20 +0200, Ingo wrote: There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed is bug for over two years! #N canvas 490 1631 331 170 10; #N canvas 571 1511 538 392 digital 0; #X obj 58 3 inlet; #X obj 58 286 outlet; #X msg 58 113 0 \$1; #X msg 96 113 1 \$1; #X msg 134 113 2 \$1; #X msg 172 113 3 \$1; #X msg 210 113 4 \$1; #X msg 248 113 5 \$1; #X msg 286 113 6 \$1; #X msg 328 113 7 \$1; #X obj 58 208 +; #X obj 394 106 15; #X msg 58 261 digital \$1 \$2; #X obj 394 127 * 8; #X obj 58 230 pack float float; #X obj 58 163 unpack float float; #N canvas 0 69 450 300 debytemask 0; #X obj 32 140 1; #X obj 82 139 2; #X obj 132 139 4; #X obj 182 139 8; #X obj 232 139 16; #X obj 282 139 32; #X obj 332 139 64; #X obj 382 139 128; #X obj 32 220 outlet; #X obj 82 220 outlet; #X obj 132 220 outlet; #X obj 182 220 outlet; #X obj 232 220 outlet; #X obj 282 220 outlet; #X obj 332 220 outlet; #X obj 382 220 outlet; #X obj 32 76 trigger float float float float float float float float ; #X obj 32 32 inlet; #X obj 82 160 1; #X obj 132 160 2; #X obj 182 160 3; #X obj 232 160 4; #X obj 282 160 5; #X obj 332 160 6; #X obj 382 160 7; #X obj 32 186 change; #X obj 82 187 change; #X obj 132 187 change; #X obj 182 187 change; #X obj 232 188 change; #X obj 282 189 change; #X obj 332 189 change; #X obj 382 189 change; #X connect 0 0 25 0; #X connect 1 0 18 0; #X connect 2 0 19 0; #X connect 3 0 20 0; #X connect 4 0 21 0; #X connect 5 0 22 0; #X connect 6 0 23 0; #X connect 7 0 24 0; #X connect 16 0 0 0; #X connect 16 1 1 0; #X connect 16 2 2 0; #X connect 16 3 3 0; #X connect 16 4 4 0; #X connect 16 5 5 0; #X connect 16 6 6 0; #X connect 16 7 7 0; #X connect 17 0 16 0; #X connect 18 0 26 0; #X connect 19 0 27 0; #X connect 20 0 28 0; #X connect 21 0 29 0; #X connect 22 0 30 0; #X connect 23 0 31 0; #X connect 24 0 32 0; #X connect 25 0 8 0; #X connect 26 0 9
Re: [PD] pduino rewrite
On Wed, 2011-09-14 at 11:48 +0200, Ingo wrote: Hi Roman, thanks for taking the time looking at the code. Unfortunately your version will be sending even many more wrong numbers. I have put some list messages into your patch. Keep clicking onto them randomly and you will see that the headers change between 6, 7, 14 and 15. Sometimes they are correct - sometimes not. The problem is due to the change object inside the debyte object. Leaving it out would always send all 8 bits for the group of pins. Leaving it in will keep holding old values. Gotcha. I removed the [change] objects from the [pd debytemask] subpatch. And I also agree, that it would be ugly, if digital pins fire without changing their state. I cannot see any way other than using individual debyte objects for each group unless you would come up with something completely different like storing everything into an array and sending from there (after checking what has changed) which would be much more complicated. Actually, I found the table based approach not that complicated and I think it is more scalable (it covers all possible 16 groups). I added a [pd polychange] subpatch that does exactly what you describe. I hopefully tested it more thoroughly this time. See attached patch. Cheers Roman #N canvas 0 53 450 300 10; #N canvas 179 119 538 392 digital 0; #X obj 42 17 inlet; #X obj 42 334 outlet; #X msg 42 120 0 \$1; #X msg 80 120 1 \$1; #X msg 118 120 2 \$1; #X msg 156 120 3 \$1; #X msg 194 120 4 \$1; #X msg 232 120 5 \$1; #X msg 270 120 6 \$1; #X msg 312 120 7 \$1; #X obj 42 215 +; #X obj 378 113 15; #X msg 42 310 digital \$1 \$2; #X obj 378 134 * 8; #X obj 42 237 pack float float; #X obj 42 170 unpack float float; #N canvas 289 142 450 300 debytemask 0; #X obj 32 140 1; #X obj 82 139 2; #X obj 132 139 4; #X obj 182 139 8; #X obj 232 139 16; #X obj 282 139 32; #X obj 332 139 64; #X obj 382 139 128; #X obj 32 220 outlet; #X obj 82 220 outlet; #X obj 132 220 outlet; #X obj 182 220 outlet; #X obj 232 220 outlet; #X obj 282 220 outlet; #X obj 332 220 outlet; #X obj 382 220 outlet; #X obj 32 76 trigger float float float float float float float float ; #X obj 32 32 inlet; #X obj 82 160 1; #X obj 132 160 2; #X obj 182 160 3; #X obj 232 160 4; #X obj 282 160 5; #X obj 332 160 6; #X obj 382 160 7; #X connect 0 0 8 0; #X connect 1 0 18 0; #X connect 2 0 19 0; #X connect 3 0 20 0; #X connect 4 0 21 0; #X connect 5 0 22 0; #X connect 6 0 23 0; #X connect 7 0 24 0; #X connect 16 0 0 0; #X connect 16 1 1 0; #X connect 16 2 2 0; #X connect 16 3 3 0; #X connect 16 4 4 0; #X connect 16 5 5 0; #X connect 16 6 6 0; #X connect 16 7 7 0; #X connect 17 0 16 0; #X connect 18 0 9 0; #X connect 19 0 10 0; #X connect 20 0 11 0; #X connect 21 0 12 0; #X connect 22 0 13 0; #X connect 23 0 14 0; #X connect 24 0 15 0; #X restore 42 85 pd debytemask; #X obj 42 38 t a a; #X msg 69 60 \$1; #X msg 42 60 \$2; #N canvas 315 128 443 301 polychange 0; #X obj 23 20 inlet; #X obj 23 242 outlet; #X obj 236 12 table \$0.digital.in.cache 128; #X obj 23 87 tabread \$0.digital.in.cache; #X obj 23 64 unpack f f; #X obj 23 109 !=; #X obj 23 131 sel 1; #X obj 23 42 t a a; #X obj 23 153 list append; #X obj 83 242 tabwrite \$0.digital.in.cache; #X obj 23 175 t a a a; #X msg 248 215 \$1; #X msg 83 213 \$2; #X connect 0 0 7 0; #X connect 3 0 5 0; #X connect 4 0 3 0; #X connect 4 1 5 1; #X connect 5 0 6 0; #X connect 6 0 8 0; #X connect 7 0 4 0; #X connect 7 1 8 1; #X connect 8 0 10 0; #X connect 10 0 1 0; #X connect 10 1 12 0; #X connect 10 2 11 0; #X connect 11 0 9 1; #X connect 12 0 9 0; #X restore 42 273 pd polychange; #X connect 0 0 17 0; #X connect 2 0 15 0; #X connect 3 0 15 0; #X connect 4 0 15 0; #X connect 5 0 15 0; #X connect 6 0 15 0; #X connect 7 0 15 0; #X connect 8 0 15 0; #X connect 9 0 15 0; #X connect 10 0 14 0; #X connect 11 0 13 0; #X connect 12 0 1 0; #X connect 13 0 10 1; #X connect 14 0 20 0; #X connect 15 0 10 0; #X connect 15 1 14 1; #X connect 16 0 2 0; #X connect 16 1 3 0; #X connect 16 2 4 0; #X connect 16 3 5 0; #X connect 16 4 6 0; #X connect 16 5 7 0; #X connect 16 6 8 0; #X connect 16 7 9 0; #X connect 17 0 19 0; #X connect 17 1 18 0; #X connect 18 0 11 0; #X connect 19 0 16 0; #X connect 20 0 12 0; #X restore 7 13 pd digital messages roman; ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
As Ingo pointed out, one bug is that [mapping/debytemask] has the [change] object for each outlet. So probably the way to fix this is to make a bunch of [mapping/debytemask] objects for all the possible digital ports. [arduino] should only output on change of digital input, and it receives the digital information one byte/port at a time, i.e. 8 pins. Another approach would be to have an array of all of the previous values which are then compared to the current before outputting. .hc On Wed, 2011-09-14 at 11:24 +0200, Roman Haefeli wrote: Hi Ingo Thanks for all your reports. Sorry that my replies sometimes only come a few days later. I'm still willing to fix any outstanding issues, but not very often I find time to get an arduino into my hands. Since sometimes I have troubles following you and keeping your several bug reports apart from each other, I'd suggest to stick with [arduino] bugs and let the documentation aspect aside for a while. I _think_ I finally understand your problem with the digital ins. I can't currently test or reproduce the problem, since I don't have an arduino at hand, but from reading the code, I think I see what could go wrong. On certain incoming commands of [pd digital messages], the [pd debytemask] *) subpatch generates more than one message, but only the last one is finally sent to the outlet, because it only fires, when the left inlet of [+ ] is triggered, which is under all circumstances only triggered once after all the [pd debytemask] messages have fired. Actually, the order should be inversed, so that all messages from [pd debytemask] go the _left_ inlet of [+ ], and the summand is sent the _right_ inlet before. This is what I did in the patch you find attached. I rather have my version going into [arduino], since it is much less code than yours. From what I can tell, they both produce similar output, but as I said, I haven't had the chance to test it in real-world circumstances with a real arduino. So, please test and report back. I guess the main reason nobody (including me) has noticed this bug yet, is that you won't trigger it, if you only test one digital in at once. Changing the state of only one input at a time makes it seem, that all inputs work correctly. Only when changing states of several inputs at the same time, you will receive only a single digital messages, which is obviously wrong. I'm happy now that you kept bugging about this. It took me a while to (hopefully) understand the problem. Thanks for your persistence. *) There is no [debytemask] abstraction anymore in the git version of [arduino]. I replaced it by a subpatch. Roman On Sun, 2011-09-11 at 06:20 +0200, Ingo wrote: There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed is bug for over two years! ___ 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
Re: [PD] pduino rewrite
Upon further testing I have found two bugs so far. On is in the firmata and the second one is in the [debytemask]. This makes fixing it a bit difficult. 1) firmata: instead of sending two values for a digital pin connected or disconnected it sends three. The first one should be the address and the second one the value for the group of 8 pins. There may be a reason why it sends another 0 at the end but that's not too important anyway. The bad thing is that when disconnecting a pin it sends these number five times (sometimes only three times) in a row while going back and forth between the last value and the current one. That's 15 bytes instead of two. (I am using an inc/dec wheel with the arduino and now I know why it doesn't respond like it should.) I havn't checked the analogue ins so far. 2) [debytemask]: there is only one debytemask for all addresses. This means - since there is a [change] object inside - there will be a wrong value when the same button of a different group of pins is pressed or released twice after each other. This could be still correct if all other pins of the group have identical values but creates random numbers if the other pins change. Not sure yet what else gets affected. I am going to try to fix the problem with the [debytemask] but I don't know if the firmata stuff has any big influence on it. I just added another 6 buttons to my remote (using all 12 digital and 6 analogue ins of the Diecimila / Duemilanove now) and the whole thing is going crazy now sending wrong stuff all over the place. Ingo -Ursprüngliche Nachricht- Von: Hans-Christoph Steiner [mailto:h...@at.or.at] Gesendet: Freitag, 9. September 2011 16:41 An: Ingo Cc: 'Roman Haefeli'; 'pd-list' Betreff: Re: [PD] pduino rewrite I basically haven't used an Arduino in 2 years, so I am a poor candidate for debugging this stuff. Roman and Olsen are much better candidates for this job. The digital input pins are reported using the hardware-level ports, the hardware is organized around pins 0-7 being one port, 8-15, another, and 16-23 (analog pins) another. As for the pull-up resistor, you activate them just like you would in an other code for an Atmel AVR chip: switch the pin mode to INPUT then set that pin to HIGH (i.e. output a 1 to that pin). .hc On Fri, 2011-09-09 at 11:34 +0200, Ingo wrote: I did test it with the Duemilanove. But I also tested Diecimila and Uno. To me the problem looks like unfortunate design in the firmata. The buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I mentioned it. I have changed my arduino patch to get it to work for what I need with the Diecimila to Uno. I don't like to submit any workarounds if I don't have a mega available. I don't know how the rest of the pins are set up in blocks. It might also break something else since I only use part of the functions. I really think Hans is the one who should look into this problem to determine whether it is a pduino or firmata bug. I am really surprised that so few people have problems with this. Or maybe they do and simply cannot figure out where the problem comes from? Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 9. September 2011 10:49 An: Ingo Cc: 'olsen'; 'pd-list' Betreff: Re: AW: [PD] pduino rewrite On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything
Re: [PD] pduino rewrite
Hi Roman, Olsen and Hans, Here' a replacement object that fixes the behaviour that wrong digital in pins get recognized when more than the first 6 pins are used. I hope there is nothing else interfering with those pins anymore. The object digital_messages inside the patch should be placed here to replace the current object digital messages: Arduino/convert to symbolic commands/ Please test if it is working on other systems! I have no idea if this works with the mega or not since I don't have one to test it. If anyone could check this out it would be great to know! Ingo #N canvas 0 0 450 300 10; #N canvas 702 733 318 273 digital_messages 0; #X obj 43 16 inlet; #X obj 43 237 outlet; #X obj 43 43 route 0 1 2 3 4 5 6; #N canvas 2032 0 534 360 resolve-bits_32-39 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 440 129 mod 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 32 \$1; #X msg 80 216 digital 33 \$1; #X msg 140 196 digital 34 \$1; #X msg 200 216 digital 35 \$1; #X msg 260 196 digital 36 \$1; #X msg 320 216 digital 37 \$1; #X msg 380 196 digital 38 \$1; #X msg 440 216 digital 39 \$1; #X connect 0 0 25 0; #X connect 2 0 16 0; #X connect 3 0 15 0; #X connect 4 0 14 0; #X connect 5 0 13 0; #X connect 6 0 12 0; #X connect 7 0 9 0; #X connect 8 0 17 0; #X connect 9 0 18 0; #X connect 10 0 24 0; #X connect 11 0 10 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 23 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 33 0; #X connect 25 0 2 0; #X connect 25 0 3 0; #X connect 25 0 4 0; #X connect 25 0 5 0; #X connect 25 0 6 0; #X connect 25 0 8 0; #X connect 25 0 7 0; #X connect 25 0 11 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 1 0; #X restore 106 150 pd resolve-bits_32-39; #N canvas 2032 0 534 360 resolve-bits_0-7 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 440 129 mod 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20 196 digital 0 \$1; #X msg 80 216 digital 1 \$1; #X msg 140 196 digital 2 \$1; #X msg 200 216 digital 3 \$1; #X msg 260 196 digital 4 \$1; #X msg 320 216 digital 5 \$1; #X msg 380 196 digital 6 \$1; #X msg 440 216 digital 7 \$1; #X connect 0 0 25 0; #X connect 2 0 16 0; #X connect 3 0 15 0; #X connect 4 0 14 0; #X connect 5 0 13 0; #X connect 6 0 12 0; #X connect 7 0 9 0; #X connect 8 0 17 0; #X connect 9 0 18 0; #X connect 10 0 24 0; #X connect 11 0 10 0; #X connect 12 0 19 0; #X connect 13 0 20 0; #X connect 14 0 21 0; #X connect 15 0 22 0; #X connect 16 0 23 0; #X connect 17 0 26 0; #X connect 18 0 27 0; #X connect 19 0 28 0; #X connect 20 0 29 0; #X connect 21 0 30 0; #X connect 22 0 31 0; #X connect 23 0 32 0; #X connect 24 0 33 0; #X connect 25 0 2 0; #X connect 25 0 3 0; #X connect 25 0 4 0; #X connect 25 0 5 0; #X connect 25 0 6 0; #X connect 25 0 8 0; #X connect 25 0 7 0; #X connect 25 0 11 0; #X connect 26 0 1 0; #X connect 27 0 1 0; #X connect 28 0 1 0; #X connect 29 0 1 0; #X connect 30 0 1 0; #X connect 31 0 1 0; #X connect 32 0 1 0; #X connect 33 0 1 0; #X restore 43 70 pd resolve-bits_0-7; #N canvas 2032 0 534 360 resolve-bits_8-15 0; #X obj 200 18 inlet; #X obj 200 320 outlet; #X obj 380 129 mod 128; #X obj 320 129 mod 64; #X obj 260 129 mod 32; #X obj 200 129 mod 16; #X obj 140 129 mod 8; #X obj 80 129 mod 4; #X obj 20 129 mod 2; #X obj 80 149 div 2; #X obj 440 149 div 128; #X obj 440 129 mod 128; #X obj 140 149 div 4; #X obj 200 149 div 8; #X obj 260 149 div 16; #X obj 320 149 div 32; #X obj 380 149 div 64; #X obj 20 169 change -1; #X obj 80 169 change -1; #X obj 140 169 change -1; #X obj 200 169 change -1; #X obj 260 169 change -1; #X obj 320 169 change -1; #X obj 380 169 change -1; #X obj 440 169 change -1; #X obj 200 55 change -1; #X msg 20
Re: [PD] pduino rewrite
There is another thing that I just noticed about the pduino test-patch. The mode buttons are suggesting that you can turn of all functions by selecting NONE. This is not true! These buttons have absolutely NO function and should be replaced with the correct commands. While doing this the option Input-PullUp should be added. The Arduino generally defaults to input. Selecting NONE at the current state leaves it at the last selected option. The analogue ins can actually be turned off by the command analogIns X 0 (where the X stands for the pin number 0-5). The digital input pins need the command digitalIns X 0 (where the X stands for the pin number 0-11). I also think that there should be a separate block for digital an analogue (with the available options only) as beginners might think you could select analog as an option for digital pins, and so on... Ingo BTW with the fix I just submitted in my last email all digital ins now work flawlessly after testing for several hours. I am amazed that hardly anybody noticed this bug for over two years! ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Ingo On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. Hm.. is this probably due to Windows and Linux using different line breaks (\r\n vs. \n)? I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. FYI: We haven't tinkered with the protocol. At this stage it's really only a version with some externals kicked out. Anyway, please report back, if you still experience the same problems. Are you testing on a Arduino Mega? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Ingo Hi Ingo On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. Hm.. is this probably due to Windows and Linux using different line breaks (\r\n vs. \n)? I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. FYI: We haven't tinkered with the protocol. At this stage it's really only a version with some externals kicked out. Anyway, please report back, if you still experience the same problems. Are you testing on a Arduino Mega? Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
I forgot to mention: I tested with a Duemilanove. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Ingo Gesendet: Freitag, 9. September 2011 10:04 An: 'Roman Haefeli'; 'olsen'; 'pd-list' Betreff: Re: [PD] pduino rewrite Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Ingo Hi Ingo On Fri, 2011-09-09 at 05:47 +0200, Ingo wrote: OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. Hm.. is this probably due to Windows and Linux using different line breaks (\r\n vs. \n)? I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. FYI: We haven't tinkered with the protocol. At this stage it's really only a version with some externals kicked out. Anyway, please report back, if you still experience the same problems. Are you testing on a Arduino Mega? 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
Re: [PD] pduino rewrite
On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Yo, it's very much a work in progress and yet the main goal was not loose any functionality by getting rid of the externals. I did not address any bugs yet, because I didn't experience any. I only have a arduino Diecimila to test here. So, I ask you again: The problem you mentioned with pin 2 and 3, on which arduino board model do you experience it? Also, if the problem is located in the firmware and not in the [arduino] abstraction, I rather don't 'fix' it in the [arduino] abstraction. Since you seem to have a strong interest on making it work for your situation, I suggest to give you commit privileges to that repository. You could send me your public key off-list and I would give you access to that repository. Also, thanks for your other comments. Those are all valid points that need to be addressed. (Actually, 'pduino rewrite' as thread was a bit too much a promise, it should have read 'please test and report back'.) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
I did test it with the Duemilanove. But I also tested Diecimila and Uno. To me the problem looks like unfortunate design in the firmata. The buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I mentioned it. I have changed my arduino patch to get it to work for what I need with the Diecimila to Uno. I don't like to submit any workarounds if I don't have a mega available. I don't know how the rest of the pins are set up in blocks. It might also break something else since I only use part of the functions. I really think Hans is the one who should look into this problem to determine whether it is a pduino or firmata bug. I am really surprised that so few people have problems with this. Or maybe they do and simply cannot figure out where the problem comes from? Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 9. September 2011 10:49 An: Ingo Cc: 'olsen'; 'pd-list' Betreff: Re: AW: [PD] pduino rewrite On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Yo, it's very much a work in progress and yet the main goal was not loose any functionality by getting rid of the externals. I did not address any bugs yet, because I didn't experience any. I only have a arduino Diecimila to test here. So, I ask you again: The problem you mentioned with pin 2 and 3, on which arduino board model do you experience it? Also, if the problem is located in the firmware and not in the [arduino] abstraction, I rather don't 'fix' it in the [arduino] abstraction. Since you seem to have a strong interest on making it work for your situation, I suggest to give you commit privileges to that repository. You could send me your public key off-list and I would give you access to that repository. Also, thanks for your other comments. Those are all valid points that need to be addressed. (Actually, 'pduino rewrite' as thread was a bit too much a promise, it should have read 'please test and report back'.) Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
I basically haven't used an Arduino in 2 years, so I am a poor candidate for debugging this stuff. Roman and Olsen are much better candidates for this job. The digital input pins are reported using the hardware-level ports, the hardware is organized around pins 0-7 being one port, 8-15, another, and 16-23 (analog pins) another. As for the pull-up resistor, you activate them just like you would in an other code for an Atmel AVR chip: switch the pin mode to INPUT then set that pin to HIGH (i.e. output a 1 to that pin). .hc On Fri, 2011-09-09 at 11:34 +0200, Ingo wrote: I did test it with the Duemilanove. But I also tested Diecimila and Uno. To me the problem looks like unfortunate design in the firmata. The buttons 2-9 don't somehow connect the same 8-bit word. It might simply be a bug in the firmata. Hans hasn't reacted to it the last 2 or 3 times I mentioned it. I have changed my arduino patch to get it to work for what I need with the Diecimila to Uno. I don't like to submit any workarounds if I don't have a mega available. I don't know how the rest of the pins are set up in blocks. It might also break something else since I only use part of the functions. I really think Hans is the one who should look into this problem to determine whether it is a pduino or firmata bug. I am really surprised that so few people have problems with this. Or maybe they do and simply cannot figure out where the problem comes from? Ingo -Ursprüngliche Nachricht- Von: Roman Haefeli [mailto:reduz...@gmail.com] Gesendet: Freitag, 9. September 2011 10:49 An: Ingo Cc: 'olsen'; 'pd-list' Betreff: Re: AW: [PD] pduino rewrite On Fri, 2011-09-09 at 10:03 +0200, Ingo wrote: Hi Roman, I just messed around with the rewrite and - as you mentioned - you didn't fix any of the bugs. I even think I send you a mail about the digital pins 2 3 and provided a fix for it here at the forum. Of course it's still there! About the other things: - The test patch has still no switches to turn on the pull up resistors. - in Natty the comport number for USB0 is 32 that's not available in the choices 0 - 7. I think for Linux [devicename /dev/ttyUSB$1( would be a better choice. At least this option of naming should be mentioned somewhere in the test patch or help patch. (maybe I missed it somewhere?) - help-patch: there is no such thing as PullDown. It's only PullUp. It should be mentioned that pin 13 does not work for Pull Up due to the built in LED and resistor. There should also be a short explanation about PullUp resistors for beginners. - help-patch: DIGITAL-INPUT should mention the PullUp resistors. I spent a lot of time at the beginning making lots of complicated cable connections because the help patch recommends connecting the pins to ground instead of simply switching on the PullUp resistors. At least as long as you are not at the very limit of your power supply. Since I only use the digital and analogue ins I didn't look any further. So I can't say anything about the output stuff. The digital pins 2 3 should really be fixed sometime soon. I was hoping you'd be getting some of these problems solved rather than putting a grey background to the help patch (lol). Yo, it's very much a work in progress and yet the main goal was not loose any functionality by getting rid of the externals. I did not address any bugs yet, because I didn't experience any. I only have a arduino Diecimila to test here. So, I ask you again: The problem you mentioned with pin 2 and 3, on which arduino board model do you experience it? Also, if the problem is located in the firmware and not in the [arduino] abstraction, I rather don't 'fix' it in the [arduino] abstraction. Since you seem to have a strong interest on making it work for your situation, I suggest to give you commit privileges to that repository. You could send me your public key off-list and I would give you access to that repository. Also, thanks for your other comments. Those are all valid points that need to be addressed. (Actually, 'pduino rewrite' as thread was a bit too much a promise, it should have read 'please test and report back'.) 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
Re: [PD] pduino rewrite
I could not open any patch at all! Neither Natty nor Windows XP worked. I am still on Pd-extended 0.42.5. There is a huge list of stuff (not pd library related) missing. So far this doesn't look like it's improving any dependency problem. Ingo buenas tutti roman me did some rewrite on the pduino - citing the README: Pduino - improved - All Pd patches are based on the official Pduino (version 0.5beta8) maintained by Hans-Christoph Steiner. The goals of the improvements are: * Get rid of avoidable dependencies on other external/abstraction libraries * Update help- and test-patches in accordance to current Firmata * Create 'intuitive' and easy-to-understand GOP abstraction Dependencies: * comport * pdstring library from moocow you'll find the patches here: https://github.com/reduzent/pduino the GOP-abstraction is still in tango alpha state aka not useable at all. so basically arduino.pd arduino-help.pd should be of interest. as they went thru some changes - most important the dependencies are reduce to the minimum. check it out report ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
OK, I got it! Downloading the files didn't work (at least not on my Windows computer) but copying the content into a bunch of text files and renaming them did. I'll take a look at it later to see if the problems with the 1st and 2nd digital input as well as my problems with inputs 10 - 13 are gone. Ingo Betreff: Re: [PD] pduino rewrite I could not open any patch at all! Neither Natty nor Windows XP worked. I am still on Pd-extended 0.42.5. There is a huge list of stuff (not pd library related) missing. So far this doesn't look like it's improving any dependency problem. Ingo buenas tutti roman me did some rewrite on the pduino - citing the README: Pduino - improved - All Pd patches are based on the official Pduino (version 0.5beta8) maintained by Hans-Christoph Steiner. The goals of the improvements are: * Get rid of avoidable dependencies on other external/abstraction libraries * Update help- and test-patches in accordance to current Firmata * Create 'intuitive' and easy-to-understand GOP abstraction Dependencies: * comport * pdstring library from moocow you'll find the patches here: https://github.com/reduzent/pduino the GOP-abstraction is still in tango alpha state aka not useable at all. so basically arduino.pd arduino-help.pd should be of interest. as they went thru some changes - most important the dependencies are reduce to the minimum. check it out report ___ 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
[PD] pduino rewrite
buenas tutti roman me did some rewrite on the pduino - citing the README: Pduino - improved - All Pd patches are based on the official Pduino (version 0.5beta8) maintained by Hans-Christoph Steiner. The goals of the improvements are: * Get rid of avoidable dependencies on other external/abstraction libraries * Update help- and test-patches in accordance to current Firmata * Create 'intuitive' and easy-to-understand GOP abstraction Dependencies: * comport * pdstring library from moocow you'll find the patches here: https://github.com/reduzent/pduino the GOP-abstraction is still in tango alpha state aka not useable at all. so basically arduino.pd arduino-help.pd should be of interest. as they went thru some changes - most important the dependencies are reduce to the minimum. check it out report ø -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino rewrite
This is a great start, it needed some loving. I'll check it out when I have some time. .hc On Fri, 2011-09-02 at 12:20 +0200, olsen wrote: buenas tutti roman me did some rewrite on the pduino - citing the README: Pduino - improved - All Pd patches are based on the official Pduino (version 0.5beta8) maintained by Hans-Christoph Steiner. The goals of the improvements are: * Get rid of avoidable dependencies on other external/abstraction libraries * Update help- and test-patches in accordance to current Firmata * Create 'intuitive' and easy-to-understand GOP abstraction Dependencies: * comport * pdstring library from moocow you'll find the patches here: https://github.com/reduzent/pduino the GOP-abstraction is still in tango alpha state aka not useable at all. so basically arduino.pd arduino-help.pd should be of interest. as they went thru some changes - most important the dependencies are reduce to the minimum. check it out report ø ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
On 06/17/2011 12:24 AM, Matteo Sisti Sette wrote: On 06/16/2011 05:44 PM, olsen wrote: it's all in the arduino-help.pd by Gerda Strobl and Georg Holzmann! Which one??? Not the one that is distributed together with [arduino] and [arduino-test] at http://at.or.at/hans/pd/objects.html, right? yo it's in Pduino-0.5beta8 linked on this page in the last subpatch [pd SWITCHING-INPUTS] you'll find the apropriate messages. There I find the same analogIns messages that are supposed to be the old ones (but are the only ones I've found that work for analog pins with the latest version of Firmata) jep i agree they're the same - i think it's a matter of wrong denotation so due to my knowledge there's nothing like old and newer messages - the current 'contemporary' message for enabling the analog inputs is: [analogIns pinumber 1=on; 0=off( f.e. to enable analog pin 1: [analogIns 1 1( correct me if i'm wrong! i don't know why this is commented with (optional) I must have another version of the help patch, as I don't see such a comment right behind the [pd SWITCHING-INPUTS] is a comment - example of switching inputs on and off (optional) How are the messages you're talking about? i guess it's a firmata peculiarity that you've explicit have to enable the analog pins as in arduino they are enabled by default - but correct me if i'm wrong. Yes, I guess what you have to explicitly enable is to have the firmware _send_ the values to the computer. It would be undesirable to have a constant flood of values of all pins whether you use them or not. jep right so with firmata the analogIns have to be enabled explicitly to use them. i think the (optional) comment somehow makes it ambiguous. as told i'll try to consider this in the improvements we're working on! salutis ø -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
eo as i mentioned in my previous post the enabling of the analogIns was also somehow confusing for me, though now i found out it's all in the arduino-help.pd by Gerda Strobl and Georg Holzmann! in the last subpatch [pd SWITCHING-INPUTS] you'll find the apropriate messages. i don't know why this is commented with (optional) but maybe this - also due to this thread - should be placed more prominent within the help-patch. as mentioned by roman we're currently doing some improvements on the whole pduino dingdongs i'll try to find a solution - suggestions are welcome. i guess it's a firmata peculiarity that you've explicit have to enable the analog pins as in arduino they are enabled by default - but correct me if i'm wrong. hth ø ej hans all the best for your genealogical tree extension!! On 06/14/2011 04:51 PM, Ingo wrote: The exact same thing that Matteo mentioned about the old analogue method is happening here, too. Tested with Diecimila and Duemilanove. I was also using the test patch as a starting patch. My workaraound was simply to use the old method (after for searching for quite some time). I need to find the other problem with the digital Ins 1+2 giving wrong values will first. I will post a patch to reproduce it asap but it might take a couple of days to look for it. I had a workaround for it already but I do not know if this workaround could still be applied with other boards like the mega. As far as I remember it was a problem of the firmata sending wrong data rather than the pd patch doing something wrong. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Matteo Sisti Sette Gesendet: Dienstag, 14. Juni 2011 16:26 An: Roman Haefeli Cc: 'PD List' Betreff: Re: [PD] pduino test patch: old analog/digital controls On 06/13/2011 09:09 PM, Roman Haefeli wrote: @Ingo and Matteo I'm also quite interested in having the [arduino] working properly. I didn't find any bugs recently, though. However, if you provide a step-by-step guide about how to reproduce a problem, I (and probably Olsen also) might be able to help, Ok, the problem is that in my case I'm not sure whether I'm experiencing an issue, an incorrectness in the test patch, or just my lack of knowledge of how it is _expected_ to behave. With both old and new versions of the StandardFirmata firmware the following message enables analog input from pin A0 (i.e. pin 14): analogIns 0 1 (0 means A0 and 1 means on) But in the test patch this is enclosed in a subpatch calles old analog/digital controls so is it supposed to be obsolete? The only other way I've seemed to find to enable input from analog pin A0 is: pinMode 14 analog which seems to be the suggested way in the test patch (offered with the pink grid on the upper-right part of the patch), but this only works with OLD versions of StandardFirmata. So it looks like either: a. there is a third, current, non-obsolete, recommended way of doing that which I don't know b. the suggested way is the old one and the one documented as old is actually the new one (but I don't think so, that's not what Chris said) c. something isn't working right The same happens with both Arduino 2009 (with the StandardFirmata sketch) and with an Arduino UNO (with the StandardFirmata_2_2_for_UNO_0_3). Both sketches are those that ship with the latest package of the Arduino IDE for Debian sid. The older StandardFirmata sketch where the pinMode N analog message worked were taken from an older version of the arduino package for Ubuntu from the official repository, but I don't remember the version number. ___ 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 -- ETs DNA will not be televised http://hasa-labs.org ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
On 06/16/2011 05:44 PM, olsen wrote: it's all in the arduino-help.pd by Gerda Strobl and Georg Holzmann! Which one??? Not the one that is distributed together with [arduino] and [arduino-test] at http://at.or.at/hans/pd/objects.html, right? in the last subpatch [pd SWITCHING-INPUTS] you'll find the apropriate messages. There I find the same analogIns messages that are supposed to be the old ones (but are the only ones I've found that work for analog pins with the latest version of Firmata) i don't know why this is commented with (optional) I must have another version of the help patch, as I don't see such a comment How are the messages you're talking about? i guess it's a firmata peculiarity that you've explicit have to enable the analog pins as in arduino they are enabled by default - but correct me if i'm wrong. Yes, I guess what you have to explicitly enable is to have the firmware _send_ the values to the computer. It would be undesirable to have a constant flood of values of all pins whether you use them or not. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
On 06/13/2011 09:09 PM, Roman Haefeli wrote: @Ingo and Matteo I'm also quite interested in having the [arduino] working properly. I didn't find any bugs recently, though. However, if you provide a step-by-step guide about how to reproduce a problem, I (and probably Olsen also) might be able to help, Ok, the problem is that in my case I'm not sure whether I'm experiencing an issue, an incorrectness in the test patch, or just my lack of knowledge of how it is _expected_ to behave. With both old and new versions of the StandardFirmata firmware the following message enables analog input from pin A0 (i.e. pin 14): analogIns 0 1 (0 means A0 and 1 means on) But in the test patch this is enclosed in a subpatch calles old analog/digital controls so is it supposed to be obsolete? The only other way I've seemed to find to enable input from analog pin A0 is: pinMode 14 analog which seems to be the suggested way in the test patch (offered with the pink grid on the upper-right part of the patch), but this only works with OLD versions of StandardFirmata. So it looks like either: a. there is a third, current, non-obsolete, recommended way of doing that which I don't know b. the suggested way is the old one and the one documented as old is actually the new one (but I don't think so, that's not what Chris said) c. something isn't working right The same happens with both Arduino 2009 (with the StandardFirmata sketch) and with an Arduino UNO (with the StandardFirmata_2_2_for_UNO_0_3). Both sketches are those that ship with the latest package of the Arduino IDE for Debian sid. The older StandardFirmata sketch where the pinMode N analog message worked were taken from an older version of the arduino package for Ubuntu from the official repository, but I don't remember the version number. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
The exact same thing that Matteo mentioned about the old analogue method is happening here, too. Tested with Diecimila and Duemilanove. I was also using the test patch as a starting patch. My workaraound was simply to use the old method (after for searching for quite some time). I need to find the other problem with the digital Ins 1+2 giving wrong values will first. I will post a patch to reproduce it asap but it might take a couple of days to look for it. I had a workaround for it already but I do not know if this workaround could still be applied with other boards like the mega. As far as I remember it was a problem of the firmata sending wrong data rather than the pd patch doing something wrong. Ingo -Ursprüngliche Nachricht- Von: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] Im Auftrag von Matteo Sisti Sette Gesendet: Dienstag, 14. Juni 2011 16:26 An: Roman Haefeli Cc: 'PD List' Betreff: Re: [PD] pduino test patch: old analog/digital controls On 06/13/2011 09:09 PM, Roman Haefeli wrote: @Ingo and Matteo I'm also quite interested in having the [arduino] working properly. I didn't find any bugs recently, though. However, if you provide a step-by-step guide about how to reproduce a problem, I (and probably Olsen also) might be able to help, Ok, the problem is that in my case I'm not sure whether I'm experiencing an issue, an incorrectness in the test patch, or just my lack of knowledge of how it is _expected_ to behave. With both old and new versions of the StandardFirmata firmware the following message enables analog input from pin A0 (i.e. pin 14): analogIns 0 1 (0 means A0 and 1 means on) But in the test patch this is enclosed in a subpatch calles old analog/digital controls so is it supposed to be obsolete? The only other way I've seemed to find to enable input from analog pin A0 is: pinMode 14 analog which seems to be the suggested way in the test patch (offered with the pink grid on the upper-right part of the patch), but this only works with OLD versions of StandardFirmata. So it looks like either: a. there is a third, current, non-obsolete, recommended way of doing that which I don't know b. the suggested way is the old one and the one documented as old is actually the new one (but I don't think so, that's not what Chris said) c. something isn't working right The same happens with both Arduino 2009 (with the StandardFirmata sketch) and with an Arduino UNO (with the StandardFirmata_2_2_for_UNO_0_3). Both sketches are those that ship with the latest package of the Arduino IDE for Debian sid. The older StandardFirmata sketch where the pinMode N analog message worked were taken from an older version of the arduino package for Ubuntu from the official repository, but I don't remember the version number. ___ 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
Re: [PD] pduino test patch: old analog/digital controls
Hi, I bring this up again after some further testing: I: In the Pduino test patch (arduino-test.pd) there is a subpatch called old analog/digital controls. ... analogIns X Y (where X is the analog pin to enable/disable and Y is either 0 or 1). Hans-Christoph Steiner: That's the original way of controlling the analog inputs. It just controls whether the Arduino sends the analog messages. Its there only for backwards compatibility. Use the non-old messages now. I: What are the non-old messages? looking at the arduino-test and arduino-help patches I can't see any way of enabling analog inputs I didn't get any answer but i found out that the message pinMode 14 analog worked like analogIns 0 1 (being pin 14 the same as A0) However, actually this works _only_ on older versions of Firmata and doesn't work with the latest version. By latest version I mean the StandardFirmata and StandardFirmata_2_2_for_UNO_0_3 example sketches packed with the latest version of the Arduino IDE (latest available package for Debian unstable). With the latest version, the only way I've found that actually works to enable analog input pins are the so-called old messages analogIns npin 1/0 Can anybody please clarify? Thanks m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
With the latest version, the only way I've found that actually works to enable analog input pins are the so-called old messages analogIns npin 1/0 /listinfo/pd-list I was mentioning that before. I had the same problem. There is another problem with the digital ins 1 and 2. I got myself a workaround. Unfortunately I don't remember anymore what it was exactly. It happened when you went from pin 1 or 2 to another one and back. The first value came out as a 0 instead of the correct version. I think it had to do with the fact that pins 1-8 should form a 8-bit number but 1+2 are part of another 8-bit number or something like that. It happens somewhere in the part of the mapping. Ingo ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
On Jun 13, 2011, at 1:48 PM, Ingo wrote: With the latest version, the only way I've found that actually works to enable analog input pins are the so-called old messages analogIns npin 1/0 /listinfo/pd-list I was mentioning that before. I had the same problem. There is another problem with the digital ins 1 and 2. I got myself a workaround. Unfortunately I don't remember anymore what it was exactly. It happened when you went from pin 1 or 2 to another one and back. The first value came out as a 0 instead of the correct version. I think it had to do with the fact that pins 1-8 should form a 8-bit number but 1+2 are part of another 8-bit number or something like that. It happens somewhere in the part of the mapping. Ingo I'm totally swamped these days, getting ready for a baby that's coming soon. Please submit bug reports, patches, help file updates, and I'll get to it when I can. .hc We have nothing to fear from love and commitment. - New York Senator Diane Savino, trying to convince the NY Senate to pass a gay marriage bill ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
On Mon, 2011-06-13 at 13:57 -0400, Hans-Christoph Steiner wrote: On Jun 13, 2011, at 1:48 PM, Ingo wrote: With the latest version, the only way I've found that actually works to enable analog input pins are the so-called old messages analogIns npin 1/0 /listinfo/pd-list I was mentioning that before. I had the same problem. There is another problem with the digital ins 1 and 2. I got myself a workaround. Unfortunately I don't remember anymore what it was exactly. It happened when you went from pin 1 or 2 to another one and back. The first value came out as a 0 instead of the correct version. I think it had to do with the fact that pins 1-8 should form a 8-bit number but 1+2 are part of another 8-bit number or something like that. It happens somewhere in the part of the mapping. Ingo I'm totally swamped these days, getting ready for a baby that's coming soon. Please submit bug reports, patches, help file updates, and I'll get to it when I can. @Ingo and Matteo I'm also quite interested in having the [arduino] working properly. I didn't find any bugs recently, though. However, if you provide a step-by-step guide about how to reproduce a problem, I (and probably Olsen also) might be able to help, as I know the code inside a bit, although I'm not the author (as long as the problem exists on the Pd side and not on the Firmata side). Regarding the help and test files, we just improve what needs improvement. I hear that this is OK with Hans. @Hans I wish you guys good luck and a happy baby! Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
On Jun 13, 2011, at 3:09 PM, Roman Haefeli wrote: On Mon, 2011-06-13 at 13:57 -0400, Hans-Christoph Steiner wrote: On Jun 13, 2011, at 1:48 PM, Ingo wrote: With the latest version, the only way I've found that actually works to enable analog input pins are the so-called old messages analogIns npin 1/0 /listinfo/pd-list I was mentioning that before. I had the same problem. There is another problem with the digital ins 1 and 2. I got myself a workaround. Unfortunately I don't remember anymore what it was exactly. It happened when you went from pin 1 or 2 to another one and back. The first value came out as a 0 instead of the correct version. I think it had to do with the fact that pins 1-8 should form a 8-bit number but 1+2 are part of another 8-bit number or something like that. It happens somewhere in the part of the mapping. Ingo I'm totally swamped these days, getting ready for a baby that's coming soon. Please submit bug reports, patches, help file updates, and I'll get to it when I can. @Ingo and Matteo I'm also quite interested in having the [arduino] working properly. I didn't find any bugs recently, though. However, if you provide a step-by-step guide about how to reproduce a problem, I (and probably Olsen also) might be able to help, as I know the code inside a bit, although I'm not the author (as long as the problem exists on the Pd side and not on the Firmata side). Regarding the help and test files, we just improve what needs improvement. I hear that this is OK with Hans. Definitely, please improve! @Hans I wish you guys good luck and a happy baby! Thanks! hc You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] pduino test patch: old analog/digital controls
That's the original way of controlling the analog inputs. It just controls whether the Arduino sends the analog messages. Its there only for backwards compatibility. Use the non-old messages now. What are the non-old messages? Maybe I should study the firmata documentation instead of just playing around with these patches, but looking at the arduino-test and arduino-help patches I can't see any way of enabling analog inputs (i.e. have the arduino send them) other than these old messages. I guess it's in front of my eyes and I don't see it... thanks m. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
