Hi,
my few words/facts/comments on the subject:
- forum & list: yes, there is less activity on the
forum but still a nice place to dig into. Sometimes you
can find amazing stuff there ;-)
2) PD "life-form" is the mailing list.
3) The list activity is purely technical for the 80% of
the mail. To me, I'd like to see more posts with user
creations, arts (something like the Reaktor user library, if
you know it..)
4) This "too much technical topics" may deconcentrate
the newbie (at least it was for me the first time I
subscribed some time ago..) which at the end may want
to see examples of what can be done with PD before starting
learning it...
5) One can find WONDERFUL examples of PD patches
around the web (pd webring and other) instead of having a
unique resource.
On the other side: we cannot blame people that
do their best for keeping this site alive on a
voluntary basis (thanks guys!) and I suppose that
there is no people paid for full-time managing the
PD.info site like in other commercial cases (who said
cycling74? ;-)
The consequence of this is that it will make the PD
learning curve a bit steeper but if one is
seriously motivated at the end he/she'll find his own way...
Just thinking.
All the best,
Alberto Zin
Hi, Ive come up with a way to parse out packets from a serial datastream that works but is possibly the ugliest thing Ive ever done and Id wonder about its resilience. If anyone could have a look and advise a better way of doing this I'd really appreciate it. Essentially each packet of the data looks like so 7E 42 FF FF 06 7D 5D 0D 01 XX XX XX XX XX XX XX XX XX XX XX XX CRC CRC
where the first XX XX represents a 10-bit ADC value in little endian format (LSB MSB) from sensor 1. There are 6 sensors in total.
I put together a patch based on searching for 7e 42 FF FF. 7E and FF will never appear in the data part Im promised.
I have no control over the data stream format as thats handled by another guy.
Anyway my approach uses [route] and loads of [spigot] to look for the 7E 42 FF FF and when it finds it bang a [repack] that has been "buffering" the data. That goes to [unpack] to unpack the bytes.
Any pointers to a nicer way would be great. Ive attached the monster. Thanks Nick
Check out arduino-test.pd and arduino.pd, there is a two-way protocol
that is parsed in Pd:
http://pure-data.cvs.sourceforge.net/pure-data/externals/hardware/ arduino
.hc
On Oct 16, 2006, at 4:22 PM, nward04@qub.ac.uk wrote:
Hi, Ive come up with a way to parse out packets from a serial
datastream that works but is possibly the ugliest thing Ive ever
done and Id wonder about its resilience. If anyone could have a look and advise a better way of doing this
I'd really appreciate it. Essentially each packet of the data looks like so 7E 42 FF FF 06 7D 5D 0D 01 XX XX XX XX XX XX XX XX XX XX XX XX CRC CRCwhere the first XX XX represents a 10-bit ADC value in little
endian format (LSB MSB) from sensor 1. There are 6 sensors in total.I put together a patch based on searching for 7e 42 FF FF. 7E and
FF will never appear in the data part Im promised.I have no control over the data stream format as thats handled by
another guy.Anyway my approach uses [route] and loads of [spigot] to look for
the 7E 42 FF FF and when it finds it bang a [repack] that has been
"buffering" the data. That goes to [unpack] to unpack the bytes.Any pointers to a nicer way would be great. Ive attached the monster. Thanks Nick
<serial2.pd> _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom
-
alberto.zin＠poste.it -
Hans-Christoph Steiner -
nward04＠qub.ac.uk