Dear Dan,
WarpTable seems to have a issue where .lookup() doesn't behave like scanning
it with another UGen does for values slightly less than 1. I think the
scanning feature is wrong here, at least scanning doesn't behave according
to the docs.
Consider this example that uses WarpTable as a wave-shaper on a sine wave;
========================
SinOsc s => WarpTable wp => dac;
//some trickery to offset and scale the input
Step st => wp;
.50 => st.next;
//notice this line; .5 should be fine here yet isn't
//increasing this to .5 will cause artefacts
.4997 => s.gain;
//scale the range back and avoid DC offset
Step stInv => dac;
-.1 => stInv.next;
2 => wp.gain;
200 => s.freq;
//increase the second value for "drive"
//this is the bit that's actually useful and interesting here
//in this case we keep it linear to be able to hear the artefacts more
clearly.
wp.coefs([1., 1. ]);
minute => now;
=========================
Or; to demonstrate the exact same issue in it's most extreme case;
==============
Step s => WarpTable wp => dac;
//linear
wp.coefs( [1., 1. ] );
//UGen based index
1 => s.next;
//allow for the value to be updated
samp => now;
//both should be 1.000000
<<
BTW, Gen17 has the exact same issue and here the docs point out; // sounds better not going to extremes drive.gain( 0.99 ); Which makes me believe this was known, maybe even intentional, however no mention is made of the differing behaviour between the UGen based scanning and code-based indexing and I'm not sure I see the use. Here it gets a bit mysterious to me. Yours, Kas.
otay, will look through this when i have a chance, thanks again kas! dt On Mar 15, 2009, at 11:49 PM, Kassen wrote:
Dear Dan,
WarpTable seems to have a issue where .lookup() doesn't behave like scanning it with another UGen does for values slightly less than 1. I think the scanning feature is wrong here, at least scanning doesn't behave according to the docs.
Consider this example that uses WarpTable as a wave-shaper on a sine wave; ======================== SinOsc s => WarpTable wp => dac;
//some trickery to offset and scale the input Step st => wp; .50 => st.next;
//notice this line; .5 should be fine here yet isn't //increasing this to .5 will cause artefacts .4997 => s.gain;
//scale the range back and avoid DC offset Step stInv => dac; -.1 => stInv.next; 2 => wp.gain;
200 => s.freq;
//increase the second value for "drive" //this is the bit that's actually useful and interesting here //in this case we keep it linear to be able to hear the artefacts more clearly. wp.coefs([1., 1. ]);
minute => now; =========================
Or; to demonstrate the exact same issue in it's most extreme case; ============== Step s => WarpTable wp => dac; //linear wp.coefs( [1., 1. ] );
//UGen based index 1 => s.next; //allow for the value to be updated samp => now;
//both should be 1.000000 <<
>>; << >>; ===================== I believe this to be a error.
Additionally; the various Gen UGens would be a lot easier to use for wave shaping if they could have a mode where they would get indexed from -1 to 1 and output the same range; this would avoid the need for Step ugens and setting gains to compensate like in the top example above. Right now they can only be indexed usefully by things like Phasor and Envelope and chaining a few can yield interesting phase distortion effects using Gen10 but using them in the amplitude domain is quite inconvenient, even when they would make a lot of sense there. Maybe this would be worthy of consideration, especially as some of the pages referenced by the Gen docs do hint at this usage as well.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
participants (2)
-
Daniel Trueman
-
Kassen