On Tue, Sep 11, 2012 at 06:01:14PM -0400, Andrew Turley wrote:

You could use OSC to communicate with the shred. You could also try using a named pipe, writing from Python and reading from Chuck.

Hey Andrew! I'm interested in this named pipe concept. How would you read from the pipe? Would you use something like Std.system(...) or do you have a method less likely to block? Not sure I ever saw this done. Yours, Kas.

On Wed, Sep 12, 2012 at 02:16:43PM -0400, Andrew Turley wrote:

The script in examples/io/read-line.ck will do this. Just make sure to create and open the named pipe before launching the script. I do something like this (where shell1 and shell2 are different shells):

Clever!

shell1$ mkfifo example.txt shell1$ cat > example.txt

Here I believe you also need.... shell2$ cat example.txt & ...to read again at the other side.

shell2$ chuck read-line.ck

Now just type lines in shell1 and they'll show up in shell2. Once you type control-C in shell1 you'll kill the writing process and read-line.ck will stop running.

Yes, I love it. Way more simple than how I was using screen for basically this thing, but sending code to a running Scheme session, maybe I can now clean up that script too and simplify stuff. screen is nice because it can keep session alive, but with this kind of thing I typically don't want that and would rather have a easy way to reset everything in the whole system. Thanks! Kas.

On Wed, Sep 12, 2012 at 02:54:48PM -0400, Andrew Turley wrote:

Sorry, I may have been a little unclear; "shell2$ chuck read-line.ck" is doing the reading on the other side.

Of course I should have looked at where read-line.ck read from, instead of assuming the console :-). I seem to be a bit scatter-brained lately, I'm sorry about that. Yours, Kas.

On Wed, Sep 12, 2012 at 09:14:30PM -0700, forrest curo wrote:

I may need to step outside the normal packages sources to make this example work?

Yes, I fear so. Shout if you run into issues building from source; first time may take some tries, then it gets better and nice features have gotten introduced since then. Yours, Kas.

You'll need to install some dependencies. Off the top of my head, you'll need bison, flex, g++ (well, some C++ compiler), alsa dev files, and libsound. I'm assuming this is your Linux box, and not a shared box where you have an account, correct? If so, the easiest thing to do is install those packages I mentioned using your Linux distribution's package manager. Once you've done that, try "make linux-alsa" again. If you're on Debian let me know an I can send you a list of the packages you need to apt-get. For the record, I think using OSC is a better bet than using named pipes. If you need some help getting SimpleOSC working, let me know and I'll try to help you out. andy On Sep 13, 2012, at 1:06 AM, forrest curo wrote:

Thank you. ARRRRRRGGGGGGGH! " forrest@critter:~/chuck-1.3.1.0/src$ make [chuck build]: please use one of the following configurations: make linux-alsa, make linux-jack, make linux-oss, make osx, make osx-ub, or make win32 forrest@critter:~/chuck-1.3.1.0/src$ make linux-jack bison -dv -b chuck chuck.y make: bison: Command not found make: *** [chuck.tab.c] Error 127 " ???!

----------------------------------------- On Wed, Sep 12, 2012 at 9:26 PM, Kassen wrote: On Wed, Sep 12, 2012 at 09:14:30PM -0700, forrest curo wrote:

...

I may need to step outside the normal packages sources to make this example work?

Yes, I fear so.

Shout if you run into issues building from source; first time may take some tries, then it gets better and nice features have gotten introduced since then.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Okay, got chuck 1.3.. to work & the example with named pipes works as it should. (It didn't work when I was running chuck in another directory-- This would be about: // default file me.sourceDir() + "/example.txt" => string filename; ?) ------------------------------------------ So, then, "example.txt" is not a virtual file but an actual file in that directory? So this way of sending data is just a little clunky; looks like time to play with OSC!

In those chuck examples, one example sets up a port "6449 (or whatever)" and another 'listens' to that port every .2 seconds. ---- ------ So I gather that if I then sent an OSC message to 'port 6449' (or the corresponding 'whatever') via python, the listening shred would pick it up sometime in the next .2 seconds. In other words, any given port number gets recognized by any program on the system that specifically looks for it (?) ----- ----- ------ If so, then the only real problem (which I guess I'll stumble through) is finding out where to stash the pyOSC... [I'm used to having everything neatly arranged in 'packages' that know where to put themselves, ow well.]