Re: [music-dsp] Comb filter decay wrt. feedback
[Peter S] but when i consider that part of designing comb filters tuned to musical notes, i have to at least pause and wonder which interpolation would be better or sufficient for whatever application and that's why it didn't seem trivial to me. Linear interpolation is fast and dirty, and gives muffled notes with reduced high freqs. Allpass interpolation has flat passband, so the Schroeder RT60 formula works precisely. (It may mess up the phase and create some Nyquist ringing, so that might be an issue in some cases.) Thiran allpass interpolation works very well for tuning feedback-delay string models, at very low computational cost. Its nonlinear phase causes slight inharmonicity in the partial frequencies, an effect which is also found in nature. Manual adjustments may be necessary to bring especially higher pitches into musical tune. Cheers, Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Simulating Valve Amps
[Andrew Simper] On 18 June 2014 21:01, Tim Goetze t...@quitte.de wrote: I absolutely agree that this looks to be the most promising approach in terms of realism. However, the last time I looked into this, the computational cost seemed a good deal too high for a realtime implementation sharing a CPU with other tasks. But perhaps I'll need to evaluate it again? The computational costs of processing the filters isn't high at all, just like with DF1 you can compute some simplified coefficients and then call process using those. Since everything is linear you end up with a bunch of additions and multiplies just like you do in a DF1, but the energy in your capacitors is preserved when you change coefficients just like it is when you change the knobs on a circuit. Yeh's work on the Fender tonestack is just that: symbolic nodal analysis leading to an equivalent linear digital filter. I mistakenly thought you were proposing nodal analysis including also the nonlinear aspects of the circuit including valves and output transformer (which without being too familiar with the method I believe to lead to a system of equations that's a lot more complicated to solve). -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Simulating Valve Amps
[Sampo Syreeni] From what (very little!) I know of hardcore analog simulations, I'd say that is part of a more general and much nastier problem. That's the interaction one: whereas digital signal graphs have a definite direction of signal flow, there's no such thing on the analog side no matter what you do. Sure, you often try to go from low to high impendance and make use of tons of other tricks in order to make your circuit approach a directional signal flow, but lo and behold, most of the nicest sounding circuits actually measurably feed back all the way from the speaker-air-interface to the input jack, affecting anything and everything on the way. This, in my opinion, is possibly the most important difference between good warm analog and cold lifeless harsh sounding gear. I think that the interplay between virtually all components touched by the signal flow causes the timbre to constantly evolve, adding life. In fact, without such enhancements the sound of a solidbody electric guitar can appear rather plain, not to say dreadful. For computational efficiency it appears we're still stuck emulating amps and other gear with a succession of stages each lumping great parts of the circuitry together. But, imperfect though it may be, we can modify the parameters of one boxed stage in relation to measurements made anywhere else in the chain to create somewhat similar timbral evolution. (Such additions to the amp model have certainly helped me come a lot closer to my personal idea of the perfect guitar tone.) Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Simulating Valve Amps
[STEFFAN DIEDRICHSEN] Actually, it's not rocket science to model a baxandall or those Treble/Mid/bass networks. A straight forward approach is modified nodal analysis, which gives you a model, that preserves the passivity of the filter network. Perhaps I was being too vague; in any case, I wasn't talking about the tone controls but about the whole amp and cabinet business. Thanks to the work of Yeh, I personally consider the tonestack a solved problem, or at least one of least concern for the time being. Cheers, Tim On 18 Jun 2014, at 10:01, Tim Goetze t...@quitte.de wrote: [Sampo Syreeni] From what (very little!) I know of hardcore analog simulations, I'd say that is part of a more general and much nastier problem. That's the interaction one: whereas digital signal graphs have a definite direction of signal flow, there's no such thing on the analog side no matter what you do. Sure, you often try to go from low to high impendance and make use of tons of other tricks in order to make your circuit approach a directional signal flow, but lo and behold, most of the nicest sounding circuits actually measurably feed back all the way from the speaker-air-interface to the input jack, affecting anything and everything on the way. This, in my opinion, is possibly the most important difference between good warm analog and cold lifeless harsh sounding gear. I think that the interplay between virtually all components touched by the signal flow causes the timbre to constantly evolve, adding life. In fact, without such enhancements the sound of a solidbody electric guitar can appear rather plain, not to say dreadful. For computational efficiency it appears we're still stuck emulating amps and other gear with a succession of stages each lumping great parts of the circuitry together. But, imperfect though it may be, we can modify the parameters of one boxed stage in relation to measurements made anywhere else in the chain to create somewhat similar timbral evolution. (Such additions to the amp model have certainly helped me come a lot closer to my personal idea of the perfect guitar tone.) -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Oversampling and CPU + Bandlimited Distortion Effects?
[Thomas Strathmann] BTW, for those who can read some German, this book https://hps.hs-regensburg.de/~elektrogitarre/ might be a fascinating read. It's a scholarly treatise on the physics of e-guitars. Nice! There's a truly dire need for the scientific approach to the physics of the electric guitar. It has been the subject of far too much superstitious myth-spreading. Thanks a lot for the link, Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] need help with gnuplot and octave on my mac.
[robert bristow-johnson] Reason: Incompatible library version: libfontconfig.1.dylib requires version 13.0.0 or later, but libfreetype.6.dylib provides version 10.0.0 It appears the version of libfreetype installed on your system is too old. The required version number 13.0.0 is a bit peculiar, as the current freetype.org release is 2.4.11. Therefore I guess you need to get a newer libfreetype release from the same source that also provided your copies of gnuplot/X11 to keep in tune with the versioning scheme. Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
[robert bristow-johnson] On 3/9/13 1:31 PM, Wen Xue wrote: I think one can trust the compiler to handle a/3.14 as a multiplication. If it doesn't it'd probably be worse to write a*(1/3.14), for this would be a division AND a multiplication. there are some awful crappy compilers out there. even ones that start from gnu and somehow become a product sold for use with some DSP. Though recent gcc versions will replace the above a/3.14 with a multiplication, I remember a case where the denominator was constant as well but not quite as explicitly stated, where gcc 4.x produced a division instruction. (I think the denominator was a c++ template parameter subjected to a binary shift operator but my memory of the exact circumstances is hazy. I do remember it was easy to evaluate at compile time, and my surprise at the compiler not getting it.) Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Efficiency of clear/copy/offset buffers
[Tim Blechmann] Though recent gcc versions will replace the above a/3.14 with a multiplication, I remember a case where the denominator was constant as well but not quite as explicitly stated, where gcc 4.x produced a division instruction. not necessarily: in floating point math a/b and a * (1/b) do not yield the same result. therefore the compile should not optimize this, unless explicitly asked to do so (-freciprocal-math) I should have added, when employing the usual suspects, -ffast-math -O6 etc, as you usually would when compiling DSP code. Sorry! Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Noise gate for guitar amplifiers and hysteresis
[robert bristow-johnson] first, you need to decide of your level is to be measured as peak level or rms level or mean abs value or whatever. I'd like to throw in that I've gotten excellent results (for electric guitar) from a design that considers the instantaneous peak level for opening and RMS for closing the gate. (You might even get away without specialised hysteresis logic because the average-over-time property of RMS calculation works towards this effect already.) Another thing that I found very helpful for electric guitars: in the presence of computing equipment, especially the single-coil pickups you find on Stratocasters and similar designs tend to pick up a lot of mains hum. Branching the input signal and notch-filtering out at 50/60 Hz before computing the RMS level allows one to lower the closing threshold further without mains hum keeping the gate open unduly. Cheers, Tim -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
