On Fri, Feb 4, 2011 at 2:14 AM, Evan Laforge <[email protected]> wrote:
> On Thu, Feb 3, 2011 at 5:27 PM, John Lato <[email protected]> wrote: > > On Thu, Feb 3, 2011 at 10:26 PM, Evan Laforge <[email protected]> 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. > > Yeah, they have some other stuff going on too, with sympathetic > resonance. It might be a separate technique because when they changed > algorithms, pitch bend affects the string but not the resonance, which > sounds quite strange. I believe they have mentioned that they have > more accurate models but don't use them for fear of no longer being > realtime. > That's pretty funny; I should check it out. >> 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. > > Well, how about multiple strings, coupled through a soundpost and the > air? Would it be naive to run each string on its own processor? I > suppose if it gets the sympathy through a sample stream then you've > got at least a one sample delay which might be enough to mess things > up... With FD methods, couplings are at present the primary parallelization difficulty. It's easy to run each string on its own processor if there are no couplings between them. If there are couplings, that serves as a synchronization point within the computation at each sample, and at present there's too much communication to make it worthwhile. What's worse is that the coupling calculations need to be very precise or the whole model will almost certainly degenerate. John
_______________________________________________ haskell-art mailing list [email protected] http://lists.lurk.org/mailman/listinfo/haskell-art
