[Clam-devel] Re: How to reproduce your synthesis

[Han, Yushen]

Hi,

An update that fixed the loop-switching problem that I mention in the
blog could be found at:

https://www.slashtmp.iu.edu/public/download.php?FILE=yushan/560t8bUcm

However, the output wave still sounds a bit repetitive with the score
file longNote.txt...

I managed to find loop points in time-domain but it seems to be
impossible to preserve these time points
after SMS - I need to apply cross-fading anyway when it goes from the
last frame in a loop back to the beginning frame.

Han, Yushen

On Tue, Jul 1, 2008 at 12:57 AM, Han, Yushen <yushen.han at gmail.com> wrote:
> Pau and Greg,
>
> I write to ask for your opinions to improve the quality of the sound.
> As a reference, attached is the synthesized sound using Greg's score
> of Violin Sonata.
>
> My first question is about the basic grain in CLAM is the sample
> As you know, I believe that one way to improve the sound is to use
> zero crossing loops instead of crossfading loops.
> But as I tried, the zero cross point  is very sensitive in the sample
> level without crossfading.
> It would sound like some samples are chopped off if we don't specify
> the right zero-cross point in a loop.
> But the problem is that the SDIF file is organized frame by frame.
> (Greg's XML file will take loop points in ms but not samples.)
> I am not sure how to give the zero crossing points without specifying
> on a sample level.
> If I could not do that, maybe I can hope to find loops that have
> samples as many as a frame...
>
> My 2nd question is about the crossfading window.
> Greg was applying a triangular-shaped crossfading to make the
> transition between loops smooth.
> I tried to skip the CrossfadeFactor and the sound had more periodical
> fluctuation, but did not make much difference.
> I don't know if this is the "standard" technique to use in realtime
> sound synthesis.
> If I should use crossfading, do you think the triangular envelope will
> introduce any artifact?
>
> My 3rd question is about the tolerance in the delay of sound and the
> physical correctness in the score.
> In my test, the jitter in the sound (as you can hear) is associated
> with the transition from one voice to another.
> In the initialization, the loop reader was already buffered up to the
> end of the first loop in its corresponding SDIF file.
> But in case of a sudden shift in frequency, I can still hear the jitter.
>
> One reason for the jitter is that there was no crossfading between
> voice in Greg's implementation
> and the index of the current loop was not reset ( a new voice will
> keep the current loop index from the previous voice ).
> (Please forgive me that my statement could be very wrong since I
> already modified Greg's code.)
>
> The other reason was that the frequency in the score could be
> arbitrary or beyond the physical capacity of an oboe.
> I made a test score with arbitrary shift in frequencies and it sounded
> very disconnected.
> So I was thinking if we would filter the score or alter the frequency,
> which requires us to delay to issue a new voice by a few frames.
> (I also need to know the physical property of the oboe.)
> Have you thought or known anything about this?
>
>
> I think I am still in the stage that the sound quality is the no.1 issue.
> But I want to know your expectation in other aspects: MIDI control,
> graphic interface ...
>
> Best regards,
> Han, Yushen
>
>
>
> On Mon, Jun 30, 2008 at 11:04 PM, Han, Yushen <yushen.han at gmail.com> wrote:
>> Hi, Pau
>>
>> I am able to update my blog.
>>
>> I put it here:
>> http://iua-share.upf.edu/wikis/clam/index.php/GSoC/Real-time_Synthesizer_Using_SMS_Models_for_a_Woodwind_Instrument
>>
>>> I think you mentioned you wanted to blog about the project.  In that
>>> case, just send me a feed url  (rss or atom) and head "hackergochi" so I
>>> can add it to the planet.
>> Thanks in advance.
>> How could I get the "feed url" out of it?
>>
>> Oh, I never got that error message.
>>
>> But the reason could be that you need to specify a score file, an
>> output wave file and the configuration xml  when you run it.
>> e.g.
>> ./SimpleOboeSynthesizer OboeSDIF/ testData/A440Short.txt
>> oboe440short.wav synthesis.xml
>>
>> Later I will send you an updated version of the synthesizer that fixed
>> a possible error in finding the loop points ( I blogged about that
>> )...
>>
>> Best regards,
>> Han, Yushen
>>
>> On Mon, Jun 30, 2008 at 2:02 PM, Pau Arumí Albó <parumi at iua.upf.edu> wrote:
>>>
>>> El dl 30 de 06 de 2008 a les 04:35 -0400, en/na Han, Yushen wrote:
>>>> But I have problem in logging my CLAM wiki page now.
>>>> So I attached my writing for your information.
>>>
>>> Does the problem you found with the wiki persists? If so, be specific
>>> and we'll try to help.
>>>
>>> I think you mentioned you wanted to blog about the project.  In that
>>> case, just send me a feed url  (rss or atom) and head "hackergochi" so I
>>> can add it to the planet.
>>>
>>> BTW, I've compiled your code (I'll give feedback on the code later)
>>> https://www.slashtmp.iu.edu/public/download.php?FILE=yushan/38176CYRpXb
>>> but find run-time problems:
>>>
>>> After compilation I do:
>>> simpleOboeSynthesizer$ ./SimpleOboeSynthesizer OboeSDIF/
>>>
>>> And an assertion fails "Starting an unconfigured processing"
>>> The problem seems being SimpleOboeSynthesizer unable to return true at
>>> ConcreteStart()
>>>
>>>  CLAM::SynthesizeToSpeakers (sdifDatabase=@0xbf7fd2c8,
>>> synthesis=@0xbf7fbc50, aControlScore=0x8115608,
>>>    audioWriter=0x0) at SimpleOboeSynthesizer.cxx:100
>>>
>>> Before diving into it, any idea of what is the problem?
>>>
>>> Pau
>>>
>>>
>>
>
> Hi,
>