Open/write/read serial port

I'm looking for a developer to create a general serial port open-read-write patch.

Inputs: 1. name of serial port, eg: /dev name 2. serial communation settings, baud rate, stop and start bits, parity 3. string to be sent to the serial port on a trigger 4. Delimiter character that segments output string.

Outputs: Anything read from the port, string output. One item for each line delimiter.

While this can be used for any device with a serial interface, the immediate need is for this I would also like to use it for a SpaceMouse maybe

Please feel free to forward questions for more details.

Starting bid: US$100 but open to suggestion/negotiation depending on just how hard this is.

smokris's picture

How soon do you need the final product?

pbourke's picture

No huge rush ... this evening sometime would be fine. :-)

Seriously: The cup interface is for a dance performance with a local artist, the sooner we get it going the sooner we can start to investigative how the data can be mapped to graphics and audio. But I do want to stress that I wouldn't expect this to be implemented for just this application, I believe a serial interface would be useful for a whole range of similar devices that have (only) serial interfaces.

cwright's picture

This sounds interesting, but I don't think you'll want outputs to work quite like that: uninitialized, you'll have no delimited outputs. Thus, you won't be able to connect anything to them. This would cause problems when you tried to save and re-open a composition, unless it saved the number of outputs. I'm assuming this would be fairly variable, so state saving isn't the right solution either.

I would imagine that a structure, with one item per delimited string, would be the way to go; It's variable in size without modifying the outputs one the fly (and all the problems associated with that).

What would modified-input behaviour be? If the user changed the device string should it automatically close the old device and open the new one? What if they change configuration (baud rate, etc). should it make those changes as soon as it notices? How should it handle error conditions (invalid baud rates, etc)? Should there be an "open the device" input?

pbourke's picture
re: outputs

An "open the device" input does sound sensible.

Yes, if any of the serial settings (device or serial parameters) are changed then the port is closed and reopened.

Error conditions .... sorry not sure what is possible with QC, perhaps the error message on the output?

In terms of the output, can it reflect the new data on the serial port. That is, when new data appears it replaces what is on the output. If there is no new data from the port can the output just be the last data. Helps with the error messages perhaps, initially it would be a null string.

cwright's picture
reflecting new data

it would definitely reflect new data as it was received. It would update the structure, etc.

for errors, I don't know. we could put an error message in an output port. This normally only happens when the user specifies an invalid configuration (either incorrect device name, too few/many start/stop bits, an out-of-range baud rate, etc).

Could to elaborate a bit on what kind of data it would receive? For example, is it always 8 fields, comma delimited, for example (which might cause problems mid-update, because the output would have only the new inputs received, not necessarily all 8).

smokris's picture
error condition

I think it might be cleaner to provide the error information out-of-band rather than as part of the output stream itself.

In QC, we can announce error conditions by: 1. sending a value to an output port on the patch --- this gives the composition writer the choice of what to do about the error. 2. logging a message to the QC Viewer Debug Log (and throwing the composition into Debug Mode) --- this is pretty invasive and will definitely get the user's attention. 2. logging a message to the (Mac OS X) Console --- this will go unnoticed unless the user is specifically looking for it.

If we use method 1., I'd suggest creating a separate output port for the error message, so that it's easy to differentiate error conditions from actual content.

cwright's picture
separate output

it's a great idea to have the error output be a separate output. perhaps a bool, "Error Has Occured", and a string, "Error description"? I've not had much experience with the Viewer Debug log personally, so I don't know of its efficacy off hand. Console log is only handy if you're developing patches :)

so, I'm leaning towards 1, but only because I'm unsure of how users interact with 2. (the first 2, not the second ;)

pbourke's picture
reflecting new daya

Could to elaborate a bit on what kind of data it would receive? For example, is it always 8 fields, comma delimited, for example (which might cause problems mid-update, because the output would have only the new inputs received, not necessarily all 8).

It needs to be more general than that, that is, more general than my initial application.

I suspect the way most apps interact with serial data is as I described in the original post, a delimiter character is defined, the output doesn't get updated until that character is detected. This works well for ascii/text data from serial devices but that would cover most uses with QC I suspect.

alexbeim's picture
QC reading/writing serial data

I see that the last comment was on 2007-09-29, have you guys done anything else on this since then? I'm super interested in getting some really simple serial data into QC.

I can program the electronics on Zygote ( to send the data however I wanted. I think the simples thing would be something like an ID number for one of the zygotes and an RGB colour code or HSB. Each ball will send the info to my computer through a serial/usb. Basically a xbee module connected to an arduino board.

I'm also willing to pay some money to develop this and I don't mind if you guys release it freely to the rest of the people interested.

I would love to be able to communicate back sending and ID and a color code and some other custom string that will start different behaviors on the zygotes.

At the moment I can do all these in processing and flash using the tinker proxy (, but because I'm not a programmer doing any type of visualizations in that environment is impossible to me. That's why I like QC so much

I would like to get something done fairly soon but I'm pretty flexible.

cwright's picture
Nice :)

Coincidently, we're just gearing up (again) to start producing a serial interface patch due to a few other users' interest :) Thanks for adding your vote :)

What kind of DMX interface do you use on OS X? I poked at on e a few months ago, but the drivers didn't work as documented, so it never came to life :( I'd love to know what interface works, so I can get that up and running.

franz's picture

this one is cheap, works on osx (with modul8 for instance, but should be working with Max too) and on pc (vvvv).

smokris's picture

On Franz's advice, I just placed an order for a DMX USB Pro. Stay tuned for DMX patch...

franz's picture

Okay, i just bought one too .... (hehe, i got 90 DMX neon tubes laying around at the basement...)

dvkid's picture

I have had my eye on the DMX USB PRO for quite some time but feared I wouldn't be able to get it working with QC. Anybody else done anything with it?

alexbeim's picture
DMX Interface

I have an open DMX from Enttec coming already. I wish I had seen these posts last week.

franz's picture
should work too

it should work with the openDMX too. If not, you can still modify the firmaware by yourself to make it compliant (i guess there are plenty o' tuts around)

alexbeim's picture
openDMX Enttec

I just received it by mail. The device was $60, shipping was 40, 35 for the broker and taxes on top of that. So I ended up paying like double of the device's price to get it to my hands. I have no clue how to modify the firmware, I'm not a programmer. Does anybody know how to make this work with osX?