Hi all,
This is a little PD abstraction I made out of Dan`s patch. Thanks for the help in decoding that list of floats. Now I see why serial lines of fixed length is easier than variable length !
In the tarball, there is also a screenshot of the blueCUI output using comport, as requested by Thomas. (maybe too late now, as it works perfectly now) It is a screenshot as there is no obvious way to copy-paste the PD window`s output in OSX.
Also, comport is still using much of the CPU. Maybe a lower data rate would be suitable.
regards, aalex
On 6/17/06, Dan Overholt dano@create.ucsb.edu wrote:
all right, there's an updated version of the PD patch for the Bluetooth CUI on the website now, including the digital inputs: http://www.create.ucsb.edu/~dano/CUI/CUIBTPDtest.pd
using the AND operator in PD seems to be _very_ inneffecient though, if anyone has a better idea, let me know!
-Dan
On Fri, 16 Jun 2006, Hans-Christoph Steiner wrote:
To get bits, use the standard bitwise operators, just like C or many other languages. Pd has the whole suite: & | >> <<
To get the value of a bit, AND it by that bit's value, i.e. the 4th bit would be [& 16]
.hc
On Jun 16, 2006, at 2:00 PM, Dan Overholt wrote:
Hi All,
I've put up an example of using the Bluetooth CUI with PD here: http://www.create.ucsb.edu/~dano/CUI/CUIBTPDtest.pd
The only question is how to get at the individual bits within the last 2 received bytes to decode the digital inputs from the CUI. In Max/MSP, there is an 3rd party external called [bit] that does this... any suggestions?
All the best, -Dan
-- Dan Overholt -- http://www.create.ucsb.edu/~dano Center for Research in Electronic Art Technology, UCSB
On Fri, 16 Jun 2006, Alexandre Quessy wrote:
Hello Pure Data friends,
We are currently trying to make the Bluetooth CUI work with PD.
The Bluetooth Create Usb Interface is the wireless version of the USB CUI, a 13 analog/10 bits and 12 digital I/O interface for sensors. The BTCUI is perfect for embbeded applications like dance, performance, music etc. It's one of the cheapest and smallest wireless interface on the market, and it is Open Hardware !
The USB CUI works all right with PD, with HID tools. We use the [hid] external from PD-Extended 0.39.RC4 (on Mac).
Unfortunately, we didn't succeeded to make the BluetoothCUI working with PD. We have tried [comport] and [hid]. The BTCUI works perfectly on Max/MSP (demo version), as announced by Dan Overholt, its creator. His patch is downloadable at http://www.create.ucsb.edu/~dano/CUI/BlueCUItestRev2.zip and uses the [serial] object of Max/MSP.
The protocol of the CUI is probably similar to the one used by joysticks and such. It consists in a serie of integers with delimiters, the several remaining integers beings the values that the device sends to the computer. See the attached PD patches. Below are out two PD patches. The first one uses [hid] and works with the USB CUI, but not over BlueTooth. (Apple does serial port emulation) The second uses [comport] and almost work. The CUI LED lights up, so it means that it is sending data, but most often, dumping the data from [comport]'s outlet give us nothing.
Would you have any idea of what is missing to imitate, and make even better than the [serial] Max/MSP object ? Otherwise, would it be easier on Linux ?
JN and
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-- Dan Overholt -- http://www.create.ucsb.edu/~dano Center for Research in Electronic Art Technology, UCSB
How about creating externals/hardware/cui in CVS and adding this there?
As for the usage of CPU, because its a fast bitrate, it will always
use a noticeable amount of CPU time. Mouse data is another example
of a high-speed data stream. IIRC, a lot of mouse pointer processing
is handled by the graphics card for this reason.
.hc
On Jun 22, 2006, at 1:41 AM, Alexandre Quessy wrote:
Hi all,
This is a little PD abstraction I made out of Dan`s patch. Thanks for the help in decoding that list of floats. Now I see why serial lines of fixed length is easier than variable length !
In the tarball, there is also a screenshot of the blueCUI output using comport, as requested by Thomas. (maybe too late now, as it works perfectly now) It is a screenshot as there is no obvious way to copy-paste the PD window`s output in OSX.
Also, comport is still using much of the CPU. Maybe a lower data rate would be suitable.
regards, aalex
On 6/17/06, Dan Overholt dano@create.ucsb.edu wrote:
all right, there's an updated version of the PD patch for the
Bluetooth CUI on the website now, including the digital inputs: http://www.create.ucsb.edu/~dano/CUI/CUIBTPDtest.pdusing the AND operator in PD seems to be _very_ inneffecient
though, if anyone has a better idea, let me know!-Dan
On Fri, 16 Jun 2006, Hans-Christoph Steiner wrote:
To get bits, use the standard bitwise operators, just like C or
many
other languages. Pd has the whole suite: & | >> <<
To get the value of a bit, AND it by that bit's value, i.e. the 4th bit would be [& 16]
.hc
On Jun 16, 2006, at 2:00 PM, Dan Overholt wrote:
Hi All,
I've put up an example of using the Bluetooth CUI with PD here: http://www.create.ucsb.edu/~dano/CUI/CUIBTPDtest.pd
The only question is how to get at the individual bits within the last 2 received bytes to decode the digital inputs from the CUI. In
Max/MSP,
there is an 3rd party external called [bit] that does this... any suggestions?
All the best, -Dan
-- Dan Overholt -- http://www.create.ucsb.edu/~dano Center for Research in Electronic Art Technology, UCSB
On Fri, 16 Jun 2006, Alexandre Quessy wrote:
Hello Pure Data friends,
We are currently trying to make the Bluetooth CUI work with PD.
The Bluetooth Create Usb Interface is the wireless version of
the USB
CUI, a 13 analog/10 bits and 12 digital I/O interface for
sensors.
The BTCUI is perfect for embbeded applications like dance, performance, music etc. It's one of the cheapest and smallest wireless interface on the market, and it is Open Hardware !
The USB CUI works all right with PD, with HID tools. We use
the [hid]
external from PD-Extended 0.39.RC4 (on Mac).
Unfortunately, we didn't succeeded to make the BluetoothCUI
working
with PD. We have tried [comport] and [hid]. The BTCUI works
perfectly
on Max/MSP (demo version), as announced by Dan Overholt, its
creator.
His patch is downloadable at http://www.create.ucsb.edu/~dano/CUI/BlueCUItestRev2.zip and
uses the
[serial] object of Max/MSP.
The protocol of the CUI is probably similar to the one used by joysticks and such. It consists in a serie of integers with delimiters, the several remaining integers beings the values
that the
device sends to the computer. See the attached PD patches.
Below are
out two PD patches. The first one uses [hid] and works with
the USB
CUI, but not over BlueTooth. (Apple does serial port
emulation) The
second uses [comport] and almost work. The CUI LED lights up,
so it
means that it is sending data, but most often, dumping the
data from
[comport]'s outlet give us nothing.
Would you have any idea of what is missing to imitate, and
make even
better than the [serial] Max/MSP object ? Otherwise, would it be easier on Linux ?
JN and
Man has survived hitherto because he was too ignorant to know
how to
realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-- Dan Overholt -- http://www.create.ucsb.edu/~dano Center for Research in Electronic Art Technology, UCSB
-- Alexandre Quessy http://alexandre.quessy.net <blueCUI-2006-06-22.tar>
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
On Fri, 23 Jun 2006, Hans-Christoph Steiner wrote:
As for the usage of CPU, because its a fast bitrate, it will always use a noticeable amount of CPU time. Mouse data is another example of a high-speed data stream.
old mice ran at 1200 bps. PS/2 mice might run at 9600 bps, not sure. In any case it doesn't get over 1 kilobyte/sec. Each packet is 3 or 5 bytes depending on the protocol. I find it likely that most PS/2 mice use only a small fraction of the bandwidth, but I haven't measured.
IIRC, a lot of mouse pointer processing is handled by the graphics card for this reason.
"Just" the display of a sprite such as an arrow. If you ever use a plain VGA driver, you don't have this feature, so it has to be handled software.
What makes you think it's high speed? Or do you mean an example of something that needs to have a low latency?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jun 23, 2006, at 2:03 PM, Mathieu Bouchard wrote:
On Fri, 23 Jun 2006, Hans-Christoph Steiner wrote:
As for the usage of CPU, because its a fast bitrate, it will
always use a noticeable amount of CPU time. Mouse data is another
example of a high-speed data stream.old mice ran at 1200 bps. PS/2 mice might run at 9600 bps, not
sure. In any case it doesn't get over 1 kilobyte/sec. Each packet
is 3 or 5 bytes depending on the protocol. I find it likely that
most PS/2 mice use only a small fraction of the bandwidth, but I
haven't measured.
IIRC, a lot of mouse pointer processing is handled by the
graphics card for this reason."Just" the display of a sprite such as an arrow. If you ever use a
plain VGA driver, you don't have this feature, so it has to be
handled software.What makes you think it's high speed? Or do you mean an example of
something that needs to have a low latency?
PS/2 mice can run up to 200Hz, USB HID devices up to 100Hz. With USB
HID mice, the data is sent every 10ms, but its not just one report,
it can be many. Each USB HID device is allocated 64kbps of
bandwidth, and decent mice use it.
My Logitech MX510 sends 1 byte for buttons, 2 bytes for standard XY
reports, and 3 bytes for hi-res XY reports (12bits per axis). That's
6 bytes per report. It can send up to 64 reports per poll (every 10
ms), so it has the ability to overwhelm the USB HID allocation many
times over. This is something that I have measured.
.hc
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
-
Alexandre Quessy -
Hans-Christoph Steiner -
Mathieu Bouchard