Hi, I wanted to comment about things that i don't find yet on chuck which i would prioritize; please, take this freely as some brainstorming from a guy that has been using SuperCollider3 for some time and finds appealing the sample-accurate emphasis in Chuck. * ugen/plugin infrastructure; what headers you include? what classes you inherit? *block processing; i find amazing the feeling of putting your code directly into the sample stream, but i realize that it comes with a price; but before talking about block processing i wanted to ask first about; *** how much multithread-eable could be chuck; in other words, how possible is to implement shreds in a true multithreaded mode where each shred can run in a different core, but keeping the sample-synchronous approach? i imagine one could relax that to a "block-synchronous" multi-shreding. Currently one could have a chuck instance per core and pipe outs and in thru jack, but this would fix the block frame size to whatever jack is set to. * dynamic allocation of resources; of course, this could be implemented on top of the language; for example, creating a fixed number of audio buffers and calling .read as a score progresses a number of times in the same sndbuf object would (i imagine) free the previous allocated buffer and alloc for the new one. --------------------------------- 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo Abrí tu cuenta aquí
Here's an example usage: in one command line: C:\Documents and Settings\Graham>chuck --loop [chuck](VM): sporking incoming shred: 1 (scale.ck)... [chuck](VM): sporking incoming shred: 2 (pop1_fm1.ck)... [chuck](VM): replacing shred 2 (pop1_fm1.ck) with 2 (pop1_fm1.ck)... <vm stops> in another one: C:\Documents and Settings\Graham\My Documents\chuck>chuck + scale.ck sessions\po p1\pop1_fm1.ck [chuck(remote)]: operation successful C:\Documents and Settings\Graham\My Documents\chuck>chuck = 2 sessions\pop1\pop1 _fm1.ck [chuck(remote)]: operation successful The sound begins to skip, and we get an error dialog: "chuck.exe has encountered a problem and needs to close. We are sorry for the inconvenience." If you debug the process in Visual Studio, you get: Unhandled exception at 0x0041117c in chuck.exe: 0xC0000005: Access violation reading location 0x00000000. Strangely, replacement works great with the Audicle. Which is a joy to use! best, Graham PS Is there a way to search the list archives? I want to make sure I'm not double posting previous issues.
Hi Graham, Are you using 1.2.0.0? The crash on replace bug has been fixed since. Try upgrading to the current version. There have been a few API changes between then and now, most notably std.abs( float ) became std.fabs( float ) and std.abs( int ) and hmm that may be it if you are going directly from 1.2.0.0 to 1.2.0.4. (If this is happening with a more recent version of chuck, then we got a new bug to track down) As for search through the archives, I don't know if it's possible with the version of mailman our department is running. If anyone knows how, please post. Thanks! Best, Ge! On Feb 15, 2006, at 6:26 PM, Graham Coleman wrote:
Here's an example usage:
in one command line: C:\Documents and Settings\Graham>chuck --loop [chuck](VM): sporking incoming shred: 1 (scale.ck)... [chuck](VM): sporking incoming shred: 2 (pop1_fm1.ck)... [chuck](VM): replacing shred 2 (pop1_fm1.ck) with 2 (pop1_fm1.ck)... <vm stops>
in another one: C:\Documents and Settings\Graham\My Documents\chuck>chuck + scale.ck sessions\po p1\pop1_fm1.ck [chuck(remote)]: operation successful
C:\Documents and Settings\Graham\My Documents\chuck>chuck = 2 sessions\pop1\pop1 _fm1.ck [chuck(remote)]: operation successful
The sound begins to skip, and we get an error dialog: "chuck.exe has encountered a problem and needs to close. We are sorry for the inconvenience."
If you debug the process in Visual Studio, you get: Unhandled exception at 0x0041117c in chuck.exe: 0xC0000005: Access violation reading location 0x00000000.
Strangely, replacement works great with the Audicle. Which is a joy to use!
best,
Graham
PS Is there a way to search the list archives? I want to make sure I'm not double posting previous issues. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Ge, Thanks! I was using an old binary. 1.2.0.4 seems to be up. And I should be able to try rolling my own as well. thanks, Graham On Wed, 15 Feb 2006, Ge Wang wrote:
Hi Graham,
Are you using 1.2.0.0? The crash on replace bug has been fixed since. Try upgrading to the current version. There have been a few API changes between then and now, most notably std.abs( float ) became std.fabs( float ) and std.abs( int ) and hmm that may be it if you are going directly from 1.2.0.0 to 1.2.0.4.
(If this is happening with a more recent version of chuck, then we got a new bug to track down)
As for search through the archives, I don't know if it's possible with the version of mailman our department is running. If anyone knows how, please post.
Thanks!
Best, Ge!
On Feb 15, 2006, at 6:26 PM, Graham Coleman wrote:
Here's an example usage:
in one command line: C:\Documents and Settings\Graham>chuck --loop [chuck](VM): sporking incoming shred: 1 (scale.ck)... [chuck](VM): sporking incoming shred: 2 (pop1_fm1.ck)... [chuck](VM): replacing shred 2 (pop1_fm1.ck) with 2 (pop1_fm1.ck)... <vm stops>
in another one: C:\Documents and Settings\Graham\My Documents\chuck>chuck + scale.ck sessions\po p1\pop1_fm1.ck [chuck(remote)]: operation successful
C:\Documents and Settings\Graham\My Documents\chuck>chuck = 2 sessions\pop1\pop1 _fm1.ck [chuck(remote)]: operation successful
The sound begins to skip, and we get an error dialog: "chuck.exe has encountered a problem and needs to close. We are sorry for the inconvenience."
If you debug the process in Visual Studio, you get: Unhandled exception at 0x0041117c in chuck.exe: 0xC0000005: Access violation reading location 0x00000000.
Strangely, replacement works great with the Audicle. Which is a joy to use!
best,
Graham
PS Is there a way to search the list archives? I want to make sure I'm not double posting previous issues. _______________________________________________ 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 is awesome, but here are some things that are weird, or suggestions, or even just idle questions: 0. ChucK is fun and awesome. 1. ChucK performance ChucK hiccups from time to time, and this has been mentioned on lists. But where are the main inefficiencies? How could hiccups be avoided? 2. Local class library It would be nice to automatically load local utility classes. 3. Globals? Given the ire surrounding them, this is more a question rather than a suggestion. It seems very natural for syncronized music-processes to want to share data, and static class data seems like a heavyweight (in terms of lines of code and syntax) way of doing this, (esp. given you can't currently redefine or reevaluate classes). But do we want global variables and refs, or will that just make things messier? Or is there some novel abstraction for sharing data that will work better in this domain? 4. Reevaluating Classes Discussed above. best, Graham
Hi Graham!
ChucK hiccups from time to time, and this has been mentioned on lists. But where are the main inefficiencies? How could hiccups be avoided?
ChucK is the main inefficiency, huh huh. As for reducing hiccups, there are several ways, depending on the hiccups you are experiencing. One common type of hiccup arises when a shred is added and then tries to load a big sound file. Since we haven't implemented chunking in sndbuf yet (it's on the todo list), a sufficiently large file will cause the hiccups. you can try to alleviate the problem for smaller files by using a bigger buffer size, for example when starting the chuck listener loop: chuck --loop --bufsize2048 However, this is more complicated on Windows XP, since we seem to be having audio problems when using a buffer size greater than 512 since upgrading to the new RtAudio, which drastically improved latency on Window XP, but for some reason isn't liking large buffer sizes.
2. Local class library
It would be nice to automatically load local utility classes.
Also in the works, though the implementation may not happen for a few more releases.
3. Globals?
Theoretically we have global variables and functions. You can declare a public class with static members and those should be accessible by all subsequent code. For example: public class The { static int number; // a bug forces one to declare static objects as references static Event @ event; } // instantiate the event outside (thanks to bug) new Event @=> The.event; Having first compiled the file containing The, subsequent code should be able to access The.number and The.event. Also previous related discussion: https://lists.cs.princeton.edu/pipermail/chuck-users/2005-November/ 000164.html https://lists.cs.princeton.edu/pipermail/chuck-users/2005-November/ 000165.html Best, Ge!
Our discussion made me think of other issues: 5. Stk imports respond to different messages I often switch out STK instruments in ChucKing sessions, and occasionally they differ as to which basic stk messages they respond to. For example, Mandolin doesn't respond to noteOn, but it works with pluck. At least Wurley doesn't seem to respond to noteOff. It seems like many basic messages could be standardized in a common interface for STK instruments. This could be taken farther by generalizing over the different control change parameters for orchestras of instruments, but you could probably accomplish this better with a wrapper class. 6. Samples Someone mentioned this at some point. Will ChucK have a library of sampled instruments? Or will performers construct or import their own and wrap them in code? good much work, Graham On Wed, 15 Feb 2006, Ge Wang wrote:
Hi Graham!
ChucK hiccups from time to time, and this has been mentioned on lists. But where are the main inefficiencies? How could hiccups be avoided?
ChucK is the main inefficiency, huh huh. As for reducing hiccups, there are several ways, depending on the hiccups you are experiencing.
One common type of hiccup arises when a shred is added and then tries to load a big sound file. Since we haven't implemented chunking in sndbuf yet (it's on the todo list), a sufficiently large file will cause the hiccups. you can try to alleviate the problem for smaller files by using a bigger buffer size, for example when starting the chuck listener loop:
chuck --loop --bufsize2048
However, this is more complicated on Windows XP, since we seem to be having audio problems when using a buffer size greater than 512 since upgrading to the new RtAudio, which drastically improved latency on Window XP, but for some reason isn't liking large buffer sizes.
2. Local class library
It would be nice to automatically load local utility classes.
Also in the works, though the implementation may not happen for a few more releases.
3. Globals?
Theoretically we have global variables and functions. You can declare a public class with static members and those should be accessible by all subsequent code. For example:
public class The { static int number;
// a bug forces one to declare static objects as references static Event @ event; }
// instantiate the event outside (thanks to bug) new Event @=> The.event;
Having first compiled the file containing The, subsequent code should be able to access The.number and The.event.
Also previous related discussion:
https://lists.cs.princeton.edu/pipermail/chuck-users/2005-November/ 000164.html
https://lists.cs.princeton.edu/pipermail/chuck-users/2005-November/ 000165.html
Best, Ge!
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
This is more consistent in STK, but we seem to have lost some things in translation. Ge is currently working on fixing up ChucKSTK, and we'll try to get things more consistent. On Thu, 16 Feb 2006, Graham Coleman wrote:
Our discussion made me think of other issues:
5. Stk imports respond to different messages
I often switch out STK instruments in ChucKing sessions, and occasionally they differ as to which basic stk messages they respond to.
For example, Mandolin doesn't respond to noteOn, but it works with pluck. At least Wurley doesn't seem to respond to noteOff.
It seems like many basic messages could be standardized in a common interface for STK instruments.
This could be taken farther by generalizing over the different control change parameters for orchestras of instruments, but you could probably accomplish this better with a wrapper class.
6. Samples
Someone mentioned this at some point. Will ChucK have a library of sampled instruments? Or will performers construct or import their own and wrap them in code?
good much work,
Graham
On Wed, 15 Feb 2006, Ge Wang wrote:
Hi Graham!
ChucK hiccups from time to time, and this has been mentioned on lists. But where are the main inefficiencies? How could hiccups be avoided?
ChucK is the main inefficiency, huh huh. As for reducing hiccups, there are several ways, depending on the hiccups you are experiencing.
One common type of hiccup arises when a shred is added and then tries to load a big sound file. Since we haven't implemented chunking in sndbuf yet (it's on the todo list), a sufficiently large file will cause the hiccups. you can try to alleviate the problem for smaller files by using a bigger buffer size, for example when starting the chuck listener loop:
chuck --loop --bufsize2048
However, this is more complicated on Windows XP, since we seem to be having audio problems when using a buffer size greater than 512 since upgrading to the new RtAudio, which drastically improved latency on Window XP, but for some reason isn't liking large buffer sizes.
2. Local class library
It would be nice to automatically load local utility classes.
Also in the works, though the implementation may not happen for a few more releases.
3. Globals?
Theoretically we have global variables and functions. You can declare a public class with static members and those should be accessible by all subsequent code. For example:
public class The { static int number;
// a bug forces one to declare static objects as references static Event @ event; }
// instantiate the event outside (thanks to bug) new Event @=> The.event;
Having first compiled the file containing The, subsequent code should be able to access The.number and The.event.
Also previous related discussion:
https://lists.cs.princeton.edu/pipermail/chuck-users/2005-November/ 000164.html
https://lists.cs.princeton.edu/pipermail/chuck-users/2005-November/ 000165.html
Best, Ge!
_______________________________________________ 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
Theoretically we have global variables and functions. You can declare a public class with static members and those should be accessible by all subsequent code. For example:
public class The { static int number;
// a bug forces one to declare static objects as references static Event @ event; }
Static variables in public classes work for sharing data. But perhaps there is a more elegant way to do this. If you want to share just a bit of data between future shreds, one must use two of lines syntax minimally, but it's big on words and punctuation and short on meaning: public class Foo { static int bar; } 4 => Foo.bar; If I define a class in a shred file and make changes, the VM doesn't allow you to redefine the class (so you must remove it from your buffer). This is a temporary practical problem. Also, it semantically implies there is some class of objects called Foo, and bar is a piece of data that relates to all of them. We aren't really sharing data between instances of Foo, we're sharing data among shreds. We are only using classes for this because it allows us to hijack a global namespace in the VM (the namespace of classes) for sharing data. We could also do this by having a machine-wide dictionary: machine.set( "beatEvent", new Event ); //this has typing issues or perhaps like this: 3 => glob int bar; //this has a bad reputation Globals have a bad reputation for cluttering programs. But in this case using class data isn't much better, and requires more meaningless syntax. Of course, static class data does have some things going for it. Overall, the syntax of ChucK is very minimal, and it conforms to the expectation of standard languages (mostly C++ and Java). This makes it easier to learn and understand, and it might make it more timeless. For a java programmer, storing global data in class (static) variables provides minimal surprise. Arguably, live-coding environments are subject more pressure than systems and applications languages to be clear and to be terse. best, Graham
Hi Charlls!
* ugen/plugin infrastructure; what headers you include? what classes you inherit?
While the framework for both statically and dynamically adding new classes and unit generators exists, only the static one is exposed. Look into any of the ugen_*.cpp or ulib_*.cpp as an example. These are pretty cumbersome, we definitely hope to improve them at some point.
*** how much multithread-eable could be chuck; in other words, how possible is to implement shreds in a true multithreaded mode where each shred can run in a different core, but keeping the sample-synchronous approach?
Having multi-core isn't hard, but keeping the sample-synchronous nature between cores may be really difficult to do efficiently. This is the subject of future research.
i imagine one could relax that to a "block-synchronous" multi-shreding.
There has been some thought put into adaptively optimizing by putting things into blocks when possible, as advised by the shreduler. There was a discussion of it here: https://lists.cs.princeton.edu/pipermail/chuck-dev/2005-September/ 000090.html https://lists.cs.princeton.edu/pipermail/chuck-dev/2005-September/ 000091.html
* dynamic allocation of resources; of course, this could be implemented on top of the language; for example, creating a fixed number of audio buffers and calling .read as a score progresses a number of times in the same sndbuf object would (i imagine) free the previous allocated buffer and alloc for the new one.
There is certainly a goal. Currently we can dynamically allocate objects in the language (via new) but garbage collection isn't done yet. This will hopefully be finished in the very near future. Best, Ge!
participants (4)
-
Charlls Quarra -
Ge Wang -
Graham Coleman -
Perry R Cook