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

Han, Yushen yushen.han at gmail.com
Tue Jun 10 15:46:01 PDT 2008


Greg and Pau,

(1) Thanks for your hint, Greg!
I tested the linebreak problem with text score files in Mac, Linux,
and DOS/Windows.
Greg's TestScore works well with the carriage (CR) in Mac and
DOS/Windows text files,
by
getline (myfile, line, '\r');
in
bool TestScore::LoadScore(std::string filename)

but did not work with Linefeed (LF) in Linux.

(DOS/Window text files use both Carriage (CR) and Linefeed (LF) as
line break so it could be detected anyway.)

Now this issue is resolved.

(2) I doubt if the counter in TestScore::NextFrameFromScore is mistaken.
Because the NextFrameFromScore skipped every other (frequency,
amplitude) pair and read empty lines as many as it skipped to the end
of the score.


bool TestScore::NextFrameFromScore(float& pitch, float& amplitude)
{
//	if ( (counter+1) > (2*numberOfEventsLoaded) )  // BEFORE
	if ( (counter) > (numberOfEventsLoaded) )  // AFTER
	{
		if ( !IsFeedForever() )
		{
			return false;
		}
		else
		{
			counter = 0;
			return NextFrameFromScore(pitch, amplitude);
		}
	}
	else
	{
		pitch = scoreVector[0][counter];
		amplitude = scoreVector[1][counter];
//		counter = counter + 2;  // BEFORE: why the counter jumps by 2 ?
		counter++;  // AFTER
		return true;
	}
}

My changes work in my computer.

(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).

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?

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

(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).

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
>




More information about the clam-devel mailing list