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.