On Wed, Aug 11, 2010 at 12:03 AM, Bill Good <[email protected]> wrote:
>
> On Tuesday 10 August 2010 23:18:02 Bill Good wrote:
>> Admittedly I haven't actually tried it yet. As long as it doesn't cause the
>> whole engine to hang (and xrun), I don't see that as really being an issue.
>> I suppose I'll find out soon enough, if it doesn't work (i.e. causes an
>> audio xrun), it's probably a bug.
>>
> I've got this all working, although there are some crummy glitches (not xruns
> though). Switching from linear -> soundtouch will produce a glitch pretty much
> 100% of the time, and the other direction probably about 60%. It sounds a lot
> like buffers in the scalars aren't being invalidated when the switch occurs
> (as
> they should be, to keep from playing old samples at the next
> enginebufferscale::scale call). Anyone have any ideas on this?
This is a potentially very complicated situation. Each
EngineBufferScale object has a pointer to the ReadAheadManager, which
helps pass it the next samples in the audio sequence. (Remember, if
there's loops involved, the next audio in the sequence might actually
involve a jump backwards to a different part of the song.) The
ReadAheadManager and the EngineBuffer have different notions of the
current playback position, because one is the "read ahead" position.
The tricky part is that SoundTouch requires way more read-ahead
samples than linear interpolation/VE does. That means the read ahead
position is going to be in the wrong spot if you change scalers on the
fly. (For example, if you change from EBST to EBSL, the
ReadAheadManager will have already given 1000 extra samples to EBST,
and those will never make it to EBSL so you'll end up with a
discontinuity in the audio, maybe even in the playback position.)
When you switch over, you're going to have to ensure that the
ReadAheadManager's playback position gets reset. I have a hack
somewhere in EngineBuffer that forces this behaviour when you switch
from going forwards to backwards, to prevent the read ahead position
from getting similarly messed up. (It's commented, search for XXX or
Albert in the comments of enginebuffer.cpp.)
So give something like what I've done there a try, and see if it makes
a difference...
Thanks,
Albert
> The code I'm
> using is as follows:
> void EngineBuffer::process(blah)
> {
> // comments
> CSAMPLE * pOutput = (CSAMPLE *)pOut;
> bool bCurBufferPaused = false;
> // FYI m_pKeylock is a ControlPushButton
> if (m_pKeylock->get() && m_pScale != m_pScaleST) {
> setPitchIndpTimeStretch(true);
> } else if (!m_pKeylock->get() && m_pScale == m_pScaleST) {
> setPitchIndpTimeStretch(false);
> }
> // and the rest of ::process
> // ...
> }
> I may also need to set enginebuffer::m_resetPITS (or whatever that variable's
> called) to false, so if the user un-clicks the key-lock button while
> scratching or whatever, it won't go back to PITS (stupid corner-case but might
> as well account for it).
>
> Other than that, it's actually surprisingly smooth for something I'm guessing
> hasn't really been tried in the past.
>
> I've made buttons but they're horrible. If anyone more familiar with
> outline/image editing in general than me wants to have a go at it, please do.
> I'm just making a regular size button, just above the volume faders, next to
> flanger and beneath PFL/headphones.
>
> Bill
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Mixxx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
