Hello!
I am trying to migrate a Pduino Patch from pd-extended to Pd-Vanilla and the only object that is missing is "moocow/string2any". (A weird thing is that on Linux I was able to find moocow in the external search from pd-vanilla, but on Windows I am not.)
However, I wanted to ask if there is a possibiliy to substitude the function of "string2any" with a more common PD Operation or something I can still find in the externals.
Big thanks!
Marco
Hi,
basically, you can achieve the same thing with [list split] and [fudiparse]. The only problem is that [moocow/string2any] bashes special characters (commas, semicolons, etc.) to symbols, but [fudiparse] doesn't (commas and semicolons are treated as message terminators)... if you're certain that your input won't contain those special symbols, it's straightforward, otherwise you would need to manually escape them with backslahes before feeding the byte lists to [fudiparse].
Christof
Gesendet: Samstag, 12. Oktober 2019 um 15:27 Uhr Von: "marco" marr9934@drei.at An: pd-list@lists.iem.at Betreff: [PD] moocow string2any
Hello!
I am trying to migrate a Pduino Patch from pd-extended to Pd-Vanilla and the only object that is missing is "moocow/string2any". (A weird thing is that on Linux I was able to find moocow in the external search from pd-vanilla, but on Windows I am not.)
However, I wanted to ask if there is a possibiliy to substitude the function of "string2any" with a more common PD Operation or something I can still find in the externals.
Big thanks!
Marco
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sat, 2019-10-12 at 15:27 +0200, marco wrote:
Hello!
I am trying to migrate a Pduino Patch from pd-extended to Pd-Vanilla
I did migrate the pduino library from Pd-extended to a vanilla friendly version. The only dependency that remained is [comport].
and the only object that is missing is "moocow/string2any". (A weird thing
There is no point in using [string2any] anymore these days.
You could try pduino 0.6 from Deken. From what I remember, it adds features compared to 0.5 (the last version part of Pd-extendd), but is backward compatible.
Roman
hello, I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1. The digital input 7 of Arduino Nano doesn't return anything. Here are my tests :
- tried with different Nano boards : nothing changed
- tried differents versions of Firmata : nothing changed
- tried to read inputs with Max/MSP and Processing digital input 7 : the
two softs return the good value
- tried my Pd patch with Pduino 0.5 and Pd-Extended : all is fine, d7
return the good value
I experience this issue with OSX10.11.6 and Raspbian - Linux version 5.4.72-v7+ (dom@buildbot) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #1356 SMP Thu Oct 22 13:56:54 BST 2020
On 12/22/20 4:59 PM, Gilles Marivier wrote:
hello, I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1. The digital input 7 of Arduino Nano doesn't return anything.
i wonder how this is related to "moocow string2any"?
and have you tried pduino 0.5 with Pd-vanilla 0.51-1? and watch the Pd-console for errors about uncreatable objects. in order to use pduino, you also must have comport installed.
I experience this issue with OSX10.11.6 and Raspbian - Linux version
5.4.72-v7+
on raspbian, you can install pduino with apt-get install pd-pduino
which will install all the dependencies (like pd-comport) as well.
also note, that for the raspbian version, it's often (but of course not
always) more interesting to get the distribution version rather than the
kernel version: run lsb_release -a instea of uname -a (or both ;-))
gfmasdr IOhannes
hello, thank you.
Le 23/12/2020 à 10:51, IOhannes m zmoelnig a écrit :
On 12/22/20 4:59 PM, Gilles Marivier wrote:
hello, I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1. The digital input 7 of Arduino Nano doesn't return anything.
i wonder how this is related to "moocow string2any"?
"moocow string2any" is necessary for Pduino 0.5/Pd vanilla, and doesn't exist for Raspbian. I was searching for a solution for this object
and have you tried pduino 0.5 with Pd-vanilla 0.51-1?
Yes, but
1- I need to install zexy, mapping, and moocow (doesn't exist for Raspbian). For this last, [string2any] is the object necessary => that's why I landed on this thread
2- with OSX, it's almost ok (all libraries availables) but I think the object [list prepend] causes an error. Here are error messages in the pd-console :
[comport] set_baudrate: Setting baud rate to 6.95322e-310 with baudbits 0xE100 [comport] opened serial line device 1 (/dev/tty.wchusbserial1410)
route 13 0 20 1 (message->prepend) connection failed route 14 0 20 1 (message->prepend) connection failed route 16 0 20 1 (bang->prepend) connection failed route 17 0 20 1 (bang->prepend) connection failed [arduino]: version_0.5 Rarduino: version 2 5 Rarduino: firmware AllInputsFirmata.ino 2 5 UNKNOWN_INPUT_COMMAND: 0 393 UNKNOWN_INPUT_COMMAND: 1 399 UNKNOWN_INPUT_COMMAND: 2 344
etc. etc. (UNKNOWN_INPUT error is infinite when serial port is open, and stops when I close it)
and watch the Pd-console for errors about uncreatable objects.
No uncreatable objects error but "connection failed" error (see upper)
in order to use pduino, you also must have comport installed.
Comport is installed of course
I experience this issue with OSX10.11.6 and Raspbian - Linux version
5.4.72-v7+
on raspbian, you can install pduino with
apt-get install pd-pduinowhich will install all the dependencies (like pd-comport) as well.
I know, I did that. I tried with all the corrects externals objects in an external specific folder too, with declare object, I tried with this folder and pd's path preferences too.
I built many interactive devices with Arduino/Raspbian/Pdvanilla/or PdExtended, the "digital in 7 issue" with Pduin0.5 is the only issue I have.
also note, that for the raspbian version, it's often (but of course not always) more interesting to get the distribution version rather than the kernel version: run
lsb_release -ainstea ofuname -a(or both ;-))
thanks : Raspbian 10 buster
gfmasdr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 12/23/20 11:33 AM, Gilles Marivier wrote:
hello, thank you.
Le 23/12/2020 à 10:51, IOhannes m zmoelnig a écrit :
On 12/22/20 4:59 PM, Gilles Marivier wrote:
hello, I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1. The digital input 7 of Arduino Nano doesn't return anything.
i wonder how this is related to "moocow string2any"?
"moocow string2any" is necessary for Pduino 0.5/Pd vanilla, and doesn't exist for Raspbian. I was searching for a solution for this object
well the real question was: why is the subject of your email "moocow string2any", when it really is about problems with pduino.
[1] mentions that you should change the subject if the topic discussed has changed.
and have you tried pduino 0.5 with Pd-vanilla 0.51-1?
Yes, but
1- I need to install zexy, mapping, and moocow (doesn't exist for Raspbian). For this last, [string2any] is the object necessary => that's why I landed on this thread
and
on raspbian, you can install pduino with
apt-get install pd-pduinowhich will install all the dependencies (like pd-comport) as well.I know, I did that. I tried with all the corrects externals objects in an external specific folder too, with declare object, I tried with this folder and pd's path preferences too.
well, on Raspbian, [string2any] is in the pd-pdstring package (which is pulled in by pd-pduino).
when using a Pd that has not been installed via 'apt-get', i can at least create the [pduino/arduino] object without problems when starting $ pd -path /usr/lib/pd/extra/
so i don't understand your problem.
2- with OSX, it's almost ok (all libraries availables) but I think the object [list prepend] causes an error. Here are error messages in the pd-console :
[...]
route 13 0 20 1 (message->prepend) connection failed
first: that's definitely *not* "almost ok". it means that the patch most likely won't work, because missing connections will prevent the data to flow where it should flow to.
then: i don't think it's the [list prepend] object. older versions of [arduino] (those found on deken before 0.6) used - besides the [list prepend] object - [cyclone/prepend].
now, [arduino] is a rather old object, and when it was written, cyclone was still maintained by Krzysztof Czaja. in his original version of cyclone, a [prepend] object created with no arguments would get an extra inlet, to set the atoms that should be prepended.
it seems that since alex has taken over cyclone, the extra inlet of [prepend] has vanished. i don't know enough about Max/MSP to know, whether this change was done to enforce stricter compatibility between the two runtimes.
anyhow: to solve your problem, you can:
- use the old cyclone
- ask alex to re-introduce the 2nd inlet
- replace [cyclone/prepend] with [list prepend] (plus the occasional
[list/trim]).
gfmasd IOhannes
Le 23/12/2020 à 12:24, IOhannes m zmoelnig a écrit :
On 12/23/20 11:33 AM, Gilles Marivier wrote:
hello, thank you.
Le 23/12/2020 à 10:51, IOhannes m zmoelnig a écrit :
On 12/22/20 4:59 PM, Gilles Marivier wrote:
hello, I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1. The digital input 7 of Arduino Nano doesn't return anything.
i wonder how this is related to "moocow string2any"?
"moocow string2any" is necessary for Pduino 0.5/Pd vanilla, and doesn't exist for Raspbian. I was searching for a solution for this object
well the real question was: why is the subject of your email "moocow string2any", when it really is about problems with pduino.
[1] mentions that you should change the subject if the topic discussed has changed.
and have you tried pduino 0.5 with Pd-vanilla 0.51-1?
Yes, but
1- I need to install zexy, mapping, and moocow (doesn't exist for Raspbian). For this last, [string2any] is the object necessary => that's why I landed on this thread
and
on raspbian, you can install pduino with
apt-get install pd-pduinowhich will install all the dependencies (like pd-comport) as well.I know, I did that. I tried with all the corrects externals objects in an external specific folder too, with declare object, I tried with this folder and pd's path preferences too.
well, on Raspbian, [string2any] is in the pd-pdstring package (which is pulled in by pd-pduino).
when using a Pd that has not been installed via 'apt-get', i can at least create the [pduino/arduino] object without problems when starting $ pd -path /usr/lib/pd/extra/
so i don't understand your problem.
2- with OSX, it's almost ok (all libraries availables) but I think the object [list prepend] causes an error. Here are error messages in the pd-console :
[...]
route 13 0 20 1 (message->prepend) connection failed
first: that's definitely *not* "almost ok". it means that the patch most likely won't work, because missing connections will prevent the data to flow where it should flow to.
then: i don't think it's the [list prepend] object. older versions of [arduino] (those found on deken before 0.6) used - besides the [list prepend] object - [cyclone/prepend].
now, [arduino] is a rather old object, and when it was written, cyclone was still maintained by Krzysztof Czaja. in his original version of cyclone, a [prepend] object created with no arguments would get an extra inlet, to set the atoms that should be prepended.
it seems that since alex has taken over cyclone, the extra inlet of [prepend] has vanished. i don't know enough about Max/MSP to know, whether this change was done to enforce stricter compatibility between the two runtimes.
anyhow: to solve your problem, you can:
- use the old cyclone
- ask alex to re-introduce the 2nd inlet
- replace [cyclone/prepend] with [list prepend] (plus the occasional
[list/trim]).
gfmasd IOhannes
[1] http://puredata.info/community/lists/Netiquette
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2020-12-23 at 14:52 +0100, Gilles Marivier wrote:
Le 23/12/2020 à 12:24, IOhannes m zmoelnig a écrit :
On 12/23/20 11:33 AM, Gilles Marivier wrote:
hello, thank you.
Le 23/12/2020 à 10:51, IOhannes m zmoelnig a écrit :
On 12/22/20 4:59 PM, Gilles Marivier wrote:
hello, I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1. The digital input 7 of Arduino Nano doesn't return anything.
I had a chance to test [arduino] from pduino 0.6 and it seems to still work with current FIRMATA version 2.5 from most recent Arduino IDE 1.8.13. However, I tested with an Arduino Leonardo board, since I don't own a Nano.
Regarding your problem: Is only input 7 not working? Are the other pins fine?
If you find issues, please test them against pduino version 0.6 or 0.7 and report back. I just released the latter and it will appear on Deken tomorrow. It contains only cosmetic changes and is functionally the same as 0.6.
Roman
Le 04/01/2021 à 23:24, Roman Haefeli a écrit :
On Wed, 2020-12-23 at 14:52 +0100, Gilles Marivier wrote: >> Le 23/12/2020 à 12:24, IOhannes m zmoelnig a écrit : >>> On
12/23/20 11:33 AM, Gilles Marivier wrote: >>>> hello, thank you. >>>>
Le 23/12/2020 à 10:51, IOhannes m zmoelnig a écrit : >>>>> On
12/22/20 4:59 PM, Gilles Marivier wrote: >>>>>> hello, I encounter a problem regarding Pduino 0.6 with Pd >>>>>> vanilla 0.51-1. The digital input 7 of Arduino Nano doesn't >>>>>> return anything. > > I had a chance to test [arduino] from pduino 0.6 and it seems to > still work with current FIRMATA version 2.5 from most recent Arduino > IDE 1.8.13. However, I tested with an Arduino Leonardo board, since I > don't own a Nano. > > Regarding your problem: Is only input 7 not working? Are the other > pins fine? > > If you find issues, please test them against pduino version 0.6 or > 0.7 and report back. I just released the latter and it will appear on > Deken tomorrow. It contains only cosmetic changes and is functionally > the same as 0.6. > > Roman
Hi, I'm back on the project using Pduino. I tested the new release (thanks Roman). There's still the digital input #7 problem with the Nano (168 or 368).
Problem description : although sending message "pinMode 7 input" to the [arduino] object, reading the #7 input state is impossible. There is no error message, just nothing happens.
Config :
- OSX HighSierra 10.13.6
- Pduino 0.7
- Pd 0.51.1
- Arduino Nano Atmel 168
- firmware AllInputsFirmata.ino 2 5
Tested too with :
- Arduino Nano Atmel 368
- firmware StandardFirmata.ino 2 5
Works fine with Max/MSP's [arduino] object.
_______________________________________________ Pd-list@lists.iem.at
mailing list UNSUBSCRIBE and account-management -> >
Hi Gilles
On Thu, 2021-03-18 at 12:57 +0100, Gilles Marivier wrote:
Hi, I'm back on the project using Pduino. I tested the new release (thanks Roman). There's still the digital input #7 problem with the Nano (168 or 368).
Problem description : although sending message "pinMode 7 input" to the [arduino] object, reading the #7 input state is impossible. There is no error message, just nothing happens.
Thanks for the report. I'll have a look.
Config :
- OSX HighSierra 10.13.6
- Pduino 0.7
- Pd 0.51.1
- Arduino Nano Atmel 168
- firmware AllInputsFirmata.ino 2 5
Tested too with :
- Arduino Nano Atmel 368
- firmware StandardFirmata.ino 2 5
Can you open an issue on so we don't forget and can track any ongoing development there:
https://github.com/pd-externals/pduino/issues
Works fine with Max/MSP's [arduino] object.
That's good to know.
Roman
Hi
Le 18/03/2021 à 13:57, Roman Haefeli a écrit :
Hi Gilles
On Thu, 2021-03-18 at 12:57 +0100, Gilles Marivier wrote:
Hi, I'm back on the project using Pduino. I tested the new release (thanks Roman). There's still the digital input #7 problem with the Nano (168 or 368).
Problem description : although sending message "pinMode 7 input" to the [arduino] object, reading the #7 input state is impossible. There is no error message, just nothing happens.
Thanks for the report. I'll have a look.
Config :
- OSX HighSierra 10.13.6
- Pduino 0.7
- Pd 0.51.1
- Arduino Nano Atmel 168
- firmware AllInputsFirmata.ino 2 5
Tested too with :
- Arduino Nano Atmel 368
- firmware StandardFirmata.ino 2 5
Can you open an issue on so we don't forget and can track any ongoing development there:
Done !
I forgot a point : all others pins work fine on Nano
Works fine with Max/MSP's [arduino] object.
That's good to know.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sat, 2021-03-20 at 19:24 +0100, Gilles Marivier wrote:
:
Done !
I forgot a point : all others pins work fine on Nano
Thanks, yeah, I saw it. However, I can't make any promises, though, since I don't own a Nano (in case that problem is specific to the Nano, which is not yet clear).
Roman
On Sat, 2021-03-20 at 21:53 +0100, Roman Haefeli wrote:
On Sat, 2021-03-20 at 19:24 +0100, Gilles Marivier wrote:
:
Done !
I forgot a point : all others pins work fine on Nano
Thanks, yeah, I saw it. However, I can't make any promises, though, since I don't own a Nano (in case that problem is specific to the Nano, which is not yet clear).
Ok, this particular problem is fixed in current master. It turns out the buggy code had 8 copies! So always the last pin in a group of 8 (7, 15, 23, etc.) did not return anything.
I believe this digital input mess could be done in a better, more robust way with less code duplication.
Also, with the Arduino Leonardo and Firmata 2.5, the higher numbered pins (the "analog pins") do not report with pduino when set as digital inputs.
It looks like some refactoring of that old code is warranted.
Roman
I'm not sure if I'm totally up to date here but with a nano on Windos10 I also get no pin 7 reported. ARDUINO_INFO: version 2 5 ARDUINO_INFO: firmware StandardFirmata.ino 2 5
A pin like D2 willl report: comport receives from the arduino: 144 120 1 (b01111000) (b00000001) convert_to_symbolic_commands outputs: digital 2 0 ARDUINO_OUT: digital 2 0
comport receives from the arduino: 144 124 10 (b01111100) (b00000001) convert_to_symbolic_commands outputs: digital 2 1 ARDUINO_OUT: digital 2 1
But piin 7 is like this: comport receives from the arduino: 144 124 0 (b01111100) (b00000000) comport receives from the arduino: 144 124 1 (b01111100) (b00000001)
This appears to be because the state of pin 7 is in the second data byte, which is ignored by the [pd convert_to_symbolic_commands ].
Bits 8 and up work because they are in the next port, so they appear as bits 0-7, so probably Pin 15 also doesn't work.
The code in firmatamarshaller.cpp refers to two versions: FirmataStream->write(DIGITAL_MESSAGE | (portNumber & 0xF)); // Tx bits 0-6 (protocol v1 and higher) // Tx bits 7-13 (bit 7 only for protocol v2 and higher) encodeByteStream(sizeof(portData), reinterpret_cast<uint8_t *>(&portData), sizeof(portData)); .
...so possibly pduino is not yet compatible with version2.
Martin
On Sat, Mar 20, 2021 at 6:15 PM Roman Haefeli reduzent@gmail.com wrote:
On Sat, 2021-03-20 at 21:53 +0100, Roman Haefeli wrote:
On Sat, 2021-03-20 at 19:24 +0100, Gilles Marivier wrote:
:
Done !
I forgot a point : all others pins work fine on Nano
Thanks, yeah, I saw it. However, I can't make any promises, though, since I don't own a Nano (in case that problem is specific to the Nano, which is not yet clear).
Ok, this particular problem is fixed in current master. It turns out the buggy code had 8 copies! So always the last pin in a group of 8 (7, 15, 23, etc.) did not return anything.
I believe this digital input mess could be done in a better, more robust way with less code duplication.
Also, with the Arduino Leonardo and Firmata 2.5, the higher numbered pins (the "analog pins") do not report with pduino when set as digital inputs.
It looks like some refactoring of that old code is warranted.
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Sat, 2021-03-20 at 19:24 -0400, Martin Peach wrote:
[...]
...so possibly pduino is not yet compatible with version2.
Thanks for having a look as well. The culprit was:
[mod 128] | [div 128]
cannot ever return 1. It should have been:
[mod 256] | [div 128]
in 8 subpatches of [pd digital_messages].
Roman
On Thu, 2021-03-18 at 12:57 +0100, Gilles Marivier wrote:
Problem description : although sending message "pinMode 7 input" to the [arduino] object, reading the #7 input state is impossible. There is no error message, just nothing happens.
I just uploaded a slightly revamped version as version 0.8 that also includes the fix for input 7 not reporting. You should soon find it in Deken.
Roman
Em qua., 23 de dez. de 2020 às 08:27, IOhannes m zmoelnig zmoelnig@iem.at escreveu:
it seems that since alex has taken over cyclone, the extra inlet of [prepend] has vanished. i don't know enough about Max/MSP to know, whether this change was done to enforce stricter compatibility between the two runtimes.
I honestly don't remember, since we've done so much and it's been almost 5 years we've started doing this. Looking at the available and very extensive changelog, I see:
"
- [append] - fixed useless inlet bug, bang behaviour and symbol input
- [prepend] - fixed useless inlet bug, bang behaviour
"
Now, trying to reconstruct what happened and what this means, this is my bet.
I looked over the old examples (pre 0.3) and saw no mentioning of a second inlet in the documentation of cyclone/Append, and this inlet only shows up when no argument is given, which is weird. Moreover, yeah, that's not how the original max object works and the documentation seemed to just be a copy from Max, so I seem to have considered it "useless" as the documentation (besides not showing or mentioning there could be a second inlet) shows how to set the object without the second inlet via the 'set' message (with or without arguments). So it really felt to me like a bug, not a feature.
I see now the old examples do mention this about 'prepend', but I started alphabetically revising all objects (code, behaviour, finding bugs, checking against max) and, at one point, I just started rewriting all the documentation from scratch as it was faster/better, and there were just too much problems and errors with the old documentation.
I also realized at one point that cyclone was first provided without any documentation and the first ones that appeared were not written by the original author and were just copied from max anyway... So I missed this when I got to prepend and maybe thought it was the same issue. The source code wasn't really clear about this either. Checking 'prepend' I saw a weird "iscompatible" flag and some comments that there was some incompatibilities checked on the object over max and that it should be fixed (Append's code had no comments about it). So yeah, I went on and fixed it... considering it a bug, not a feature, and as with every changes and bug fixes we've made, I put it into the changelog.
anyhow: to solve your problem, you can:
- use the old cyclone
- ask alex to re-introduce the 2nd inlet
- replace [cyclone/prepend] with [list prepend] (plus the occasional
[list/trim]).
Or adapt the patch and use the 'set' message.
But yeah, I can gladly restore this "functionality" and document it for the next release if anyone believes it's important.
Cheers
gfmasd IOhannes
[1] http://puredata.info/community/lists/Netiquette
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2020-12-23 at 17:24 -0300, Alexandre Torres Porres wrote:
But yeah, I can gladly restore this "functionality" and document it for the next release if anyone believes it's important.
Just for the sake of pduino, I wouldn't bother. There is no good reason to use [prepend] and version 0.6 doesn't use it anyway. Let's fix what is worth fixing and not put effort in restoring functionality of out- dated versions.
Roman
Em qua., 23 de dez. de 2020 às 18:10, Roman Haefeli reduzent@gmail.com escreveu:
Just for the sake of pduino, I wouldn't bother.
Ok, yeah, but it would be only because of the backwards compatibility issue reported here by itself. And it bothers me cause I fear there's this image of me where people can think "Alex will break backwards compatibility to favor max compatibility" and that is not true :) Keeping backwards compatibility is a thing for us and I've said it many times and even put it in cyclone's readme. If there's an issue, if something broke - and that can happen unintentionally - please report. As I explained, this was considered a bug and was an unintentional breakage. I missed the fact that it was documented in prepend's old documentation and that was a mistake. Once you document it, you have to keep it or at least mention you changed it.
And checking purr data's cyclone/prepend, it's even more confusing. It's an abstraction (for some reason) and that just keeps the second inlet with or without arguments, even though its documentation says it's there only if there's no argument.
Well, I'm thinking that the best way to clear up this mess now is to just add and keep the second inlet for all cases and put a note this second inlet in Append and prepend is not compatible to Max. It'd be easier to document it also and it's a less stupid design. By the way, there are other objects in cyclone that do have the same remark of some inconsistencies regarding max compatibility, and even, although rarely, added functionality. I'm openly not a fan of that, but I don't care enough to make a case for it, so I kept it and documented it. I'm just saying this cause, again, I don't want people reinforcing the idea cyclone is now deliberately and mercilessly breaking stuff ;)
cheers
Le 23 déc. 2020 à 22:01, Roman Haefeli reduzent@gmail.com a écrit :
On Wed, 2020-12-23 at 17:24 -0300, Alexandre Torres Porres wrote:
But yeah, I can gladly restore this "functionality" and document it for the next release if anyone believes it's important.
Just for the sake of pduino, I wouldn't bother. There is no good reason to use [prepend] and version 0.6 doesn't use it anyway. Let's fix what is worth fixing and not put effort in restoring functionality of out- dated versions.
My intention is to manage things to use latest and « vanillaest » things. So let’s fix problem using Pduino0.6 (and pd vanilla).
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Tue, 2020-12-22 at 16:59 +0100, Gilles Marivier wrote:
I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1
On Wed, 2020-12-23 at 11:33 +0100, Gilles Marivier wrote:
route 13 0 20 1 (message->prepend) connection failed route 14 0 20 1 (message->prepend) connection failed route 16 0 20 1 (bang->prepend) connection failed route 17 0 20 1 (bang->prepend) connection failed
What you tell us is a contradiction. Pduino 0.6 doesn't use any object [prepend]. Either you are using not Pduino 0.6 or your reports are from different tests. Anyway, it's important to mention such errors as above. Those are critical and as IOhannes said the object is very unlikely to work without addressing those errors.
Roman
Le 23/12/2020 à 14:53, Roman Haefeli a écrit :
On Tue, 2020-12-22 at 16:59 +0100, Gilles Marivier wrote:
I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1
On Wed, 2020-12-23 at 11:33 +0100, Gilles Marivier wrote:
route 13 0 20 1 (message->prepend) connection failed route 14 0 20 1 (message->prepend) connection failed route 16 0 20 1 (bang->prepend) connection failed route 17 0 20 1 (bang->prepend) connection failed
What you tell us is a contradiction. Pduino 0.6 doesn't use any object [prepend]. Either you are using not Pduino 0.6 or your reports are from different tests. Anyway, it's important to mention such errors as above. Those are critical and as IOhannes said the object is very unlikely to work without addressing those errors.
Roman
This was an answer to the question "and have you tried pduino 0.5 with Pd-vanilla 0.51-1? " IOhannes asked.
I rechanged the subject to stick with IOhannes' and your suggestions. Is it ok now ?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Wed, 2020-12-23 at 15:10 +0100, Gilles Marivier wrote:
Le 23/12/2020 à 14:53, Roman Haefeli a écrit :
On Tue, 2020-12-22 at 16:59 +0100, Gilles Marivier wrote:
I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1
On Wed, 2020-12-23 at 11:33 +0100, Gilles Marivier wrote:
route 13 0 20 1 (message->prepend) connection failed route 14 0 20 1 (message->prepend) connection failed route 16 0 20 1 (bang->prepend) connection failed route 17 0 20 1 (bang->prepend) connection failed
What you tell us is a contradiction. Pduino 0.6 doesn't use any object [prepend]. Either you are using not Pduino 0.6 or your reports are from different tests. Anyway, it's important to mention such errors as above. Those are critical and as IOhannes said the object is very unlikely to work without addressing those errors.
Roman
This was an answer to the question "and have you tried pduino 0.5 with Pd-vanilla 0.51-1? " IOhannes asked.
I see. I'm not so interested in fixing 0.5, since the goal of creating 0.6 was exactly to get rid of many externals and making installing Pduino a bit easier.
Do you see any messages in the Pd console when loading [pduino] from the 0.6 release?
I rechanged the subject to stick with IOhannes' and your suggestions. Is it ok now ?
Looks good.
Roman
On Tue, 2020-12-22 at 16:59 +0100, Gilles Marivier wrote:
I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1. The digital input 7 of Arduino Nano doesn't return anything. Here are my tests :
- tried with different Nano boards : nothing changed
- tried differents versions of Firmata : nothing changed
- tried to read inputs with Max/MSP and Processing digital input 7 :
the two softs return the good value
- tried my Pd patch with Pduino 0.5 and Pd-Extended : all is fine,
d7 return the good value
Any messages in the Pd-console?
Roman
Le 23 déc. 2020 à 22:08, Roman Haefeli reduzent@gmail.com a écrit :
On Tue, 2020-12-22 at 16:59 +0100, Gilles Marivier wrote:
I encounter a problem regarding Pduino 0.6 with Pd vanilla 0.51-1. The digital input 7 of Arduino Nano doesn't return anything. Here are my tests :
- tried with different Nano boards : nothing changed
- tried differents versions of Firmata : nothing changed
- tried to read inputs with Max/MSP and Processing digital input 7 :
the two softs return the good value
- tried my Pd patch with Pduino 0.5 and Pd-Extended : all is fine,
d7 return the good value
Any messages in the Pd-console?
As far as I need à break, I will restart debugging the problem on the 5th of january. Thank you all, and greetings, enjoy with your family /friends
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Christof Ressi -
Gilles -
Gilles Marivier
-
IOhannes m zmoelnig -
marco -
Martin Peach -
Roman Haefeli