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