- It should be possible to start and stop the ChucK VM in Processing, but no stop handlers are called at closing the app, leaving the VM in the air. I understand this is an issue with Java applets.

Yes, this is a bit mysterious to me. The way to go about this would be staring ChucK using either "chuck --loop" or by feeding it a file like this; "ChucK myfile.ck " using a file that will keep running. The ChucK VM should exit after you give the system a command to "chuck --kill" or after the last shred has been removed from it (if it's not set to --loop). If it doesn't properly exit after either then that would probably be a bug. I don't see how applets would affect this as this would be something between the OS and ChucK, ChucK shouldn't be affected by what sort of thing send those system calls. Strange.

No, this is just because of the way applets are quit in Java. If 'chuck --kill' is sent the processed are killed normally, so ChucK behaves predictable

- I would have liked to use 1 FilePlayer class that is loaded only once into the VM, but I have not found a way to do this. Either: 1) call 'chuck fileplayer.ck' before demo files are called causes errors on running the demo files that FilePlayer is unknown 2) for every demo file call 'chuck fileplayer.ck chuckdemo.ck:all:sorts:of:params' causes an error that FilePlayer is already in the global VM space and this will stop the demo file from running

I looked at your code for a bit and noticed you wrote a public class in one file, then redefined the class in another...

The public class not used in the demo, but I kept the file because that is the way I would ideally solve it. What I do in Processing is: 1) start chuck with 'chuck --loop' (because Processing will not quit the process I start it from the command line) 2) add the fileplayer class with 'chuck -add fileplayer.ck' 3) for each of the sound files, add it with 'chuck -add chuckdemo.ck:with:a:lot:of:params' This is the order the commands are sent to ChucK. But what I get back is: $ chuck --loop [chuckdemo.ck]:line(43): undefined type 'FilePlayer'... [chuckdemo.ck]:line(43): ... in declaration ... [chuckdemo.ck]:line(43): undefined type 'FilePlayer'... [chuckdemo.ck]:line(43): ... in declaration ... [chuckdemo.ck]:line(43): undefined type 'FilePlayer'... [chuckdemo.ck]:line(43): ... in declaration ... [chuckdemo.ck]:line(43): undefined type 'FilePlayer'... [chuckdemo.ck]:line(43): ... in declaration ... [chuck](VM): sporking incoming shred: 1 (fileplayer.ck)... So even if 'fileplayer.ck' is called earlier, it is added last to the VM. First the chuckdemo.ck files are run and they do not know any FilePlayer class at that time. Note that the order varies at each run. Sometimes the FilePlayer class is added second or third, sometimes first. I don't know if this is because of the way Java calls the processes, or if class initialization in ChucK happens after file processing. So I would be fine if I could call for each file: 'chuck -add fileplayer.ck chuckdemo.ck:with:a:lot:of:params', but after the first file ChucK is bailing out: [fileplayer.ck]:line(1): class/type 'FilePlayer' is already defined in namespace 'global' why can't it just ignore this? Arthur

On Sep 3, 2007, at 8:56 PM, Kassen wrote:

On 9/3/07, Arthur Clemens wrote:

No, this is just because of the way applets are quit in Java. If 'chuck --kill' is sent the processed are killed normally, so ChucK behaves predictable

Ok, so the issue is that ChucK keeps running when Processing is killed? If that's a real problem you could try to make ChucK poll processing over OSC every second or so and if it isn't running ChucK could send a system command to kill ChucK.

I have to try this. It would mean I have a message sent from Processing at least once in a while.

The public class not used in the demo, but I kept the file because that is the way I would ideally solve it.

That's what I suspected now.

<snip> So even if 'fileplayer.ck' is called earlier, it is added last to the VM. First the chuckdemo.ck files are run and they do not know any FilePlayer class at that time. Note that the order varies at each run. Sometimes the FilePlayer class is added second or third, sometimes first.

I don't know if this is because of the way Java calls the processes, or if class initialization in ChucK happens after file processing.

This is very odd, I'm inclined to suspect Processing is sending the commands in the wrong order.

The commands are sent in the right order. But they are sent though Java processes, and I don't know how Java handles these calls.

What you could do is start ChucK using this;

chuck --loop fileplayer.ck

That should force it to be added at the right moment.

This works. But this is not a flexible solution from a Processing user point of view. I would prefer to use a generic setup. Arthur

Ok, so the issue is that ChucK keeps running when Processing is killed? If that's a real problem you could try to make ChucK poll processing over OSC every second or so and if it isn't running ChucK could send a system command to kill ChucK.

How would this work? Unfortunately there is no command 'Machine.kill ()'. 'Machine.crash()' is not so neat. Also, I cannot use 'OscEvent oeAlive => now;' because that will wait for the message that will not arive anymore... Arthur

I have solved 1 main problem: starting and stopping Chuck by Processing. I have created a 'monitor' chuck file that listens for incoming events and shuts down Chuck when it no longer receives any messages. New demo + video: http://visiblearea.com/blog/bin/view/VisibleArea/ ProcessingandChucKHelloWorlddemo Arthur On Sep 5, 2007, at 1:45 AM, Kassen wrote:

On 9/5/07, Arthur Clemens wrote:

...

Ok, so the issue is that ChucK keeps running when Processing is killed? If that's a real problem you could try to make ChucK poll processing over OSC every second or so and if it isn't running ChucK could send a system command to kill ChucK.

How would this work? Unfortunately there is no command 'Machine.kill ()'. 'Machine.crash()' is not so neat.

The easiest and safest way is probably to use the standard library function that issues a call to the OS and have the OS execute "chuck --kill". The advantage of this is that it will also work in the case the VM is set to --loop.

This would elimiate the need for the sugestion below since you could have Processing ask ChucK to terminate directly (or more precicely; have Processing ask ChucK to ask the OS to terminate ChucK).

That being said; now that I think about it I have no idea why there is no Machine.kill() command. Considdering that defining public classes will make changes to the VM that can't be undone from within ChucK it would seem ballanced to be able to destroy the VM from within ChucK without crashing.

Also, I cannot use 'OscEvent oeAlive => now;' because that will wait for the message that will not arive anymore...

Yes. True. A clean solution would be to have your OSC parsing function write "now" to a variable of type "time" named "last_time_we_heard_from_processing" (or the like) every time a OSC event comes in. Then you could have a function that would periodically substract this from "now" and if the outcome is longer then -say- ten seconds this shred would call for the destruction of the VM. The exact tuning of this might need some care because obviously we wouldn't want to accidentally destroy the VM (and we don't want to wait more then we have to) but as a general principle this seems like a good plan to me and it also deals with the chance that processing would crash/get stuck. You might want to check / examples/time/ for details on how variables of the type "time" work.

Disclaimer; these sound like good plans to me but I don't think I ever actually tried either. May catch fire, no waranties, no refunds.

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

On 9/5/07, Arthur Clemens wrote:

...

Ok, so the issue is that ChucK keeps running when Processing is killed? If that's a real problem you could try to make ChucK poll processing over OSC every second or so and if it isn't running ChucK could send a system command to kill ChucK.

How would this work? Unfortunately there is no command 'Machine.kill ()'. 'Machine.crash()' is not so neat.

The easiest and safest way is probably to use the standard library function that issues a call to the OS and have the OS execute "chuck --kill". The advantage of this is that it will also work in the case the VM is set to --loop. This would elimiate the need for the sugestion below since you could have Processing ask ChucK to terminate directly (or more precicely; have Processing ask ChucK to ask the OS to terminate ChucK). That being said; now that I think about it I have no idea why there is no Machine.kill() command. Considdering that defining public classes will make changes to the VM that can't be undone from within ChucK it would seem ballanced to be able to destroy the VM from within ChucK without crashing. Also, I cannot use 'OscEvent oeAlive => now;' because that will wait

for the message that will not arive anymore...

Yes. True. A clean solution would be to have your OSC parsing function write "now" to a variable of type "time" named "last_time_we_heard_from_processing" (or the like) every time a OSC event comes in. Then you could have a function that would periodically substract this from "now" and if the outcome is longer then -say- ten seconds this shred would call for the destruction of the VM. The exact tuning of this might need some care because obviously we wouldn't want to accidentally destroy the VM (and we don't want to wait more then we have to) but as a general principle this seems like a good plan to me and it also deals with the chance that processing would crash/get stuck. You might want to check /examples/time/ for details on how variables of the type "time" work. Disclaimer; these sound like good plans to me but I don't think I ever actually tried either. May catch fire, no waranties, no refunds. Hope that helps, Kas.

I read those this afternoon. One factual note; functions have their own name-space as well. One opinion; I completely fail to see what's wrong with "miniaudicle" as a name. One helpfull note; garbage collection is indeed a issue but in most cases a lot can be done to avoid generating garbage, both Ugens and sporked functions can be re-used, etc. Aside from those I look forward to reading more about your progress. Cheers, Kas. On 9/2/07, robin.escalation wrote:

My blog diagrammes modernes now has several articles of interest to this community, including one on ChucK. More are coming soon, and as I have 50K hits a year this might help spread the word!

Surf: http://diagrammes-modernes.blogspot.com/

-- robin

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

On 9/3/07, robin.escalation wrote:

...

One factual note; functions have their own name-space as well.

OK. I am already missing the package / module concept however.

I'm not sure what those are or why we need them, could you kindly explain?

One opinion; I completely fail to see what's wrong with

...

"miniaudicle" as a name.

Well, there's no such thing as an "audicle" so tacking on the prefix "mini" makes it less than informative as to what it might actually be.

At this stage I suspect I need to point something out to you; http://audicle.cs.princeton.edu/ There in fact is a "Audicle" but it can be quite heavy on the CPU and GPU, the MiniAudicle is a smaller version with the most important elements yet a far smaller footprint resource-wise. This makes a lot of sense, IMHO. That said I also hate the name "ChucK", especially with that

spelling, but thought it impolite to mention that as well. ;-)

One has to admit that Supercollider is a very cool name!

SuperCollider has a very cool name, I admit. Future writers might engage in long articles interperting the act of chucking something in comparision to the effect of it colliding against something else *ducks*. If all else fails you can re-name the executable. ;¬)

Yes, I saw some code for that somewhere. Though it's nice to have a workaround, it does make what should be trivial into something less than trivial.

Yes, that's true. We definately need garbage collection but in practice I don't think too many people are stuck now without it because in most cases it's not a issue at all. If you are writing code for a instalation it could become a very real matter but at that point whatever you write will need to be double-checked so many times that working around garbage will mostly be a relatively minor adition to this work-load. Kas.

On 9/3/07, robin.escalation wrote:

...

I'm not sure what those are or why we need them, could you kindly explain?

I'll explain using Python, which I am the most familiar with. Each file of code is a module, which can contain an arbitrary number of functions or classes. Each of these has their own addressable namespace, but the key thing is that the module itself has its own namespace too.

Ok, got it.

As I understand it, in ChucK there is nothing similar to an import. Files do not have explicit namespaces, though one is created if a file is sporked as a shred. But this is not addressable, it merely keeps private data in each process from colliding. A further limitation is there can be only one public class in a file.

Yes, you are right. As you might've seen in the list archives; we just went trough a process where everybody could list his/her wishes and sugestions for chucK and a import/inclusion process turned out to be very high on that list. Likely this will (have to?) bring a more sophisiticated namespace method with it. In my own experience the current method covers the needs of chucK. Another matter is that in the past far more people ran into a desire to have seperate elements share their namespace then that ran into the desire for more seperation. Perhaps this will change as imports/inclusions make it easier and more inviting to start larger projects.

Oh yes, I know about the audicle and have tried it. Someday this might rule the world. But it's still not a word. :-)

Ah, sorry, for a moment I thought you were unaware of the Audicle. Personally I like how it's named; it's a new thing, arguably it's a completely new *sort* of thing so it has a new name. The same hold true for "spork". "Cubase" isn't a word either yet that doesn't seem to cause any confusion or loss of sales either compared to "Logic", "Sonar" or "Live" which are words.

SuperCollider has a very cool name, I admit. Future writers might

...

engage in long articles interperting the act of chucking something in comparision to the effect of it colliding against something else *ducks*.

This would be good fun and is not totally a joke. As a poet I would argue that how we name things and what language we choose to describe them affects how we work with them in an intimate way.

Yeah, absolutely. SC-fanatics will likely interpert the analogies with a different emphasis, could be a fun debate :¬) One of the reasons I like ChucK is that the expressive use of the

language, especially the chuck operator, makes good sense to me for the domain of audio operations.

Same here. After a long time of thinking like "sending this there, then making foo go to bar and seeing what happens" the "ChucK" name might well become more apealing to you. I mean; we realy are sending stuff in directions, sometimes like a ninja throwing stars, at others more like a drunk garbage-man. Perhaps ChucK will once get so mature and stable that "chucking" no longer seems like a apropriate analogy, perhaps at that stage we will have to considder a different name that expresses a more precise and controlled sort of throwing. Perhaps "ParticleAccelerator" ;¬). Cheers, Kas. P.S. joking aside I think SC is great and so are my SC-using friends, I believe we can learn a lot from them.

Hi Eduard and all, Thanks for narrowing this down and reporting it! We have repro bug, and have tracked it down to incorrect handling of multi-expression on the third clause in for loop statements. The happens both inside and out of class definitions, but is more crash-prone when inside the class. The fix is in CVS. Anyone else notice anything else fishy with new release (aside from known bugs)? If there is enough cause, we may do an incremental release. Thanks again! Best, Ge! On Sep 3, 2007, at 9:22 AM, eduard aylon wrote:

Hello all,

It's weird, but I think there may be a bug in for-loop's declaration when used inside a class. Not sure it has been discussed earlier. The code below explains it better than words. Can anyone try if it gives a Bus Error when using myClass2? BTW, I'm using Chuck-1.2.1.0

// *********************************** // this is ok int i, j;

for( 0 => i => j; i < 12; 3 +=> i, j++ ) { <<< i, j>>>; }

// *********************************** //this class is ok class myClass1 { int i, j;

for( 0 => i => j; i < 12; 3 +=> i ) { <<< i, j++>>>; // note j is incremented here } }

// *********************************** // next class is not ok: seems that declaring 2 increments at the end of the for-loop declaration rises a Bus Error. class myClass2 { int i, j;

for( 0 => i => j; i < 12; 3 +=> i, j++ ) // note i and j are incremented here and this is supposedly the problem { <<< i, j>>>; } }

myClass2 c;

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

I will not quote all of Gatti Lorenzo's post, which basically suggested adding (most of) the Python namespace and import features into ChucK. I think this would be wonderful and furthermore concur with those features that needn't be implemented. I would like to point out that the import mechanism relies on having a list of paths to search in order to find the libraries. This would also be needed in Chuck. Specifying such a list could happen in an environment variable, configuration file, command-line argument, or some combination of all three. -- robin

Gatti Lorenzo wrote:

A significant difference in usage between Python and ChucK is that Python libraries and extensions tend to be either an integral part of a project or stable shared dependencies of other libraries or applications, while most ChucK libraries can be expected to be

1) experimental or hacked versions of standard library modules, overriding the originals

2) foreign and/or hacked code adopted from other people

3) personal work-in-progress toolboxes.

Actually I don't see how this is really different for the two languages. If anything it's a difference of degree and not of kind. I hack lots of my own libraries in Python, and some of these fit all the above categories. In no cases do I want to store them in the application tree, and so I need to be able to specify where they are. I am not a big fan of environment variables, since they are global for all apps on the system. I take it from your comments you are of like mind. However they are simple solutions that work for simple cases. Other solutions are better.

There are two mostly orthogonal important design decisions about library search paths on the command line: whether to specify directories (including all their content) or single files and whether the list of library locations should be in a command line option or indirectly referenced from a configuration file.

In the first case: why not both? A path could point to either a file of a folder. In the second: A configuration file is more flexible. The command-line can reference it, reducing verbosity. Multiple configs can be maintained for different environments. Apps could alter the config file directly (OK, not ChucK apps... yet) for further flexibility (and potential mayhem!). The config can be a simple list of paths. When searching for a file to import, ChucK first looks in the folder of invocation, then in the config file, reading bottom up, then lastly in the ChucK application mandated location. This means that a file I'm hacking in the current folder will be found first. If the file isn't there, it will be loaded from one of my library locations, and finally the standard library. The same sort of search could be done to find data files, like wavs to open. Similarly, to find the config file itself, ChucK looks first on the command-line, next in the invocation folder, and lastly in the ChucK application folder. (And maybe looks to an environment variable.) -- robin

--- Kassen wrote:

I'm forwarding this to the Forum admins.

Thanks. Got a message from them.

I find there is very little double-posting between the forum and the list, ech has it's own little culture and emphasis even if many people are on both. To me it seems that the forum is generally a bit more practical in nature while the topics on the list have a tendency towards the theoretical. Perhaps most importantly it's looking like the forum is more accesible to people curious about ChucK.

So would it be better for me to ask my practical questions on the forum? I don't want to start double-posting and spamming people. -- robin

I started with the pan example with a gain setting added to prevent my head from getting blown off: // white noise pan Noise n => Pan2 p => dac; .4 => n.gain; while(true) { Math.sin( now / 3::second * 2 * pi ) => p.pan; 10::ms => now; } I wanted to generalise this to several outputs, so I recoded it: // white noise pan without using Pan2 Noise n; n => Gain gleft => dac.left; n => Gain gright => dac.right; .4 => n.gain; 5::second => dur period; while(true) { (Math.sin( now / period * 2 * pi ) +1) / 2 => float amount; amount => gleft.gain; 1-amount => gright.gain; 10::ms => now; } I made sure I had all 8 outputs turned on my soundcard by running this in one window: chuck --out(8) --loop Then, in a second window I fed it the shreds. The two above worked fine. So, I tried this: // white noise four-channel "pan" Noise n; n => Gain gfl => dac.chan(1); n => Gain gfr => dac.chan(2); n => Gain grl => dac.chan(3); n => Gain grr => dac.chan(4); .4 => n.gain; 5::second => dur panperiod; 6::second => dur fadeperiod; while(true) { (Math.sin( now / panperiod * 2 * pi ) +1) / 2 => float panamount; (Math.sin( now / fadeperiod * 2 * pi ) +1) / 2 => float fadeamount; panamount * fadeamount => gfl.gain; (1-panamount) * fadeamount => gfr.gain; panamount * (1-fadeamount) => grl.gain; (1-panamount) * (1-fadeamount) => grr.gain; 10::ms => now; } And got this: NullPointerException: (UGen link) in shred[id=1:x.ck], PC=[33] I have no idea how to use this to diagnose the issue. I am using the latest win32 ASIO build. -- robin