[Clam-devel] Re: Zero crossings and so ons...

[Han, Yushen]

Hi, Greg

"crossfading the spectral peaks rather than audio" is exactly what is
happening there.

We have a SpectralPeakArray class that offers access to each of those
SpectralPeaks.
We are actually crossfading two sets of SpectralPeaks.

It's strange to me that I did not hear any scramble-phase effect after
I change the SpectralPeaks
(e.g. I move the center of spectral peaks from one bin to another. It
sounded good in spite of the fact that I did NOT do any phase-vocoding
by myself. )

I need to know what happened to the residue too.

Interface Builder is good if you program in Cocoa (Objective C for Mac OS X).
Otherwise I am not sure it could be use for C++ in general, but you
could easily get a non-functional picture out of it.




On Thu, Jul 3, 2008 at 2:11 PM, Greg Kellum <greg.kellum at gmail.com> wrote:
> Hi Yushen and Xavier,
>
>
>> Hi, Greg
>>
>> 1. "Do you think you could identify zero crossings on the fly after
>> you've already resynthesized your two new frames?"
>> This is an interesting question and my answer is no. I can't do this
>> unless I have the access to the samples in a frame. So far all I did
>> is in the frame level. Is there anyway for me to operate on sample
>> level?
>
> I had actually forgotten how the looping was working.  I just went back and
> looked at it, and I was surprised that it was crossfading the spectral peaks
> rather than audio...  Hm...  Maybe, this is a good thing though...  For each
> spectral peak you also have a phase value.  I didn't do anything with these
> though.  I just matched up the frequency of the partials and crossfaded
> their magnitudes.  I would think though that if you took the phase values of
> all the partials of the end of the loop and assigned them to the partials at
> the beginning of the loop this would work just as well as matching up the
> zero crossings in the time domain, because then you are forcing the phase of
> the start of the loop to be continuous with the phase of the end of the
> loop...  But actually now that I think about it, the phase values are
> already being corrected anyway.  The SMS synthesis should be over writing
> the phases of each new frame so that it continues where the last frame
> ended.  So, actually, the phases of the partials of the overlapping frames
> should already be aligned.  I'm not sure what happens with the residual...
>
> Xavier Amatrian.  What do you have to say about this?  Is what I'm saying
> correct?
>
>> 4. For the "mock-up", do you mean something like a blue print of the
>> interface that is not really sfunctional?
>> If so, I can just use XCODE Interface Builder...
>>
>
> Yeap, I meant just a blue print of the interface that is not really
> functional.  Interface Builder...  I've never used it.  You recommend it?  I
> guess I should check it out...
>
> Best,
> Greg
>
>>
>> Best regards,
>> Han, Yushen
>>
>>
>>
>> On Thu, Jul 3, 2008 at 6:32 AM, Greg Kellum <greg.kellum at gmail.com> wrote:
>>>
>>> Hi Yushen,
>>>
>>> Here's a response to your earlier mail...
>>>
>>> I could imagine that it would be difficult to preserve the loop points
>>> you found after an analysis / resynthesis.  Do you think you could
>>> identify zero crossings on the fly after you've already resynthesized
>>> your two new frames?  When you wrap back around in a loop maybe you
>>> could just offset the start point of the loop by enough samples to
>>> make sure that the phases of the end and the start of the loop are
>>> aligned...
>>>
>>> You had also asked about the triangular envelope...  Well, a
>>> triangular envelope is already being using in SMS for overlapping
>>> frames.  This happens in the class OverlapAndAdd (I think).  And it
>>> doesn't introduce any artifacts...  Kontakt also uses triangular
>>> envelopes in looping...  Um...  Is there another alternative to using
>>> a triangular envelope?  Well, I suppose you could use no envelope at
>>> all as you mentioned...
>>>
>>> You also mentioned problems with jitter.  Is this the same question
>>> that you wrote about in your more recent email?  I wasn't sure that I
>>> understood the problem.  But I'm downloading your tar file, and
>>> hopefully, there are some sound files in there where I can hear the
>>> jitter...  Maybe that will help...
>>>
>>> With regards to the user interface, it would be cool if you had enough
>>> time to make a stand-alone application with its own GUI.  They're
>>> already using Qt for CLAM.  So, I suppose it would be best if you were
>>> to use Qt as well, and I think portmidi is already built into clam.
>>> So, I suppose you could use either that or OSC for input.  I suppose
>>> if you have some time to make some mock-ups of the user interface then
>>> we could make comments about them...  I'm working on OS-X as well, and
>>> I usually use OmniGraffle to make mock-ups and then save them as
>>> pdfs...
>>>
>>> Best wishes,
>>> Greg
>>>
>
>