Re: [chuck-users] serial communication and chuck
YES! Chuck NEEDS serial. Of course it's true that all of this can be accomplished using some other application and OSC, but it's cumbersome and lame to have to use another application *only* to get access to serial. I've had to do this for several projects, including one I'm working on now. HIDUINO seems like a promising alternative for Arduino stuff, but I wasn't able to get it working right, so I gave up on it. Maybe others have had luck with that? Cameron
N. Cameron Britt wrote:
YES! Chuck NEEDS serial. Of course it's true that all of this can be accomplished using some other application and OSC, but it's cumbersome and lame to have to use another application *only* to get access to serial. I've had to do this for several projects, including one I'm working on now.
HIDUINO seems like a promising alternative for Arduino stuff, but I wasn't able to get it working right, so I gave up on it. Maybe others have had luck with that?
There's also OSC on Arduino via an ethernet shield, e.g. http://recotana.com/recotanablog/closet http://adrianfreed.com/content/oscuino-arduino-osc-sketch-open-sound-control... Does anyone have experience with such a library? michael
This is a great thread. :) +1 for serial support in Chuck.
I've done a lot in the past with hardware interfaces and Chuck and have
always run something like processing/oscP5 or a python/pyliblo script in
the middle to send OSC to chuck.
Arduino (on a mac) uses the FTDI driver to expose a serial port. In a
posix environment, can't we configure our machines to pipe the output of
that file in the dev filesystem to a named pipe or something as a
work-around?
mkfifo tochuck
cat /dev/usbserial-blah | tochuck
and then read from tochuck using file i/o objects? I know it's hackish,
but what is nice is that you could configure your system to just do this
all the time and then your students wouldn't have to constantly worry about
booting processing and running some dinky little middleware app that sends
serial over OSC.
You'd have to be careful to use an ascii based protocol on the arduino
side. And, of course, you'd have to make sure to reset everything when
chuck crashes with the file still open.
Just thinking out loud here...
-Mike
http://michaelclemow.com
http://semiotech.org
On Sun, Mar 4, 2012 at 11:09 PM, Michael Heuer
N. Cameron Britt wrote:
YES! Chuck NEEDS serial. Of course it's true that all of this can be accomplished using some other application and OSC, but it's cumbersome and lame to have to use another application *only* to get access to serial. I've had to do this for several projects, including one I'm working on now.
HIDUINO seems like a promising alternative for Arduino stuff, but I wasn't able to get it working right, so I gave up on it. Maybe others have had luck with that?
There's also OSC on Arduino via an ethernet shield, e.g.
http://recotana.com/recotanablog/closet
http://adrianfreed.com/content/oscuino-arduino-osc-sketch-open-sound-control...
Does anyone have experience with such a library?
michael _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Mon, Mar 05, 2012 at 12:48:56PM -0500, mike clemow wrote:
and then read from tochuck using file i/o objects? I know it's hackish, but
I don't think that's so hackish, that's how UNIX is supposed to work and why the "everything is a file" thing is nice. :-) If you like you can also write numbers to the file that represent your soundcard, at least on Linux you can (you may want to disable some of those pesky modern drivers first). As I understood the discussion that is exactly what is planned and partially what people are already doing, but the problem is setting properties like the baud rate and so on. I like this, I'm quite in favour of simple things that work; it's rarely the simple things that ruin my day and when they do they tend to do so in ways that are at least predictable. Yours, Kas.
The arduino can't mount the file system of the ChucK host, so you'd still need an intermediate process to read the data from the arduino and write it into the pipe, but that may be as simple as `mkfifo mypipe; chuck mywhatever.ck; cat /dev/ttyUSB > mypipe`, where mywhatever.ck has an open file handle on mypipe, reading from it continuously. There's a concern about fifos being synchronous by default and that a writer with a higher throughput than the ChucK process on the reading side would become blocked, which I can see not really jiving with ChucK's timing guaranteed. fifo(7) discusses using fifos in a non-blocking fashion but I'm a little vague on " Normally, opening the FIFO blocks until the other end is opened also. A process can open a FIFO in nonblocking mode.", since I don't know if a process has to do something special in order to get that behavior and it's scant on details, but I've had the blocking natures of fifo's bite in the ass before. http://linux.die.net/man/7/fifo
the problem is setting properties like the baud rate and so on.
There's an article discussing such /dev/ttyUSB tomfoolery here: http://arduino.cc/playground/Interfacing/LinuxTTY. It mentions a usage of the stty command that I believe addresses Kas's concerns, but I haven't tried it yet so I'm not sure. seems dangerous but it just might work. On Mar 5, 2012, at 12:57 PM, Kassen wrote:
On Mon, Mar 05, 2012 at 12:48:56PM -0500, mike clemow wrote:
and then read from tochuck using file i/o objects? I know it's hackish, but
I don't think that's so hackish, that's how UNIX is supposed to work and why the "everything is a file" thing is nice. :-) If you like you can also write numbers to the file that represent your soundcard, at least on Linux you can (you may want to disable some of those pesky modern drivers first).
As I understood the discussion that is exactly what is planned and partially what people are already doing, but the problem is setting properties like the baud rate and so on.
I like this, I'm quite in favour of simple things that work; it's rarely the simple things that ruin my day and when they do they tend to do so in ways that are at least predictable.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Mon, Mar 05, 2012 at 01:23:17PM -0500, Jordan Orelli wrote:
The arduino can't mount the file system of the ChucK host, so you'd still need an intermediate process to read the data from the arduino and write it into the pipe,
Ah, sorry. I was under the impression that the Arduino would, on its own, put arbitrary data on its output, while fairly unaware of what kind of device (a PC or some sort of machine or...) the other side was. Maybe that was wrong.
There's a concern about fifos being synchronous by default and that a writer with a higher throughput than the ChucK process on the reading side would become blocked, which I can see not really jiving with ChucK's timing guaranteed.
I'm not sure this is a issue in practice, because ChucK could read all available data from the file once every few ms or so. Serial ports are hardly devices known for putting through terabytes of data. It does bring up the question of how ChucKs definitions of timing may interact with actual processes that run "as quickly as they can". As I see it that interaction is something that hasn't yet been explored in as much depth as would IMHO be nice. Clearly we run into exactly that when playing back sound or listening to the ADC and that's also the case where we have some advanced syntax, being "samp => now;". No such syntax is there to wait for a serial or MIDI port to clear its cue or to interact with a hard-drive. ChucK can tell us how quickly the dac can deal with 10 samples in double-float precision, but it can't tell us how quickly we can read 10MB from the drive or write the same to it. On the bright side; with a set baud rate a serial port becomes a lot like a dac in that we know exactly how much data we can expect, so dealing with that is a lot more like what we already have than the wide variety of drives that can be expected to potentially be attached to computers running ChucK. Interesting problem. Kas.
wait a second... can ChucK just read from /dev/ttyUSB directly? I don't know how the /dev files operate, but maybe what we're saying is a really roundabout way of just mounting the arduino as a TTY like in the article I linked and having ChucK read from the device file. I don't have an arduino to try it out, but... it's worth trying if anyone wants to give it a whirl ;) On Mar 5, 2012, at 2:35 PM, Kassen wrote:
On Mon, Mar 05, 2012 at 01:23:17PM -0500, Jordan Orelli wrote:
The arduino can't mount the file system of the ChucK host, so you'd still need an intermediate process to read the data from the arduino and write it into the pipe,
Ah, sorry. I was under the impression that the Arduino would, on its own, put arbitrary data on its output, while fairly unaware of what kind of device (a PC or some sort of machine or...) the other side was. Maybe that was wrong.
There's a concern about fifos being synchronous by default and that a writer with a higher throughput than the ChucK process on the reading side would become blocked, which I can see not really jiving with ChucK's timing guaranteed.
I'm not sure this is a issue in practice, because ChucK could read all available data from the file once every few ms or so. Serial ports are hardly devices known for putting through terabytes of data.
It does bring up the question of how ChucKs definitions of timing may interact with actual processes that run "as quickly as they can". As I see it that interaction is something that hasn't yet been explored in as much depth as would IMHO be nice. Clearly we run into exactly that when playing back sound or listening to the ADC and that's also the case where we have some advanced syntax, being "samp => now;". No such syntax is there to wait for a serial or MIDI port to clear its cue or to interact with a hard-drive. ChucK can tell us how quickly the dac can deal with 10 samples in double-float precision, but it can't tell us how quickly we can read 10MB from the drive or write the same to it.
On the bright side; with a set baud rate a serial port becomes a lot like a dac in that we know exactly how much data we can expect, so dealing with that is a lot more like what we already have than the wide variety of drives that can be expected to potentially be attached to computers running ChucK.
Interesting problem.
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
On Mon, Mar 05, 2012 at 02:54:10PM -0500, Jordan Orelli wrote:
wait a second... can ChucK just read from /dev/ttyUSB directly? I don't know how the /dev files operate, but maybe what we're saying is a really roundabout way of just mounting the arduino as a TTY like in the article I linked and having ChucK read from the device file. I don't have an arduino to try it out, but... it's worth trying if anyone wants to give it a whirl ;)
I think so. I never tried it with a arduino, but a bit ago I was trying to get some annoying multi-media keys to work and just ran "cat" on the "/dev/input/blah-blah-blah" of the keyboard to confirm I was getting data. You can, they are just files. For some you may need root and some of the stuff in /dev may be best left alone, on top of that nothing says the output you get will make intuitive sense... but yes you can. Basically everything in Unix is abstracted to the OS as being a file and those you can read from or write to, just like any other process can. Have fun, Kas. Disclaimer; poking around is good fun and educational. It's safe to assume that all UNIX experts poked around... but it's also safe to assume that the expertise was gained in learning what not to touch by burning one's finger. (same holds true for Windows, BTW)
I figured Jordan would pipe up at the mention of mkfifo. (pun intended ;) Yeah, I'm totally not thinking through the process here. It's best to decide that you're doing serial at 9600 baud, say, and read from /dev/ttyUSB using python, say, and then write to a named pipe and read from that pipe with chuck. (Still using an ASCII protocol). Since Chuck's FileIO blocks, you tell Chuck to read as fast as possible in a single shred and route data using Events (Chuckian). BUT, my point is that this could be set up very simply to always work the same way without having to fiddle with it each time you want to read your Arduino data. If you got super-fancy you could create a udev rule to always have this run when it sees the Arduino.
I don't think that's so hackish, that's how UNIX is supposed to work and why the "everything is a file" thing is nice. :-) If you like you can also write numbers to the file that represent your soundcard, at least on Linux you can (you may want to disable some of those pesky modern drivers first).
Yeah, but you have "mad scientist" in your resumé. ;)
-mike
http://michaelclemow.com
http://semiotech.org
On Mon, Mar 5, 2012 at 3:13 PM, Kassen
On Mon, Mar 05, 2012 at 02:54:10PM -0500, Jordan Orelli wrote:
wait a second... can ChucK just read from /dev/ttyUSB directly? I don't know how the /dev files operate, but maybe what we're saying is a really roundabout way of just mounting the arduino as a TTY like in the article I linked and having ChucK read from the device file. I don't have an arduino to try it out, but... it's worth trying if anyone wants to give it a whirl ;)
I think so. I never tried it with a arduino, but a bit ago I was trying to get some annoying multi-media keys to work and just ran "cat" on the "/dev/input/blah-blah-blah" of the keyboard to confirm I was getting data.
You can, they are just files. For some you may need root and some of the stuff in /dev may be best left alone, on top of that nothing says the output you get will make intuitive sense... but yes you can. Basically everything in Unix is abstracted to the OS as being a file and those you can read from or write to, just like any other process can.
Have fun, Kas.
Disclaimer; poking around is good fun and educational. It's safe to assume that all UNIX experts poked around... but it's also safe to assume that the expertise was gained in learning what not to touch by burning one's finger. (same holds true for Windows, BTW) _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (5)
-
Jordan Orelli -
Kassen -
Michael Heuer -
mike clemow -
N. Cameron Britt