Taybin Rutkin wrote: glad you like it. i'll probably tar them all together when the set is complete and the individual units are 'final'. can't tell right now how long this is going to take. tim

Taybin Rutkin wrote: i'll continue work on this branch until the guitar sounds just right. the more i work on it, the more i learn about it -- sorry, any estimation i could make on how many units and how long this is going to take will be proven wrong too soon. tim

Steve Harris wrote: cheers, i do like the sound too. take a look at the 1st derivative of the curve; it's not so easy to emulate this with one polynomial. the spice implementation of the valve itself uses pow (x, 1.5) and branching a few times ... i'm working on a different implementation that decomposes the response into n segments, each evaluated as a 4th order poly. there's a table storing only the poly coefficients for each segment. i think it will come much closer than a 5th or 6th order over the whole curve, let alone the current implementation. and (tests done) it does execute a tad quicker than lerping over 1996 samples. it's fairly linear over this range (the plot is from a [-5, +5] V ramp). more interesting is that if you feed it a sine wave, the circuit *never* clips the lower lobe, it rather seems to compress so the lower lobe never hits the end of the curve. it does clip the lower lobe of a triangle however. <diy tips for spice> if you'd like to run spice yourself, it's fairly easy: fetch spice3f5sfix.tar.gz (google for it, i think it's on sunsite) and run the spice binary on the netlist linked from the preamp page. then tell the spice prompt 'run; setplot tran; plot V(4)' to see what the output looks like. 'plot V(1)' will show the input signal. 'write V(4)' will write the output to a mixed ascii/binary format that is fairly easy to decode with a little {python|perl}. i keep a .py around you can have. the spice netlist language is a little crude yet sometimes elegant, and the binary and build process feel like those days when you had to lease cpu time at the local computing centre. </diy> tim

Lamar Owen wrote: i'd like to understand why, but in the meantime implementing similar behaviour is not that hard. :) yep, it's a great program, and in true grand old unix spirit, it hides behind an unfriendly and fiendish interface. ;) judging from execution times on this box, you'd probably need something like a recent 32-way cluster to run a whole amp sim in realtime. tim