[PD] frozen GUI

2011-06-14 Thread Jeppi Jeppi

Hi all,
I know this is quite a recurrent topic...we are having serious issues with PD 
under Windows. The GUI gets frozen after 15-30min working, possibly due to 
excess of GUI updates, though not sure about that. The audio thread works and 
operating with the GUI is still possible, though with no visual feedback.
Would it be a way to overcome that, or to relaunch/reconnect whatever the GUI 
alone, without having to restart PD?
If removing GUI updates to hidden abstractions might help, I would patienlly 
remove them all...

Thanks in advance
Josep M
  ___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] frozen GUI

2011-06-14 Thread IOhannes m zmoelnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-06-14 10:52, Jeppi Jeppi wrote:
 
 Hi all,
 I know this is quite a recurrent topic...we are having serious issues with PD 
 under Windows. The GUI gets frozen after 15-30min working, possibly due to 
 excess of GUI updates, though not sure about that. The audio thread works and 
 operating with the GUI is still possible, though with no visual feedback.
 Would it be a way to overcome that, or to relaunch/reconnect whatever the GUI 
 alone, without having to restart PD?
 If removing GUI updates to hidden abstractions might help, I would patienlly 
 remove them all...

the problem with recurrent issues is, that it is hard to tell whether
they are really appearing again (that is: in new versions of Pd) or
only still appearing (in versions that are known to exhibit the problem)

in order to let us know more:
- - which version of Pd are you using?
- - have you used a _recent_ (e.g. 0.43) version of Pd?

fmaer
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk33L1QACgkQkX2Xpv6ydvRYJACdGwdahOP0BkqnPpIXLbC3jVuh
paAAoLHpABNjFlO7z8+SjCVdmR6xsOC4
=L1D6
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] frozen GUI

2011-06-14 Thread Jeppi Jeppi

Thanks IOhannes,
well I use PD extended 0.42.5 under Windows 7.
The pach has the default GUI elements with intensive updates of their state 
from OSC, both via sends, sets and color updates.

Josep M

Date: Tue, 14 Jun 2011 11:52:23 +0200
From: zmoel...@iem.at
To: pd-list@iem.at
Subject: Re: [PD] frozen GUI

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
On 2011-06-14 10:52, Jeppi Jeppi wrote:
 
 Hi all,
 I know this is quite a recurrent topic...we are having serious issues with PD 
 under Windows. The GUI gets frozen after 15-30min working, possibly due to 
 excess of GUI updates, though not sure about that. The audio thread works and 
 operating with the GUI is still possible, though with no visual feedback.
 Would it be a way to overcome that, or to relaunch/reconnect whatever the GUI 
 alone, without having to restart PD?
 If removing GUI updates to hidden abstractions might help, I would patienlly 
 remove them all...
 
the problem with recurrent issues is, that it is hard to tell whether
they are really appearing again (that is: in new versions of Pd) or
only still appearing (in versions that are known to exhibit the problem)
 
in order to let us know more:
- - which version of Pd are you using?
- - have you used a _recent_ (e.g. 0.43) version of Pd?
 
fmaer
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAk33L1QACgkQkX2Xpv6ydvRYJACdGwdahOP0BkqnPpIXLbC3jVuh
paAAoLHpABNjFlO7z8+SjCVdmR6xsOC4
=L1D6
-END PGP SIGNATURE-
 

___
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] frozen GUI

2011-06-14 Thread IOhannes m zmoelnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-06-14 12:24, Jeppi Jeppi wrote:
 
 Thanks IOhannes,
 well I use PD extended 0.42.5 under Windows 7.


ok.
could you try a 0.43 build and see what happens.
note that some people think, that 0.43 is not ready for prime-time, so
you probably don't want to overwrite your existing installation, but
install besides it.

fgmasdr
IOhannes



___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management -
http://lists.puredata.info/listinfo/pd-list 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk33N/AACgkQkX2Xpv6ydvT5OgCg3TiZTMjNKfCED4n8ZqW7T5KP
lsUAoMftJY45yD2jVum+rwmwAwV99/Xa
=tzio
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] arduino weirdnesses

2011-06-14 Thread Matteo Sisti Sette

Hi,

I'm using and arduino UNO with StandardFirmata and the [arduino] 
abstraction and the arduino-test.pd test patch.


When I open the connection, at random times some of the following things 
happen:


- sometimes the ver subpatch (the one with blue gop just under pd 
device info) appears empty instead of showing the usual Firmata-2.2


- sometimes on the console I get the firmware message twice, and one of 
the times it is messed up, like:

Firmware: Stá-2.2
Firmware: StandardFirmata_2_2_forUNO_0_3-2.2

-sometimes I get this error on the console:

And of course, most of the times everything works fine.

This looks like there are being transmission errors on the serial line, 
doesn't it?

Doesn't it use any error correction?

Or is it something else?

I always close the connection before I try opening it again, and I'm 
doing this all with the arduino-test.pd patch.


Thanks
m.

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] ardino open message and version

2011-06-14 Thread Matteo Sisti Sette

Hi,

Digging into the [arduino] abstraction I've noticed that it seems to 
assume that [flatspace/comport] will output a open 1 message when the 
connection is open, but that never happens.


There is a pd report firmware version connected to comport's right 
outlet that does the following:


[inlet]
 |
[route open]
 |
[select 1]
 |
[delay 2000]
 |
[version(
 |
[outlet]

and that's sent back to [pd command processing], as if that was used to 
ask the arduino for its version when the opening of the connection is 
detected. However, that does never happen because the open message 
never comes from comport's right outlet in the first place.


However I do see the firmware version message on the console. So I'm 
guessing that the arduino outputs it when it gets connected, on its own 
initiative, without being asked. Is that right? Or is that triggered 
from somewhere else?


The only thing coming out from flatspace/comport's right outlet seems to 
be a -1 when the connection is closed.


By the way I now see that the help patch for comport also has a [route 
open] (among other messages) on its right outlet, so maybe it is 
actually a bug in [comport] not outputting the open message?


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

2011-06-14 Thread Matteo Sisti Sette

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

2011-06-14 Thread Ingo
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] ardino open message and version

2011-06-14 Thread Martin

On 14/06/11 10:05 AM, Matteo Sisti Sette wrote:

Hi,

Digging into the [arduino] abstraction I've noticed that it seems to 
assume that [flatspace/comport] will output a open 1 message when 
the connection is open, but that never happens.


There is a pd report firmware version connected to comport's right 
outlet that does the following:


[inlet]
 |
[route open]
 |
[select 1]
 |
[delay 2000]
 |
[version(
 |
[outlet]

and that's sent back to [pd command processing], as if that was used 
to ask the arduino for its version when the opening of the connection 
is detected. However, that does never happen because the open 
message never comes from comport's right outlet in the first place.


However I do see the firmware version message on the console. So I'm 
guessing that the arduino outputs it when it gets connected, on its 
own initiative, without being asked. Is that right? Or is that 
triggered from somewhere else?


The only thing coming out from flatspace/comport's right outlet seems 
to be a -1 when the connection is closed.


By the way I now see that the help patch for comport also has a [route 
open] (among other messages) on its right outlet, so maybe it is 
actually a bug in [comport] not outputting the open message?




Or maybe you don't have a recent [comport]. It should output a list of 
things when you send it a [info( message, one of which is 'open'.


Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] pix_film can't open almost any file after upgrading to Ubuntu 10.10

2011-06-14 Thread Matteo Sisti Sette

Hi,

I've recently upgraded ubuntu 10.04 to 10.10, and I had to uninstall 
pd-extended and reinstalled the new package for 10.04.


After that, pix_film crashes when I try to open many video files that I 
used to be able to open without issues.


It crashes with a few MOV files encoded with mjpeg but doesn't crash 
with some other AVI files also encoded with mjpeg (don't know if it was 
the exact same codec or not) (all these are files it used to be able 
open), and so far it crash with ANY new file that I have tried to encode 
with ffmpeg, with avidemux, both mov and avi and with several different 
codecs. I can't find any format I can generate with ffmpeg or avidemux 
that pix_film will open without crashing.


Has anyone experienced anything similar?
I'm desperate, as this breaks almost all the patches I was working on 
and I can't seem to find even a workaround, such as recoding all videos 
to a format that would work.


Just hoping someone has had a similar issue and figured out what got 
broken when upgrading to 10.10...


This is Pd Extended 0.42.5 which has Gem 0.92.3, as it ships in the 
Package for Ubuntu 10.10 downloaded from puredata.info.


Needless to say I can open these files in just any other software other 
than Pd.


Thanks in advance
m.

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pix_film can't open almost any file after upgrading to Ubuntu 10.10

2011-06-14 Thread Matteo Sisti Sette

On 06/14/2011 06:59 PM, Matteo Sisti Sette wrote:

I've recently upgraded ubuntu 10.04 to 10.10, and I had to uninstall
pd-extended and reinstalled the new package for 10.04.
After that, pix_film crashes when I try to open many video files that I
used to be able to open without issues.


Ok it turns out it is libquicktime which is broken (thanks IOHannes for 
pointing that out).


Unfortunately the latest version from CVS is equally broken.

Does anybody know of a version of libquicktime that doesn't always crash 
on Ubuntu 10.10 and how can I get that particular version?


thanks
m.

___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] frozen GUI

2011-06-14 Thread Ivica Ico Bukvic
You can download disis_netsend/receive and other externals directly from the 
l2ork page I posted in my last email (just click on join l2orkmania and then 
on software and it should work with any flavor of pd. It is also a drop-in 
replacement for vanilla netsend/receive.

HTH

P.S. Many thanks for the kind words regarding NIME performance!

Best wishes,

Ico

Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound  Intermedia Studio
Director, L2Ork LinuxLaptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Department of Music
Blacksburg, VA 24061-0240
(540) 231-6139
(540) 231-5034 (fax)
disis.music.vt.edu
l2ork.music.vt.edu
ico.bukvic.net

Jeppi Jeppi jepp...@hotmail.com wrote:

Hi!
Many thanks...
By the way, nice performance@NIME, I was there. Great drummer, and nice 
ensemble!
Yep, we use massive networking (I conduct another laptop orchestra, from 
Barcelona).
We currently use Windows for the servers (because of soundcard driver 
availability)...is that netsend external available for it? Otherwise I'll check 
it during the summer, but not for our very next performance which is in two 
days...

Josep M

_
From: i...@vt.edu
To: jepp...@hotmail.com
Subject: RE: [PD] frozen GUI
Date: Tue, 14 Jun 2011 14:55:19 +0200

Are you using any networking?

 

If so, I encountered similar problems with gui updates in our l2ork setup where 
netreceive’s polling function (afaik) dispatches message at any time regardless 
of when the gui thread is taking place. Consequently, in pd-l2ork (Linux only 
at this point) there are changes in core architecture to address this including 
disis_netsend/netreceive external that, apart from broadcast and other 
features, also ensures that incoming messages always are dispatched within the 
gui update thread.

 

http://l2ork.music.vt.edu/main/ (click on Software link)

 

HTH

 

ico

 

_

From: pd-list-boun...@iem.at [mailto:pd-list-boun...@iem.at] On Behalf Of Jeppi 
Jeppi
Sent: Tuesday, June 14, 2011 10:53 AM
To: pd-list@iem.at
Subject: [PD] frozen GUI

 

Hi all,
I know this is quite a recurrent topic...we are having serious issues with PD 
under Windows. The GUI gets frozen after 15-30min working, possibly due to 
excess of GUI updates, though not sure about that. The audio thread works and 
operating with the GUI is still possible, though with no visual feedback.
Would it be a way to overcome that, or to relaunch/reconnect whatever the GUI 
alone, without having to restart PD?
If removing GUI updates to hidden abstractions might help, I would patienlly 
remove them all...

Thanks in advance
Josep M

 ___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pix_film can't open almost any file after upgrading to Ubuntu 10.10

2011-06-14 Thread IOhannes m zmoelnig
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2011-06-14 19:43, Matteo Sisti Sette wrote:
 On 06/14/2011 06:59 PM, Matteo Sisti Sette wrote:
 I've recently upgraded ubuntu 10.04 to 10.10, and I had to uninstall
 pd-extended and reinstalled the new package for 10.04.
 After that, pix_film crashes when I try to open many video files that I
 used to be able to open without issues.
 
 Ok it turns out it is libquicktime which is broken (thanks IOHannes for
 pointing that out).
 
 Unfortunately the latest version from CVS is equally broken.
 

since libquicktime (1.2.2) is fine here on debian. the problem might
come from something else, e.g. some 3rd party library lqt is using.

you should run a a test in gdb and do a backtrace:

$ gdb --args lqtplay /path/to/broken/file
(gdb) run
Segmentation faul
(gdb) bt
snip
...
/snip
(gdb)

and post everything between snip and /snip.
preferrably (also) to some quicktime-related bugtracker (or ubuntu's)

fgmadr
IOhannes
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk33p+kACgkQkX2Xpv6ydvR+jwCg78fGVCjZcFjkAx1D4TEZCcxA
SmkAoISSU7PILAp/QGjrc388qllGqFQc
=kgLx
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


[PD] Another arduino weirdness

2011-06-14 Thread Matteo Sisti Sette

Hi,

With this:

[arduino]
   |
  [print ARDUINO]

On Linux, when I open the connection, it prints:
ARDUINO: version 2 2
ARDUINO: StandardFirmata_2_2_forUNO_0_3 2 2
ARDUINO: firmware StandardFirmata_2_2_forUNO_0_3 2 2

On Windows (with the very same arduino board), it doesn't print anything!!

Yet everything else works and I do get the data messages from the left 
inlet of arduino!


How can that be


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] pix_film can't open almost any file after upgrading to Ubuntu 10.10

2011-06-14 Thread Matteo Sisti Sette

On 06/14/2011 08:26 PM, IOhannes m zmoelnig wrote:


Unfortunately the latest version from CVS is equally broken.


I wrote this after installing it and trying in Gem, but I hadn't tried 
lqtplay.


Now lqtplay doesn't crash any more, it says it can't find libquicktime!!

lqtplay: error while loading shared libraries: libquicktime.so.0: cannot
open shared object file: No such file or directory


So my guess is that the version from CVS didn't install properly 
(thought it didn't report any error while configuring, making, nor 
installing) and that Gem is still using the version that used to crash 
and keeps crashing...




___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Another arduino weirdness

2011-06-14 Thread Matteo Sisti Sette

On 06/14/2011 09:58 PM, Matteo Sisti Sette wrote:

Hi,

With this:

[arduino]
   |
  [print ARDUINO]

On Windows (with the very same arduino board), it doesn't print anything!!



Nothing is even coming out from [comport] when the connection is 
established (in Windows)!! (but it does print things when data messages 
are received, such as digital pin data)


It's as if the arduino itself was actually behaving differently on 
different platforms...


or maybe [comport]. But why would [comport] drop some specific messages? 
It doesn't even know about messages, right? It only sees incoming 
bytes, doesn't it?



I thought I would post the output from [comport] when connecting the 
arduino, on Windows and on Linux, but it is not always the same. Even if 
opening a freshly reset arduino (i.e. just after connecting it to the 
usb port, and without any extra circuitry), the output from [comport] is 
not always the same.


Furthermore, it seems it is sending digital pin data messages (which may 
happen randomly since no pin is connected to anything) even if it has 
never received any pìnMode message. Is that expected behavior?


And occasionally I get an UNKNOWN_INPUT_COMMAND: 1 505





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Another arduino weirdness

2011-06-14 Thread Martin

On 14/06/11 04:44 PM, Matteo Sisti Sette wrote:

On 06/14/2011 09:58 PM, Matteo Sisti Sette wrote:

Hi,

With this:

[arduino]
   |
  [print ARDUINO]

On Windows (with the very same arduino board), it doesn't print 
anything!!




Nothing is even coming out from [comport] when the connection is 
established (in Windows)!! (but it does print things when data 
messages are received, such as digital pin data)


It's as if the arduino itself was actually behaving differently on 
different platforms...


or maybe [comport]. But why would [comport] drop some specific 
messages? It doesn't even know about messages, right? It only sees 
incoming bytes, doesn't it?




Well maybe you have different versions of [comport]. The 'open' message 
is output after the [comport] object receives an [info( message from 
within the Pd patch: it's not related to the arduino.




I thought I would post the output from [comport] when connecting the 
arduino, on Windows and on Linux, but it is not always the same. Even 
if opening a freshly reset arduino (i.e. just after connecting it to 
the usb port, and without any extra circuitry), the output from 
[comport] is not always the same.


Furthermore, it seems it is sending digital pin data messages (which 
may happen randomly since no pin is connected to anything) even if it 
has never received any pìnMode message. Is that expected behavior?




Pins default to input. You can often change unconnected pins by moving 
your charge-carrying body parts near them.


Martin


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Another arduino weirdness

2011-06-14 Thread Matteo Sisti Sette

On 06/14/2011 11:01 PM, Martin wrote:

On 14/06/11 04:44 PM, Matteo Sisti Sette wrote:

On 06/14/2011 09:58 PM, Matteo Sisti Sette wrote:

Hi,

With this:

[arduino]
   |
  [print ARDUINO]





Well maybe you have different versions of [comport]. The 'open' message
is output after the [comport] object receives an [info( message from
within the Pd patch: it's not related to the arduino.


Yes that accounts for the open message which would come from 
[comport]'s right outlet.


But there are other messages sent by the arduino, such as the ones 
reporting the firmware version, which are being lost.



I've found out that if I send the arduino the version message, then 
these messages _are_ received (also in Windows), while when the Arduino 
send them just after connecting, they are lost in Windows.


So I think there must be an issue either in the Windows version of 
[comport] or in the Windows drivers, that if a message is received too 
soon after connecting, it is lost.


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Another arduino weirdness

2011-06-14 Thread Martin Peach

On 2011-06-14 17:45, Matteo Sisti Sette wrote:

On 06/14/2011 11:01 PM, Martin wrote:

On 14/06/11 04:44 PM, Matteo Sisti Sette wrote:

On 06/14/2011 09:58 PM, Matteo Sisti Sette wrote:

Hi,

With this:

[arduino]
|
[print ARDUINO]





Well maybe you have different versions of [comport]. The 'open' message
is output after the [comport] object receives an [info( message from
within the Pd patch: it's not related to the arduino.


Yes that accounts for the open message which would come from
[comport]'s right outlet.

But there are other messages sent by the arduino, such as the ones
reporting the firmware version, which are being lost.


I've found out that if I send the arduino the version message, then
these messages _are_ received (also in Windows), while when the Arduino
send them just after connecting, they are lost in Windows.

So I think there must be an issue either in the Windows version of
[comport] or in the Windows drivers, that if a message is received too
soon after connecting, it is lost.




Yes I've run into that with arduino on MacOSX; the arduino bootloader is 
active for about 5 seconds after power-up, or whenever the port is 
opened if you are powering it via USB, so you have to be careful not to 
send anything through the serial port in the first 5 seconds or the 
arduino will interpret it as an incoming program.


Martin





___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] Another arduino weirdness

2011-06-14 Thread Matteo Sisti Sette

On 06/15/2011 12:57 AM, Martin Peach wrote:


I've found out that if I send the arduino the version message, then
these messages _are_ received (also in Windows), while when the Arduino
send them just after connecting, they are lost in Windows.

So I think there must be an issue either in the Windows version of
[comport] or in the Windows drivers, that if a message is received too
soon after connecting, it is lost.




Yes I've run into that with arduino on MacOSX; the arduino bootloader is
active for about 5 seconds after power-up, or whenever the port is
opened if you are powering it via USB, so you have to be careful not to
send anything through the serial port in the first 5 seconds or the
arduino will interpret it as an incoming program.



But I'm talking about the opposite direction. Messages sent from the 
Arduino to the computer immediately after the connection is established,


1. I connect the arduino physically, and wait several seconds, so it is 
already powered on and running StandardFirmata

2. In Pd I send the message open 0 to the [arduino] object

In linux:
[comport]'s left outlet outputs some data coming from the arduino, which 
happen to be the messages telling the firmware version and such


In windows:
[comport]'s left outlet doesn't output anything.


So my guess is that the Arduino board, as soon as the connection is 
established from Pd, immediately sends data. In Linux this data is 
received and output by [comport], in Windows it is lost.

I'm talking about data sent from Arduino to the computer, not viceversa.

My guess may be entirely wrong, of course. It's just the only 
explanation I can think of.



Note that these messages that the arduino sends (immediately after 
opening the connection through comport) are NOT being triggered by 
anything being sent by the [arduino] abstraction to the arduino board 
through [comport].



A possible explanation, now that I think about it, may be that the 
Arduino board does not send the firmware version every time a connection 
is established, but every time it is reset, and for some reason (due to 
differences in the way drivers work) establishing the connection from Pd 
in Limux triggers an Arduino reset while establishing the connection 
from Pd in Windows does not.


Is it so?

O, it may be relevant (though I don't directly see how) that 
when I test on Windows I do it through a virtual machine (on a linux 
host which is the one on which i test it in Linux).


___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list


Re: [PD] A bit of generative patching

2011-06-14 Thread Jeffrey Concepcion
Did you check out the patchwerk radio site? it streams generative patches
24/7 for 10 mins each. http://radio.rumblesan.com:8000/radio.ogg . Here's my
contribution, tell me what you think.

Jeff

On Sat, Jun 11, 2011 at 3:57 PM, Pierre Massat pimas...@gmail.com wrote:

 I like it a lot. I don't know anything about generative music. This is all
 pseudo-randomly created, right? It can't be played twice, right? And all
 these moments will be lost in time, like tears in the rain, the replicant
 said. Never thought about it before, now i like the idea.
 Thanks a lot for sharing!

 Pierre

 2011/6/11 Andrew Faraday jbtur...@hotmail.com

  Hey Guys

 Just came across this Pd lesson on youtube...

 http://www.youtube.com/watch?v=ojO6woTngG8

 It inspired me to get back on Pd (having not used it in a while) and
 modify the ideas he's throwing around into my own patch.

 This could quite possibly be the finest piece of single-canvas generative
 patching I've ever done, made in the space of about an hour. As ever any
 comments or suggestions would be welcome.

 Let me know what you think

 Andrew Faraday

 ___
 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




-- 
www.epicjefferson.com
www.avmachinists.org Puerto Rico based Art Collective/ Non-Profit Org


Epic_Jeffersons_Craze.rar
Description: application/rar
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management - 
http://lists.puredata.info/listinfo/pd-list