On Thu, Feb 3, 2011 at 10:26 PM, Evan Laforge <qdun...@gmail.com> wrote:
> I should have mentioned Pianoteq back there as an exception to "no > interesting physical models since the '90s" thing. But it's pretty > specialized, and since it's proprietary who knows what they're doing > in there anyway. > I always assumed it was a very well-tuned waveguide model. But I haven't actually used it myself. > > > Waveguides are popular primarily because they're cheap to calculate. > Their > > fidelity is not great for certain classes of instruments though. > > > > My code is an implementation of a finite difference method, as described > in > > Stefan Bilbao's book "Numerical Sound Synthesis" (among other sources). > The > > finite difference method produces excellent results, but is extremely > > computation intensive. I've only recently managed to get to the point > where > > interesting models can run in real time. Currently I have models of > > striking bars and plates. Stefan's got some audio samples on his pages > > (along with some more interesting models, and some Matlab code too) so > you > > can check the quality yourself[0], but unfortunately I'm not able to > release > > my work at this time. > > Yes, I read his CMJ article with great interest, even though I don't > understand the math. In my case, a non-realtime model is not such a > problem because I already have to incrementally recompute a changed > score, so incrementally recomputing the sound would just be one more > step in that direction. Though I suppose this could still get > annoying if the computation time to real time ratio is too high. In > that case (say a minute to render a second) then perhaps the technique > lends itself to a cheaper approximation? Even if not, it's always > possible to automatically generate a sample set and use that as the > mockup. > My results are better than that. The most complex systems I've run so far are about 3:1 with my code, although Matlab is slower than that by orders of magnitude. Simpler stuff is generally closer to 1:2. > > It seems like it should be possible to get speedups with parallelism as > well. > Not as easily as you might expect, unfortunately. More precisely, the most interesting systems are those in which options for parallelism are most limited due to non-linear effects. > > I've seen lots of percussion and woodwind models, but bowed strings > are conspicuously absent. Is there something particularly hard about > it? > Yes and no. Bowed strings are easily modeled with waveguides driven by sawtooth waves. In fact, many plucked string models will work pretty well if you just change the driver from an impulse to a sawtooth. I think that's why bowed strings are mostly absent, intellectually they aren't as interesting as other problems. Of course generating a true-to-life sound requires a significant investment of time tweaking your model (and driving signal) precisely. > > > Sorry if I gave the wrong impression, but my EDSL and my physical > modeling > > work are entirely separate at this time. I do have both text-based and > > programmatic interfaces to the phys. modeling stuff though, so it is be > > possible to generate systems and scores. I guess the text interface > could > > be considered a DSL. > > It seems to me that an input of a set of signals for parameters like > resonator length, mallet impulse, breath pressure, whatever, and a > signal for output is already a sufficient interface. I suppose if you > want to go lower level and hook the output of one model to the input > of another then you get into DSL territory. I guess these audio DSLs > all tend to boil down to piping sample streams around anyway---the > main difference is the set of included primitives. > > Anyway, if you ever are able to release your work, then I'd be very > interested in giving it a try. I noticed that most audio examples > don't actually hook them up to a real score so you can hear a musical > usage rather than a demonstration, but this is something I'll > (eventually) be in a pretty good position to do. > I have some hope that I'll be able to release it relatively soon. John
_______________________________________________ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
