mailing list problem
I have noticed that sending a reply on this mailing list doesn't work as usual. It seems that by default the reply message is not sent to the list but to the original poster. Can somebody else confirm this problem? -mb
The current setting for chuck, chuck-users, chuck-dev is to reply to sender and not to the list by default (you have to hit 'reply all' to include the list). I guess it is to help prevent accidentally sending personal replies to the entire list. But perhaps it would be better to revert chuck-users to reply to list by default? let me know if you like to revert this list to reply list. Best, Ge! On Wed, 31 Aug 2005, Manfred Brockhaus wrote:
I have noticed that sending a reply on this mailing list doesn't work as usual. It seems that by default the reply message is not sent to the list but to the original poster. Can somebody else confirm this problem?
-mb
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
I definitely vote for reply to list by default. I think it's normal behaviour that users would expect from a users list. Recently I've got some replies directly which were accidently NOT sent to list I guess. -mb On Aug 31, 2005, at 8:48 PM, Ge Wang wrote:
The current setting for chuck, chuck-users, chuck-dev is to reply to sender and not to the list by default (you have to hit 'reply all' to include the list). I guess it is to help prevent accidentally sending personal replies to the entire list. But perhaps it would be better to revert chuck-users to reply to list by default? let me know if you like to revert this list to reply list.
Best, Ge!
On Wed, 31 Aug 2005, Manfred Brockhaus wrote:
I have noticed that sending a reply on this mailing list doesn't work as usual. It seems that by default the reply message is not sent to the list but to the original poster. Can somebody else confirm this problem?
-mb
_______________________________________________ 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
I back Manfred's vote. On 31 Aug 2005, at 21:43, Manfred Brockhaus wrote:
I definitely vote for reply to list by default. I think it's normal behaviour that users would expect from a users list. Recently I've got some replies directly which were accidently NOT sent to list I guess.
-mb
On Aug 31, 2005, at 8:48 PM, Ge Wang wrote:
The current setting for chuck, chuck-users, chuck-dev is to reply to sender and not to the list by default (you have to hit 'reply all' to include the list). I guess it is to help prevent accidentally sending personal replies to the entire list. But perhaps it would be better to revert chuck-users to reply to list by default? let me know if you like to revert this list to reply list.
Best, Ge!
On Wed, 31 Aug 2005, Manfred Brockhaus wrote:
I have noticed that sending a reply on this mailing list doesn't work as usual. It seems that by default the reply message is not sent to the list but to the original poster. Can somebody else confirm this problem?
-mb
_______________________________________________ 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
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
We have changed the settings to respond to list (instead of sender). This goes for chuck, chuck-users, and chuck-dev. chuck is now moderated, and chuck-users and chuck-dev remains unmoderated. If we run into any problems, we can vote again. Ge! On Aug 31, 2005, at 6:44 PM, eduard wrote:
I back Manfred's vote.
On 31 Aug 2005, at 21:43, Manfred Brockhaus wrote:
I definitely vote for reply to list by default. I think it's normal behaviour that users would expect from a users list. Recently I've got some replies directly which were accidently NOT sent to list I guess.
-mb
On Aug 31, 2005, at 8:48 PM, Ge Wang wrote:
The current setting for chuck, chuck-users, chuck-dev is to reply to sender and not to the list by default (you have to hit 'reply all' to include the list). I guess it is to help prevent accidentally sending personal replies to the entire list. But perhaps it would be better to revert chuck-users to reply to list by default? let me know if you like to revert this list to reply list.
Best, Ge!
On Wed, 31 Aug 2005, Manfred Brockhaus wrote:
I have noticed that sending a reply on this mailing list doesn't work as usual. It seems that by default the reply message is not sent to the list but to the original poster. Can somebody else confirm this problem?
-mb
_______________________________________________ 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
_______________________________________________ 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
Hi Ge and others, I have a proposal, which I don't know if people would agree it is important but that I personally would find handy. I am a newbie with chuck and maybe there is a way to accomplish such thing. If that were the case my apologies but I couldn't figure it out from reading the documentation. The proposal is to be able to have a "name" public method for Shreds. This comes in handy when one runs the same ck-program several times with different settings each time and therefore being able to differentiate from each other easily. It has happened to me that I've removed shreds that I didn't want to. One could assign the name by issuing: machine.add("foo.ck", "foo_1") //where foo_1 would be the name obviously. hmm.., now that I am writting this lines I'm thinking could add and remove shreds by doing: machine.add("foo.ck") => int foo_1_id; machine.remove( foo_1_id ); However this would require keeping a "main" program, and the foo_1_id, would be a local variable from the first run of the program.... So in the end, I think it would be nice to issue ./chuck ^ and see the status with more representative names than those from the ck- program filenames. Sorry, I went a bit messy by the end of the email. Eduard
Hi Eduard and all, Adding .name() to Shreds is a very good idea. I would also find this useful. Perhaps we can allow names to be set and gotten like: // for Shred foo "foo(d)!!!" => foo.name; // print out the name <<< foo.name() >>>; or some other syntax? We will also add this name to the --status output. By the way, the interface to machine.* will be changed soon to return shreds, not the id. The id is still available via the .id() member. We can add overloaded versions of these to set names. Best, Ge! On Aug 31, 2005, at 8:39 PM, eduard wrote:
Hi Ge and others,
I have a proposal, which I don't know if people would agree it is important but that I personally would find handy. I am a newbie with chuck and maybe there is a way to accomplish such thing. If that were the case my apologies but I couldn't figure it out from reading the documentation.
The proposal is to be able to have a "name" public method for Shreds. This comes in handy when one runs the same ck-program several times with different settings each time and therefore being able to differentiate from each other easily. It has happened to me that I've removed shreds that I didn't want to.
One could assign the name by issuing:
machine.add("foo.ck", "foo_1") //where foo_1 would be the name obviously.
hmm.., now that I am writting this lines I'm thinking could add and remove shreds by doing:
machine.add("foo.ck") => int foo_1_id; machine.remove( foo_1_id );
However this would require keeping a "main" program, and the foo_1_id, would be a local variable from the first run of the program....
So in the end, I think it would be nice to issue ./chuck ^ and see the status with more representative names than those from the ck-program filenames.
Sorry, I went a bit messy by the end of the email.
Eduard
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hi all, I am doing the following: Terminal A: 1. ./chuck --loop Terminal B: 1. ./chuck --loop --silent --port4000 Terminal C: 1. ./chuck + kick.ck // 120 bpm kick, one kick every half a sec 2. ./chuck --port4000 + test.ck test.ck is the following: .5::second => dur T; T - (now % T )=>now; 0 => int i; while(true) { i++; <<< "foo",i>>>; 1::T => now; } So I expect the word foo to appear every half a sec as well. However what happens is that it gets printed out way faster than that ( around 20 times faster). However if I do the same but skipping the --silent option in Terminal B, all works fine. Maybe a bug??? Here's my second question. I want the word foo to be printed synchronously with the kick and be run on different terminals. For that I thought I could issue the following command: ./chuck + kick.ck && ./chuck --port4000 + test.ck but they are slightly out of tempo. How could I achieve to get them synchronised or with less latency? Eduard
Hi Eduard and all, Sorry for the mailing spam silence. We have been away at ICMC and I am going back under the radar for a few more days (will return to Princeton early next week). Eduard, it's very good meeting you in Barcelona!
Terminal A: 1. ./chuck --loop
Terminal B: 1. ./chuck --loop --silent --port4000
Terminal C: 1. ./chuck + kick.ck // 120 bpm kick, one kick every half a sec 2. ./chuck --port4000 + test.ck
The --silent flag actually means "no real-time audio. compute samples as fast as possible", and is a way to do "offline" synthesis (generating to file). That is why time can move much "faster" under this mode.
Here's my second question. I want the word foo to be printed synchronously with the kick and be run on different terminals. For that I thought I could issue the following command:
./chuck + kick.ck && ./chuck --port4000 + test.ck
but they are slightly out of tempo. How could I achieve to get them synchronised or with less latency?
At the moment, there is no easy way to synchronize two separate ChucK virtual machines. It is possible to use dracula features to pass OSC messages to/from the virtual machines, which may be one low-latency approach to do what you want. (see examples/event/opensound_demo_*) Best, Ge!
Dear All, I mainly edit CHUCK programs with VIM and I've been missing syntax highlighting to make the programs more readable. I've attempted to do one myself, but actually what I've done is a terrible hack from the existing c.vim file ( syntax coloring for c programs). So far I think it helps me much more than not having any highlighting at all, so I will send it to the list in case someone finds it of any use. Two files are attached: 1. ck.vim --> this file must be copied in the same directory where other vim syntax highlighting files are. Mainly /usr/share/vim/ vim62/syntax. In order to make the syntax highlighting effective, you must add the following line in /usr/share/vim/ filetype.vim : au BufNewFile,BufRead *.ck setf ck 2. the second attachment is just a screenshot, so you can see how the syntax highlighting looks in my screen. My knowledge of vim syntax highlighting is very poor, so feel free to improve it or let me know if you have any suggestions... I'm sure I've forgotten many things. Eduard
participants (3)
-
eduard -
Ge Wang -
Manfred Brockhaus