Hi I'm trying to make my huge live-thingy run under 1.2.1.2. I've narrowed the first problem down to the following code, that runs fine in 1.2.1.1b but segfaults in 1.2.1.2. Any input on what's changed and how to make the sniplet work in 1.2.1.2 would be greatly appreciated! public class Time { new Shred @=> static Shred @ ticker_shred; public static void start(){ spork ~ ticker() @=> ticker_shred; } public static void ticker(){ while(true){ 1::ms => now; } } } Time dummy; dummy.start(); 100::week => now; Thank in advance for any feedback. -- Atte http://atte.dk http://modlys.dk
Atte,
This seems to work:
public class Time {
static Shred @ ticker_shred;
public static void start(){
spork ~ ticker() @=> ticker_shred;
}
public static void ticker(){
while(true){
1::ms => now;
}
}
}
Time dummy;
dummy.start();
100::week => now;
I'm not sure why you wanted the "new Shred" instantiation there... I
think instantiation is implicit.
Cheers,
Mike
On Sat, Jan 24, 2009 at 9:57 AM, Atte André Jensen
Hi
I'm trying to make my huge live-thingy run under 1.2.1.2. I've narrowed the first problem down to the following code, that runs fine in 1.2.1.1b but segfaults in 1.2.1.2. Any input on what's changed and how to make the sniplet work in 1.2.1.2 would be greatly appreciated!
public class Time { new Shred @=> static Shred @ ticker_shred; public static void start(){ spork ~ ticker() @=> ticker_shred; } public static void ticker(){ while(true){ 1::ms => now; } } } Time dummy; dummy.start(); 100::week => now;
Thank in advance for any feedback.
-- Atte
http://atte.dk http://modlys.dk _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Mike said; I'm not sure why you wanted the "new Shred" instantiation there... I
think instantiation is implicit.
I think it was a attempt to get around the issue with instantiating non-primitive static objects. It's not clear to me why your version would work or why Atte's original one used to work in the last version of ChucK; Shreds aren't primitives. It's cool that it does work now but but I don't understand why this is a exception. Yours, Kas.
I think it has something to do with this bug about spork returning
Shreds. This works:
fun void foo() {
while( true ) {
1::second => now;
<<< "hi, I'm foo." >>>;
}
}
// okay...
spork ~ foo() @=> Shred s;
while( true ) {
while( true ) {
1::second => now;
<<< "s.id = ", s.id() >>>;
}
}
However, this crashes chuck:
fun void foo() {
while( true ) {
1::second => now;
<<< "hi, I'm foo." >>>;
}
}
// not okay...
Shred s;
spork ~ foo() @=> s;
while( true ) {
while( true ) {
1::second => now;
<<< "s.id = ", s.id() >>>;
}
}
I ran into this a while back. It worked with the previous version of
chuck, but not the latest.
-Mike
On Sat, Jan 24, 2009 at 2:12 PM, Kassen
Mike said;
I'm not sure why you wanted the "new Shred" instantiation there... I think instantiation is implicit.
I think it was a attempt to get around the issue with instantiating non-primitive static objects.
It's not clear to me why your version would work or why Atte's original one used to work in the last version of ChucK; Shreds aren't primitives. It's cool that it does work now but but I don't understand why this is a exception.
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
mike clemow wrote:
static Shred @ ticker_shred;
I'm not sure why you wanted the "new Shred" instantiation there... I think instantiation is implicit.
I think it was attempt to work around something unneeded. Your suggestion worked just great! Interesting (I think): Changing this single line (out of 9511) of my setup makes it run on 1.2.1.2 (and it also works on 1.2.1.1b). Thanks for you help! I still don't understand why it works and my code doesn't, but maybe that's ok... -- Atte http://atte.dk http://modlys.dk
Atte; Thanks for you help! I still don't understand why it works and my code
doesn't, but maybe that's ok...
That's perfectly ok for your code, it's probably a rare non-trivial ChucK project that doesn't work around some issues here and there and your "live-thingy" seems to be over three times the size of mine, at least when we express size in lines of code (which is probably even a valid metric if we're talking ChucK issues). I don't think it's ok in general. I'm not sure I agree with Mike's hunch of blaming the return process of the spork function. My hunch is that we are dealing with a instantiation error related to the rather loose link bwetween objects of type Shred and actual shreds that are running processes. I say that because I find it rather odd that you can instantiate a non-primitive static object inside a public class; you can't do that for other non-primitives so something about the instantiation of Shred objects must be unusual. It may be a bit odd to find the one type of non-primitive that actually behaves propperly there and *doesn't* require a workaround suspicious... maybe we should be thankful instead but I still suspect it's to blame. As an aside; I'm very interested in ChucK based live setups. Are there any videos/texts/audio-recordings about your system online? If not would you have the time to entertain me with some notes on your approach? Yours, Kas.
Kassen wrote:
As an aside; I'm very interested in ChucK based live setups. Are there any videos/texts/audio-recordings about your system online? If not would you have the time to entertain me with some notes on your approach?
I have a little less than an hour of live recording from last summer + some video of the same concert. The video is giving me a hard time, but I could get the audio prepared and put it up somewhere, if you're interested... -- Atte http://atte.dk http://modlys.dk
Atte; I have a little less than an hour of live recording from last summer + some
video of the same concert. The video is giving me a hard time, but I could get the audio prepared and put it up somewhere, if you're interested...
I'm interested. I'm also particularly interested in the "how" and "why" questions. I believe that programming a system for performing music comes down to defining (part of) what you think about music so I'd like to hear what drove you to create your own. That is of course provided you have the time and inclination to go into such subjects at all. Yours, Kas.
Hi all, I just thought I'd pop in and second this. Kassen:
I'm interested. I'm also particularly interested in the "how" and "why" questions. I believe that programming a system for performing music comes down to defining (part of) what you think about music so I'd like to hear what drove you to create your own. That is of course provided you have the time and inclination to go into such subjects at all.
I'm working towards live performance at some point, and I've been banging around ideas in my head, and it'd be really nice to hear your thoughts (both of you) on how you set up your systems. Cheers, Rogan
Rogan;
I'm working towards live performance at some point, and I've been banging around ideas in my head, and it'd be really nice to hear your thoughts (both of you) on how you set up your systems.
Sure. The main thing that I did was simplify and take shortcuts in the interest of fast input; lots of emphasis on physical movement and none on graphical feedback. I think I posted these links to this list before but I'm lazy so if I wrote/did something before I might as well link to it; http://www.leonardo.info/lmj/lmj18contribnotes.html (general description, scroll down about 3/4th of the document) http://steim.org/jamboree08/?p=437 (text about a presentation I did) http://steim.org/jamboree08/?p=571 (video of the same thing) That should at least give you a rough idea of my direction and setup. Yours, Kas.
Kassen wrote:
I'm interested. I'm also particularly interested in the "how" and "why" questions. I believe that programming a system for performing music comes down to defining (part of) what you think about music so I'd like to hear what drove you to create your own. That is of course provided you have the time and inclination to go into such subjects at all.
First I must tell a little bit about the kind of music that I'm doing in this particular project. It's obviously electronic, but not very loop based. Although it's not pop it uses to some extend the pop forms like intro, verse, chorus. Also it has chord changes like a pop song, and those changes might be different for each song part. And finally it involves a double bass player and a singer (besides me and a vj). Maybe it's time for some music. These are the first two tracks of the first concert with chuck. They might be representative of what I do live, something algorithmic, something prepared, something weird (for the regular listener) and something poppy. Notes 1) The thing blowing up between tracks is my micron, 2) the muddy sound on the vocals should be better next time, 3) besides the vocal the bass and the blow-up in the transition everything is chuck. http://atte.dk/download/01_train.mp3 http://atte.dk/download/02_holde_pkt.mp3 One of my main motivations was to be able to make something that is flexible like a real band. I want to be able to jam with it, take the dynamics down, repeat a part, stay on a part, and play solo (either with synth, game pad or melodica) over it. With this small band I soon felt it would be a waste of my hands and mind to simply play any single part unless it would be possible to modulate the whole piece dramatically with that specific part. In stead my role is to modulate the whole "band", kind of like a director, deciding in real time which part comes next, taking certain instruments out and controlling the music in more general terms. Everything is controlled from a bcr2000, and I play a little on a keyboard and a game pad. So my system lets me program "patterns" like a synth part, or a drums part, each of which is a single .ck file. They have a degree of either randomness to them or are actual algorithms that spin out eternal variations. Each of them "listens" to the settings of various knobs like dynamic (how loud to play), height (chose notes in either lower or higher register), length (play short or long notes) and activity (play less or more). Each part goes into an eight channel mixer with delay (with controllable delay time and feedback) and a controllable filter. I make some abstractions on time (this was where my segfault occurred), like: Time.wait(4); which means "wait for the next quarter-note" or if(Time.sub(8)%2 == 1) which means "if we're now on one of one-and, two-and etc. Basically the system works very well, but it takes practice. Not only can it be tricky to actually press the right button at the right moment, but it demands alot to be able to shape an eight minute piece from beginning to end with a satisfying structure and a natural climax not only so that the piece itself comes out right but also so that it fits within the entire set, which lasted about 50 minutes (next gig will have more new songs, so we're doing two sets of about 35-40 minutes). I hope this gives you an idea of what I do and why. Of course this explanation leaves out a lot of details, and the systems does a bit more here and there, but that's basically it... -- Atte http://atte.dk http://modlys.dk
Kassen wrote:
<snip> and your "live-thingy" seems to be over three times the size of mine, at least when we express size in lines of code (which is probably even a valid metric if we're talking ChucK issues).
Actually most of it is the songs, the system itself is only 3076 lines: atte@vestbjerg:~/music/chuck/modlys$ cat *.ck | wc -l 3076 -- Atte http://atte.dk http://modlys.dk
participants (4)
-
Atte André Jensen -
Kassen -
mike clemow -
Rogan Carr