Hi all, here's a little New Year's gift. After reading a posting by an STK user to the stk list about reading Andy Moorer's account of how he created the THX sound, I decided to whip one up in ChucK. As easy as one might expect. Enjoy!! PRC http://musicthing.blogspot.com/2005/05/tiny-music-makers-pt-3-thx-sound.html // THX emulator, Perry R. Cook, Jan. 8, 2007 // // F-1, B1b, F1, B2b, F2, B3b, F3, A5, F4, A6 [ 29.0, 87.5,116.0,175.0,233.0,350.0,524.0,880.0,1048,1760, 29.0, 87.5,116.0,175.0,233.0,350.0,524.0,880.0,1048,1760, 29.0, 87.5,116.0,175.0,233.0,350.0,524.0,880.0,1048,1760 ] @=> float targets[]; float initials[30]; float deltas[30]; sawosc s[30]; gain gl[30]; gain gr[30]; JCRev rl => dac.left; JCRev rr => dac.right; 0 => int i => int j; for (0 => i; i<30; i+1 => i) { std.rand2f(200.0,800.0) => initials[i] => s[i].freq; // random freqs. (targets[i] - initials[i]) / 10000.0 => deltas[i]; // 10 sample updates 0.1 => s[i].gain; std.rand2f(0.0,1.0) => gl[i].gain; // random 1.0 - gl[i].gain() => gr[i].gain; // panning s[i] => gl[i] => rl; // hook up s[i] => gr[i] => rr; // all the oscs } 10000 :: samp => now; // steady cluster while(j < 10000) { for (0 => i; i<30; i+1 => i) { initials[i] + (deltas[i]*j) => s[i].freq; // sweep freqs. } j + 1 => j; 10 :: samp => now;} while (j < 30000) { // hold chord 10 :: samp => now; j + 1 => j; } while (j < 35000) { for (0 => i; i<30; i+1 => i) { 0.1 * (35000 - j) / 10000.0 => s[i].gain; // decay gains } 10 :: samp => now; j + 1 => j; } 60000 :: samp => now; // reverb tail
Awesome!! I've added this as an example to be included in the next release, all- too-fittingly in the 'deep' directory. Already in CVS. I hope we don't get sued. Best, Ge! On Jan 8, 2007, at 3:56 PM, Perry R Cook wrote:
Hi all, here's a little New Year's gift. After reading a posting by an STK user to the stk list about reading Andy Moorer's account of how he created the THX sound, I decided to whip one up in ChucK. As easy as one might expect. Enjoy!!
PRC
http://musicthing.blogspot.com/2005/05/tiny-music-makers-pt-3-thx- sound.html
// THX emulator, Perry R. Cook, Jan. 8, 2007 // // F-1, B1b, F1, B2b, F2, B3b, F3, A5, F4, A6 [ 29.0, 87.5,116.0,175.0,233.0,350.0,524.0,880.0,1048,1760, 29.0, 87.5,116.0,175.0,233.0,350.0,524.0,880.0,1048,1760, 29.0, 87.5,116.0,175.0,233.0,350.0,524.0,880.0,1048,1760 ] @=> float targets[]; float initials[30]; float deltas[30]; sawosc s[30]; gain gl[30]; gain gr[30]; JCRev rl => dac.left; JCRev rr => dac.right;
0 => int i => int j;
for (0 => i; i<30; i+1 => i) { std.rand2f(200.0,800.0) => initials[i] => s[i].freq; // random freqs. (targets[i] - initials[i]) / 10000.0 => deltas[i]; // 10 sample updates 0.1 => s[i].gain; std.rand2f(0.0,1.0) => gl[i].gain; // random 1.0 - gl[i].gain() => gr[i].gain; // panning s[i] => gl[i] => rl; // hook up s[i] => gr[i] => rr; // all the oscs }
10000 :: samp => now; // steady cluster
while(j < 10000) { for (0 => i; i<30; i+1 => i) { initials[i] + (deltas[i]*j) => s[i].freq; // sweep freqs. } j + 1 => j; 10 :: samp => now;} while (j < 30000) { // hold chord 10 :: samp => now; j + 1 => j; } while (j < 35000) { for (0 => i; i<30; i+1 => i) { 0.1 * (35000 - j) / 10000.0 => s[i].gain; // decay gains } 10 :: samp => now; j + 1 => j; } 60000 :: samp => now; // reverb tail
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
can Envelope work like SinOsc to control ugen parameters? meaning, something like this, hacked from the lovely ChucK manual blackhole example: SinOsc s => dac; Envelope e => blackhole; 10. => lfo.time; s.freq = 220.; e.target(440.); while (20::ms => now){ e.last() => s.freq; } ? it doesn't work, and it seems that e.last() doesn't actually give you anything. obviously there are other ways to do this, but i'm trying to *learn* here! takk, dan
whoops, i meant 10. => e.time; for line 3. dt On Jan 13, 2007, at 12:27 AM, dan trueman wrote:
can Envelope work like SinOsc to control ugen parameters? meaning, something like this, hacked from the lovely ChucK manual blackhole example:
SinOsc s => dac; Envelope e => blackhole; 10. => lfo.time; s.freq = 220.; e.target(440.);
while (20::ms => now){ e.last() => s.freq; }
?
it doesn't work, and it seems that e.last() doesn't actually give you anything. obviously there are other ways to do this, but i'm trying to *learn* here!
takk, dan _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hey Dan, You're on the right track with that code. Envelope needs a source to work on, though--if there isn't a ugen inputting samples to it, it just envelopes a zero signal. The Step ugen works nicely for this, as you can feed it an arbitrary sample value, and it will continuously feed this value through a patch. SinOsc s => dac; 220 => s.freq; Step stp => Envelope e => blackhole; // set step value s.freq() => stp.next; // set the current value of the envelope 1 => e.value; // set the target value of envelope 2 => e.target; // set time to reach target 10 => e.time; // activate e.keyOn(); while (20::ms => now){ e.last() => s.freq; } A functionally equivalent but potentially clearer way of writing this would be: SinOsc s => dac; 220 => s.freq; Step stp => Envelope e => blackhole; // set step value 1 => stp.next; // set the current value of the envelope s.freq() => e.value; // set the target value of envelope s.freq() * 2 => e.target; // set time to reach target 10 => e.time; // activate e.keyOn(); while (20::ms => now){ e.last() => s.freq; } spencer On Jan 13, 2007, at 12:27 AM, dan trueman wrote:
can Envelope work like SinOsc to control ugen parameters? meaning, something like this, hacked from the lovely ChucK manual blackhole example:
SinOsc s => dac; Envelope e => blackhole; 10. => lfo.time; s.freq = 220.; e.target(440.);
while (20::ms => now){ e.last() => s.freq; }
?
it doesn't work, and it seems that e.last() doesn't actually give you anything. obviously there are other ways to do this, but i'm trying to *learn* here!
takk, dan _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
thanks spencer. which of course leads to more questions... by accident, i did this:
>>>>> Step stp => Envelope e => SinOsc s => dac; 220 => s.freq;
// set step value 1 => stp.next; // set the current value of the envelope s.freq() => e.value; // set the target value of envelope s.freq() * 2 => e.target; // set time to reach target 10 => e.time; while (20::ms => now){ //nothing needed to do.... }
>>>>>
and it works! so i gather there is some default parameter that gets set in a ugen when you chuck to it? i'm curious in part because i'd like to write classes which can do this, for example: someRandomControlSignal => MySillyControlFilter_class mscfc => Envelope e => SinOsc s => dac; etc.... is there a way to write classes which can be chucked to in this way? again, this can obviously be done other ways, but grasshopper is attempting to learn. sorry if this is documented somewhere already! dan On Jan 13, 2007, at 11:19 AM, Spencer Salazar wrote:
Hey Dan, You're on the right track with that code. Envelope needs a source to work on, though--if there isn't a ugen inputting samples to it, it just envelopes a zero signal. The Step ugen works nicely for this, as you can feed it an arbitrary sample value, and it will continuously feed this value through a patch.
SinOsc s => dac; 220 => s.freq;
Step stp => Envelope e => blackhole; // set step value s.freq() => stp.next; // set the current value of the envelope 1 => e.value; // set the target value of envelope 2 => e.target; // set time to reach target 10 => e.time;
// activate e.keyOn();
while (20::ms => now){ e.last() => s.freq; }
A functionally equivalent but potentially clearer way of writing this would be:
SinOsc s => dac; 220 => s.freq;
Step stp => Envelope e => blackhole; // set step value 1 => stp.next; // set the current value of the envelope s.freq() => e.value; // set the target value of envelope s.freq() * 2 => e.target; // set time to reach target 10 => e.time;
// activate e.keyOn();
while (20::ms => now){ e.last() => s.freq; }
spencer
On Jan 13, 2007, at 12:27 AM, dan trueman wrote:
can Envelope work like SinOsc to control ugen parameters? meaning, something like this, hacked from the lovely ChucK manual blackhole example:
SinOsc s => dac; Envelope e => blackhole; 10. => lfo.time; s.freq = 220.; e.target(440.);
while (20::ms => now){ e.last() => s.freq; }
?
it doesn't work, and it seems that e.last() doesn't actually give you anything. obviously there are other ways to do this, but i'm trying to *learn* here!
takk, dan _______________________________________________ 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
On Jan 13, 2007, at 1:22 PM, Daniel Trueman wrote:
thanks spencer. which of course leads to more questions...
by accident, i did this:
>>>>>> Step stp => Envelope e => SinOsc s => dac; 220 => s.freq;
// set step value 1 => stp.next; // set the current value of the envelope s.freq() => e.value; // set the target value of envelope s.freq() * 2 => e.target; // set time to reach target 10 => e.time;
while (20::ms => now){ //nothing needed to do.... }
>>>>>>
and it works! so i gather there is some default parameter that gets set in a ugen when you chuck to it?
Ah yes. Thats actually a much more efficient method than the one I wrote, as the ChucK audio subsystem is applying the envelope for you. Oscillator ugens have a parameter .sync, which states how a given oscillator is affected by its input. The online documentation and ChucK manual are a bit out of date as to what values .sync accepts and what those values do, as they have changed recently. So here they are: 0 => osc.sync (the default) causes the frequency of the oscillator to be whatever its input is; 1 => osc.sync causes the phase of the oscillator to be whatever its input is; 2 => osc.sync adds the oscillator's input to its current frequency, i.e. frequency modulation Notably, this only works with the basic oscillator ugens, so the other less efficient enveloping method would be needed for other ugens like filters or STK instruments.
i'm curious in part because i'd like to write classes which can do this, for example:
someRandomControlSignal => MySillyControlFilter_class mscfc => Envelope e => SinOsc s => dac;
etc....
is there a way to write classes which can be chucked to in this way?
That sort of thing is possible, but currently it is not possible to write chuckable ugens in ChucK code--that has to be done on the C++ side, and invariably involves compiling a custom chuck binary. Solutions to both of those problems are high on the to-do list (first- class UGens in ChucK code, dynamic UGen plugins). There are a few non-ideal workarounds at the moment, mostly involving writing functions to act as the chuck and unchuck operators. You could also probably implement MySillyControlFilter_class in ChucK using some combination of built-in ugens, but packaging it into a single chuckable ugen would not be possible without delving into the chuck source. spencer
again, this can obviously be done other ways, but grasshopper is attempting to learn.
sorry if this is documented somewhere already!
dan
On Jan 13, 2007, at 11:19 AM, Spencer Salazar wrote:
Hey Dan, You're on the right track with that code. Envelope needs a source to work on, though--if there isn't a ugen inputting samples to it, it just envelopes a zero signal. The Step ugen works nicely for this, as you can feed it an arbitrary sample value, and it will continuously feed this value through a patch.
SinOsc s => dac; 220 => s.freq;
Step stp => Envelope e => blackhole; // set step value s.freq() => stp.next; // set the current value of the envelope 1 => e.value; // set the target value of envelope 2 => e.target; // set time to reach target 10 => e.time;
// activate e.keyOn();
while (20::ms => now){ e.last() => s.freq; }
A functionally equivalent but potentially clearer way of writing this would be:
SinOsc s => dac; 220 => s.freq;
Step stp => Envelope e => blackhole; // set step value 1 => stp.next; // set the current value of the envelope s.freq() => e.value; // set the target value of envelope s.freq() * 2 => e.target; // set time to reach target 10 => e.time;
// activate e.keyOn();
while (20::ms => now){ e.last() => s.freq; }
spencer
On Jan 13, 2007, at 12:27 AM, dan trueman wrote:
can Envelope work like SinOsc to control ugen parameters? meaning, something like this, hacked from the lovely ChucK manual blackhole example:
SinOsc s => dac; Envelope e => blackhole; 10. => lfo.time; s.freq = 220.; e.target(440.);
while (20::ms => now){ e.last() => s.freq; }
?
it doesn't work, and it seems that e.last() doesn't actually give you anything. obviously there are other ways to do this, but i'm trying to *learn* here!
takk, dan _______________________________________________ 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,
another way is to use the function Envelope.value() where you can not only
set but also get
the actual envelope value... (the value of the envelope itself and not of
the enveloped signal)
SinOsc s => dac;
Envelope e => blackhole;
10. => e.time;
s.freq = 220.;
e.target(440.);
while (20::ms => now){
e.value() => s.freq;
}
so you do not need another ugen as a source..
2007/1/13, dan trueman
can Envelope work like SinOsc to control ugen parameters? meaning, something like this, hacked from the lovely ChucK manual blackhole example:
SinOsc s => dac; Envelope e => blackhole; 10. => lfo.time; s.freq = 220.; e.target(440.);
while (20::ms => now){ e.last() => s.freq; }
?
it doesn't work, and it seems that e.last() doesn't actually give you anything. obviously there are other ways to do this, but i'm trying to *learn* here!
takk, dan
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
-- tazumi
Hi all, For a while I''ve been thinking about writing a shell script or small c++ program in order to change all my old Chuck patches (using old version names i.e. sinosc, std, etc.) to the new version names (i.e. SinOsc, Std, etc.). I see that even Perry is stuck to the old 'style'.. I still am also... I'm a bit lazy these days, so my question is... has anyone written a script to do such thing? If so.. I will update the ck.vim soon.. million thanks, eduard On 8 Jan 2007, at 21:56, Perry R Cook wrote:
Hi all, here's a little New Year's gift. After reading a posting by an STK user to the stk list about reading Andy Moorer's account of how he created the THX sound, I decided to whip one up in ChucK. As easy as one might expect. Enjoy!!
PRC
http://musicthing.blogspot.com/2005/05/tiny-music-makers-pt-3-thx- sound.html
// THX emulator, Perry R. Cook, Jan. 8, 2007 // // F-1, B1b, F1, B2b, F2, B3b, F3, A5, F4, A6 [ 29.0, 87.5,116.0,175.0,233.0,350.0,524.0,880.0,1048,1760, 29.0, 87.5,116.0,175.0,233.0,350.0,524.0,880.0,1048,1760, 29.0, 87.5,116.0,175.0,233.0,350.0,524.0,880.0,1048,1760 ] @=> float targets[]; float initials[30]; float deltas[30]; sawosc s[30]; gain gl[30]; gain gr[30]; JCRev rl => dac.left; JCRev rr => dac.right;
0 => int i => int j;
for (0 => i; i<30; i+1 => i) { std.rand2f(200.0,800.0) => initials[i] => s[i].freq; // random freqs. (targets[i] - initials[i]) / 10000.0 => deltas[i]; // 10 sample updates 0.1 => s[i].gain; std.rand2f(0.0,1.0) => gl[i].gain; // random 1.0 - gl[i].gain() => gr[i].gain; // panning s[i] => gl[i] => rl; // hook up s[i] => gr[i] => rr; // all the oscs }
10000 :: samp => now; // steady cluster
while(j < 10000) { for (0 => i; i<30; i+1 => i) { initials[i] + (deltas[i]*j) => s[i].freq; // sweep freqs. } j + 1 => j; 10 :: samp => now;} while (j < 30000) { // hold chord 10 :: samp => now; j + 1 => j; } while (j < 35000) { for (0 => i; i<30; i+1 => i) { 0.1 * (35000 - j) / 10000.0 => s[i].gain; // decay gains } 10 :: samp => now; j + 1 => j; } 60000 :: samp => now; // reverb tail
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hi all, I'm a new Chuck user and I'm trying to create a simple midi router. I tried a very simple Chuck program to test the midi functionnality of Chuck : I created a Midin and a Midiout, opened them without problems. MidiIn min; MidiOut mout; MidiMsg msgin; MidiMsg msgout; then I just wanted to copy the MidiIn data to the MidiOut data... msgin.data1 => msgout.data1; msgin.data2 => msgout.data2; msgin.data3 => msgout.data3; mout.send(msgout); It works perfectly for noton and noteoff events but when I send A program Change, an error occurs : [chuck](via RtMidi): RtMidiOut::sendMessage: event parsing error! After some tests, it appears that this error occurs when I set the msgout.data1 to values greater than 191 (it works for 191 and bugs for 192). (I'm running under Linux Ubuntu & Jack.) Is this error normal ? Thanks a lot. Terence
\Piccolos wrote:
Hi all,
Hi there! I'm a new Chuck user Welcome!
It works perfectly for noton and noteoff events but when I send A program Change, an error occurs : [chuck](via RtMidi): RtMidiOut::sendMessage: event parsing error!
Yeah, it should work for CC changes as well. The issue relates to Program Change messages being two bytes while note and cc messages (the ones which ChucK anticipates) are three bytes. The good news is that it *can* work right now. Anyway; if the first byte (.data1) is 192 the MIDI message will be a program change and the receiving end (your synth and apparently rtmidiout) will anticipate one data byte (holding the program number) after this. Sending a second data byte (.data3) is bad midi syntax and this is probably what RtMidiOut is complaining about. In the case of your code the second data byte is probably the .data3 of the last three-byte message you got as your input but I'm a little unsure there because to me it seemed that ChucK's MIDI in doesn't realy like two byte input messages either (and I think it ignores single byte clock messages). To get back to your problem; I got the output of Program Change messages to work fine with the .data3 set to "0" so I think this should work; --------------- msgin.data1 => msgout.data1; msgin.data2 => msgout.data2; //this range just covers program change messages if ( (msgin.data3 > 191 ) && (msgin.data3 < 208) ) 0 => msgout.data3; else msgin.data3 => msgout.data3; mout.send(msgout); --------------- ...but right now stuff isn't pluged in here so I can't test meaning no refunds or waranty in case of fire, crashes or both. I got it to work with .data3 zero-ed out on Windows at least. Hope that helps, Kas.
Hi, Thanks a lot for the answer. I've just tried put the data3 to 0 and it still crash. In fact, this error occurs also for values of data1 >= 192 (I tried 193, 194, etc.) It's not only strange, but also a bit annoying for my purpose ... ;-) Seems to be linked to linux version ? Piccolos
Thanks a lot for the answer. I've just tried put the data3 to 0 and it still crash. In fact, this error occurs also for values of data1 >= 192 (I tried 193, 194, etc.)
Yeah, but that's logical. "192" means "now I'm going to send a program change which refers to the first MIDI channel", 193 means the same for the second channel and so on up to 207. It's not only strange, but also a bit annoying for my purpose ... ;-) Yes, quite so. It should be less strange and less annoying :-). Seems to be linked to linux version ? Confirmed. The code below is what I posted to the list to demonstrate program change. This works on my Win laptop and on this machine (Demudi, stable) I get the same error that you did. (you can also insert "0 => msg.data3;" for the same results) ----------------- MidiOut mout; MidiMsg msg; mout.open(0); //refers to a program change on the first channel //add to it for following channels 192 => msg.data1; //refers to the program to be loaded 4 => msg.data2; mout.send(msg); --------------- So, erm, the Linux version lacks the undocumented feature that the Windows version has. :-) Sorry, Kas.
Yeah, but that's logical. "192" means "now I'm going to send a program change which refers to the first MIDI channel", 193 means the same for the second channel and so on up to 207.
Indeed ! I didn't know this at all. Aware of this I've just tested with greater values. The problem disapears with value 224 (and is still there for 223, 222, etc.). (And I don't know what a value of data1=223 means...) Piccolos
Indeed ! I didn't know this at all.
Aware of this I've just tested with greater values. The problem disapears with value 224 (and is still there for 223, 222, etc.).
(And I don't know what a value of data1=223 means...)
http://www.gweep.net/~prefect/eng/reference/protocol/midispec.html There you go. That should help. Before you spend as much time jugeling HEX and "normal" decimal values as I did; it turns out ChucK can deal with HEX numbers too. Oh, and maybe this would also be interesting; http://www.rattus.net/~packrat/audio/ChucK/ ...but I still think this Win-Linux difference has you stuck at the moment. Kas.
On Sun, Jan 14, 2007 at 05:53:18PM +0100, Piccolos wrote:
Yeah, but that's logical. "192" means "now I'm going to send a program change which refers to the first MIDI channel", 193 means the same for the second channel and so on up to 207.
Indeed ! I didn't know this at all.
Aware of this I've just tested with greater values. The problem disapears with value 224 (and is still there for 223, 222, etc.).
(And I don't know what a value of data1=223 means...)
Just for the record, just never ever deal with midi data in decimal. It will just confused you. If you use hex, everything will be simple and obvious because the commands are broken across the nybbles. And yes, you might want to look at my MIDI sending API at http://www.rattus.net/~packrat/audio/ChucK/ That will give you a better idea of whether the crash is due to bad data values. I can only assume that the midi interface library under linux is partially interpreting your data values and complaining about invalid ones. I'm afraid I only use a mac for ChucK these days. B> -- Packrat (Wombat Implementor;COSO;Badgerphonic;Biokino Artist) Nihil illegitemi carbovndvm
Hi all,
For a while I''ve been thinking about writing a shell script or small c++ program in order to change all my old Chuck patches (using old version names i.e. sinosc, std, etc.) to the new version names (i.e. SinOsc, Std, etc.). I see that even Perry is stuck to the old 'style'.. I still am also... I'm a bit lazy these days, so my question is... has anyone written a script to do such thing?
This is an interesting and cool idea. Has anyone made such a thing? Incidentally, how many people are still sticking to the old naming convention? Best, Ge!
On 21/02/2007, at 6.35, Ge Wang wrote:
Hi all,
For a while I''ve been thinking about writing a shell script or small c++ program in order to change all my old Chuck patches (using old version names i.e. sinosc, std, etc.) to the new version names (i.e. SinOsc, Std, etc.). I see that even Perry is stuck to the old 'style'.. I still am also... I'm a bit lazy these days, so my question is... has anyone written a script to do such thing?
This is an interesting and cool idea. Has anyone made such a thing?
Will sed and bash do? Then here is a quick one, attached. The list need to be completed. It fills /tmp/ and doesn't clean up, such that incase of trouble the org. file is there. Best, Steffen
It just occured to me that theoretically a automated system to update code to the new syntax could break stuff. I think this; sinosc SinOsc => dac; would (theoretically) be valid in the old system while bluntly converting this to; SinOsc Sinosc => dac; would result in problems. I hope nobody used that as a convention. I could imagine people being inspirered by examples that use uppercase for classes and lowercase for instances and start using the following in new-style files; SndBuf sndbuf => dac; I think I myself did that in a few cases; a script would break that. This means it's probaly advisable to keep a manual eye (erm....) on exactly what's being converted into what and not to blutly convert everything -including new-style files- system-wide, then have more problems then you had to begin with. To be clear; I don't mean to say it's not a good idea to use batch-conversion or that it wasn't very nice of Stephen to make us a script :-). It'd be sad to have to say "I thought of that" after somebody accidentally converted a few hundred unsorted files.... Kas.
Good point--in a similar vein, another issue with a linear string find +replace would be the ambiguity between the gain ugen and the .gain parameter every ugen has--youd want gain to be converted to Gain, but 1 => mySine.gain; should stay the way it is. So maybe an extra rule in the conversion script to ignore the next word after a dot (with whitespace potentially separating them) would get around that problem. Surprisingly enough, SinOsc SinOsc => dac; is actually valid ChucK in its present incarnation--the compiler allows variables that have the same name as types. So in that particular instance you would be okay. spencer On Feb 22, 2007, at 2:57 AM, Kassen wrote:
It just occured to me that theoretically a automated system to update code to the new syntax could break stuff. I think this;
sinosc SinOsc => dac;
would (theoretically) be valid in the old system while bluntly converting this to;
SinOsc Sinosc => dac;
would result in problems.
I hope nobody used that as a convention. I could imagine people being inspirered by examples that use uppercase for classes and lowercase for instances and start using the following in new-style files;
SndBuf sndbuf => dac;
I think I myself did that in a few cases; a script would break that.
This means it's probaly advisable to keep a manual eye (erm....) on exactly what's being converted into what and not to blutly convert everything -including new-style files- system-wide, then have more problems then you had to begin with.
To be clear; I don't mean to say it's not a good idea to use batch- conversion or that it wasn't very nice of Stephen to make us a script :-).
It'd be sad to have to say "I thought of that" after somebody accidentally converted a few hundred unsorted files....
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (11)
-
Bruce Murphy -
dan trueman -
Daniel Trueman
-
eduard -
Ge Wang -
Kassen -
Perry R Cook -
Piccolos -
Spencer Salazar -
Steffen -
tazumi