tis 2007-12-04 klockan 18:00 +0100 skrev Kassen:

Hi, again, Core.

[snip]

Hope this helps, Happy ChucKing! Kas.

Damn, he beats me again! :D Gasten

tis 2007-12-04 klockan 18:18 +0100 skrev Kassen:

On 04/12/2007, Martin Ahnelöv wrote:

The syntax should look like this (I've made some notes):

// if followed an expression in brackets. if there are mutliple, use // "and" followed by a new expression between brackets (you can also use // "or" instead of "and". // The curly brackets come after the whole if-statement. // No "then". if (msg.isButtonDown()) and (msg.my_keynumber = 65) {

I'm sorry but I really don't think you can do that. I don't think I ever saw "and" used in a ChucK context and I can't get this to run;

if ( true and true ) <<<"poof">>>;

or this; if ( true) and (true ) <<<"poof">>>;

While this works;

if ( true && true ) <<<"poof">>>;

If I'm wrong, could you give a example along those lines that uses "and" and will run?

No, you're right. I just thought "and" and "or" was in there, since they are pretty common in languages with this kind of syntax. My bad. Gonna go edit my sintax file. IT DECEIVED ME!!!1 Gasten

Just in case anyone is interested.... I fixed the problem by packing x and y and sending them together via osc. If someone uses more points, as its my case, all values need be packed, in order to receive all info at the same rate. eduard On Dec 5, 2007, at 8:16 PM, eduard aylon wrote:

Hi all,

I am building an interface in Puredata to control via OSC a chuck program, but I am having some trouble when sending the position (x,y pairs) of a small "canvas" which I use as a point in space. The problem is that somehow most of the time I just get the x- coordinate and only sometimes the y-coordinate. And really don't know why. I must say that I'm not very used to work with puredata, so if there are any PD+chuck experts in this list that may have some time to have a look at the patches (attached below) and give some advice, I'd much apreciate it.

thanks in advance,

eduard

in my experience, UDP regularly drops messages, even when sending small amounts from one server to 2-3 clients (all reasonably new machines). we use it all the time in PLOrk, and have always had to find ways to work around the unreliability. this is true with both max and chuck. tcp and other things are in our future, though the accurate timing of udp is still quite remarkable. dt On Dec 6, 2007, at 9:53 AM, Stefan Blixt wrote:

Hi.

I know you found a good solution, but I am curious. Are you running your puredata and ChucK programs on the same computer? UDP (upon which OSC is based) is lacking in the secure-transfer department, but if you aren't sending enourmous amounts of data on different hosts (or use an old computer), you shouldn't lose messages like this.

Cheers, Stefan

On Dec 6, 2007 2:57 PM, eduard wrote: Just in case anyone is interested.... I fixed the problem by packing x and y and sending them together via osc. If someone uses more points, as its my case, all values need be packed, in order to receive all info at the same rate.

eduard

On Dec 5, 2007, at 8:16 PM, eduard aylon wrote:

...

Hi all,

I am building an interface in Puredata to control via OSC a chuck program, but I am having some trouble when sending the position (x,y pairs) of a small "canvas" which I use as a point in space. The problem is that somehow most of the time I just get the x- coordinate and only sometimes the y-coordinate. And really don't know why. I must say that I'm not very used to work with puredata, so if there are any PD+chuck experts in this list that may have some time to have a look at the patches (attached below) and give some advice, I'd much apreciate it.

thanks in advance,

eduard

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

-- Release me, insect, or I will destroy the cosmos! _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

good to know. probably then some combination of udp for well timed messages (except for multicasting, which also stinks for timing) and tcp for single messages that *have* to get to their destination is the way to go. i believe Perry has a student working some new networking protocols for ChucK and related apps. top secret i suppose. dan On Dec 6, 2007, at 10:31 AM, garton@columbia.edu wrote:

Quoting dan trueman :

...

tcp and other things are in our future, though the accurate timing of udp is still quite remarkable.

and the timing with tcp can be quite variable...

brad http://music.columbia.edu/~brad _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

...

good to know. probably then some combination of udp for well timed messages (except for multicasting, which also stinks for timing) and tcp for single messages that *have* to get to their destination is the way to go.

The other alternative is time-stamping of some sort of sync signal, but that makes some kinds of r/t interactivity more difficult.

I believe the TCP-for-commands, UDP-for-parameters approach is a pretty good one. In my experience UDP packets aren't really dropped all that often, but I often wondered if TCP might be a better approach in general. Some day I'd like to see a standardized shared-memory approach to passing OSC messages, which would be insanely fast on a local machine. (Though, I believe that local loopback sockets are often implemented using shared memory, and are thus pretty much just as fast. Not sure if this is the case in Linux, I've been meaning to look it up for a while..) Keep in mind that if you have several OSC messages that must arrive simultaneously, you can us bundles, which should be supported in most implementations. I believe you can use them in PureData by sending "[" and "]" messages to the dumpOSC object. Not sure if Chuck supports them? In any case they are an under-used part of the OSC standard. Steve

Quoting Stephen Sinclair :

Some day I'd like to see a standardized shared-memory approach to passing OSC messages, which would be insanely fast on a local machine. (Though, I believe that local loopback sockets are often implemented using shared memory, and are thus pretty much just as fast. Not sure if this is the case in Linux, I've been meaning to look it up for a while)

My preference is to dump OSC entirely, and use some kind of loadable/imbeddable scheme. It would be just fun fun fun to put the entirety of ChucK into a loadable lib of some kind, and then find the entry-points you want from your calling environment and go go go. This is how [chuck~] works, by the way, brad http://music.columbia.edu/~brad

mån 2008-05-19 klockan 11:42 +0200 skrev Luigi Rensinghoff:

Hmm

I am mainly a PD User but had a short look into chuck....

For now i cannot grasp the capabilities that a chuck~object brings into max or PD, but i am very interested..

Its a shame you didnt use "flext" (you know it ??)

http://www.parasitaere-kapazitaeten.net/ext/flext/

That way we had a PD-object as well..

Since i am not a programmer i cannot do the port, do you think it is a lot of effort ???

Thanks Luigi

AFAIK, the chuck development team is not responsible for the [chuck~]-object in PD, it's Martin Robinson, and he in turn based his work on Brad Garton's Max/MSP-object. I think you should get in touch with either them or the PD-list. Though, I might be very wrong in this. Mr Robinson will probably turn out to be a plork-member, or something =) Gasten

Seriously, when I was building rtcmix~ (which acted as the template for chuck~), I don't think flext was fully-developed. Plus there is some weirdness in the way I do the dynamic loading, not sure about flext compatability (probably is easy). flext does look like a nifty approach, does it work with Xcode yet? There is a PD chuck~ object, as noted in an earlier post. Plus source for all this stuff is on-line, feel free to flext-ize it! brad http://music.columbia.edu/~brad On May 19, 2008, at 5:42 AM, Luigi Rensinghoff wrote:

Hmm

I am mainly a PD User but had a short look into chuck....

For now i cannot grasp the capabilities that a chuck~object brings into max or PD, but i am very interested..

Its a shame you didnt use "flext" (you know it ??)

http://www.parasitaere-kapazitaeten.net/ext/flext/

That way we had a PD-object as well..

Since i am not a programmer i cannot do the port, do you think it is a lot of effort ???

Thanks Luigi

Am 06.12.2007 um 18:10 schrieb garton@columbia.edu:

...

Quoting Stephen Sinclair :

...

Some day I'd like to see a standardized shared-memory approach to passing OSC messages, which would be insanely fast on a local machine. (Though, I believe that local loopback sockets are often implemented using shared memory, and are thus pretty much just as fast. Not sure if this is the case in Linux, I've been meaning to look it up for a while)

My preference is to dump OSC entirely, and use some kind of loadable/imbeddable scheme. It would be just fun fun fun to put the entirety of ChucK into a loadable lib of some kind, and then find the entry-points you want from your calling environment and go go go.

This is how [chuck~] works, by the way,

brad http://music.columbia.edu/~brad _______________________________________________ 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