[Clam-devel] Re: gsoc project - real time synthesizer for a woodwind instrument

[Pau Arumí Albó]

El dt 10 de 06 de 2008 a les 18:46 -0400, en/na Han, Yushen va escriure:
> Greg and Pau,

> (3) some other questions about the dependencies in CLAM:
> 
> I noticed Greg's plugin continuousExcitationSynthesizer
> included "LoopingSDIFFileReader.hxx" which was written by Greg as well.
> 
> But the LoopingSDIFFileReader.hxx is located in /usr/local/include/CLAM/
> (a system header file, not just a piece of the plugin).

It's a clam library (not plugin) header. The source actually sits at
CLAM/src/Processing/SDIFIO/

> I will modify this LoopingSDIFFileReader (and more files) for some
> error in array.
> "This may happen if you forgot to call SetSize(...) in your code.
> This is now needed. Just calling Resize() is not enough any more.
>  Unable to adquire symbols names for the backtrace"
> 
> Why do you make it a system file, Greg? Does some other stuff depend
> on it if I am going to change it?

I think the reason behind this is that this class might be reused by
other apps and processings/plugins.


> Also, why is some of the code in the folder "toreview"?
> Can I put everything under the same folder?

This is/was supposed to be a temporal directory where I put stuff to
revise in order to decide if remove or move to the upper directory. As
you see the task ended up unfinished. So we should look at it and
decide.

> (4) Now I fixed the loop point problem in my oboe samples and they did
> not sound bad (no click, noise etc. but still not good).

Well, I'd like to here how it sound. Please post the instructions and
database for others to reproduce. And let's move the discuss on code
patches as soon as possible.

Pau



> 
> I know both of you are occupied these days (for conference / finishing
> PhD separately).
> I don't expect quick reply but would like to document these known
> problems at clam-devel.
> 
> Best regards,
> Han, Yushen
> 
> On Tue, Jun 3, 2008 at 12:59 PM, Greg Kellum <greg.kellum at gmail.com> wrote:
> > Hi Yushen,
> >
> >> (1) The format of the score
> >>
> >> But anything I edited by hand results in segmentation fault
> >> because the program mistook multiple lines for one frame.
> >
> > I can vaguely remember having the same problem, and *** I think *** it
> > was because the parser was sensitive to whether the line ended with
> > carriage return line feeds or just line feeds.  (Don't blame me for
> > this;  I'm just using a standard C++ function for reading lines. ;-)
> > Try editing the score file with a text editor that lets you set what
> > is used for line breaks, and experiment to see what works...
> >
> >> (2) the synthesized frames
> >>
> >> Why is the even lines in the text score are skipped in the synthesis?
> >> The assumption for "one frame" in the score is SR = 44100Hz and HOPSIZE =
> >> 256 Samples.
> >> Is that correct?
> >>
> >
> > Wow, I had never noticed that before!  I have no idea why that is happening...
> >
> >> (3) ( to both Pau and Greg )
> >>
> >> Besides the problems above, the sound is not good
> >
> > Well, another reason it probably doesn't sound good is that I'm not
> > using the residual.  For what I was synthesizing -- ebow notes -- the
> > residual wasn't important, and it was taking a lot of processor power.
> >  So, I disabled it.  But for what you are synthesizing, the residual
> > is very important.
> >
> > If you look at the file ContinuousExcitationSynthesizer, you'll notice
> > that the function responsible for synthesizing the spectral frames is
> > using the class SinusoidalSynthesis.  You should be able to change
> > this to use SMSSynthesis instead pretty easily, and then, the residual
> > part will be synthesized as well.
> >
> > Best,
> > Greg
> >