I ran into quite a few challenges starting out. waveguide1 with higher frequencies would quickly decay, far too fast. I experimented with different cutoff settings and, naturally, the feedback.
Reading about waveguides with junctions and two delay lines, I wonder: following the above paper, should I model one string with two waveguide1 opcodes partially feeding back into each other?
Or is there perhaps a newer or different approach to modelling a piano that is easier to implement in Csound?
I ran into quite a few challenges starting out. waveguide1 with higher
frequencies would quickly decay, far too fast. I experimented with different
cutoff settings and, naturally, the feedback.
The pitch versus decay issue is already handled in the first paper by
Karplus&Strong, as is tuning issues (for high pitches, semitones can
amount to delay differences of less than one sample). You might want to
look there.
Reading about waveguides with junctions and two delay lines, I wonder:
following the above paper, should I model one string with two waveguide1
opcodes partially feeding back into each other?
Or is there perhaps a newer or different approach to modelling a piano that
is easier to implement in Csound?
In theory this can be used with the Csound Faust opcodes, but unfortunately, although I have made many nice Csound instruments using Faust .dsp sources, this particular one does not work for me.
In theory you can get Faust to translate this to C++ code and make a plugin Csound opcode that way, but I haven’t (yet?) been able to get that to work.
Hi Partev, Michael and Peter,
many thanks for all your pointers and resources. I'm slowly making my way, hoping to gain something along the roa. It's definitely fun.
Okay, I got this to work. There is evidently a bug in the Faust faust2csound tool, which I figured out how to work around (it’s easy).
The Faust piano does not sound nearly as good as the Pianoteq physically modelled VST plugin, but still, this opens the way to creating many new plugin opcodes from Faust code.