Hi guys,
----- Original Message -----
From: Garth Dahlstrom <[EMAIL PROTECTED]>
Date: Monday, May 12, 2008 11:53 am
Subject: Re: [Mixxx-devel] loop tool
To: Nick Guenther <[EMAIL PROTECTED]>
Cc: mixxx-devel <[email protected]>, Felipe Machado <[EMAIL
PROTECTED]>
> Hi Nick,
>
> I've seen it implemented a couple of ways:
> 1) Having loop in and loop out buttons (where the music between
> when you hit in and out is looped)
> 2) Having beat length select and a loop button
>
>
> Some of these use bpm detection to do it nicely (if your timing
> is a little off with the buttons).... I don't
> think our BPM detection is that granular though...
> so likely we'd have to go with 1 without the auto bpm
> alignment...
This seems reasonable to me. I'd also be up for doing some brainstorming for
some unique way of implementing looping. I think simple loop-in and loop-out is
something we should start writing a spec for, and we can call it "Looping 1.0".
By sticking to this simple approach, we'll have functional looping sooner
rather than later.
>From there, we can build on the idea and come up with a spec for Looping 2.0.
>One idea I have myself:
- Have a bank of loops that can be mixed in somehow. For example, when you set
the loop in/out markers, it would save that loop to a bank and you could
overlay it onto audio elsewhere in the song... something like this.
Stuff like this would take more effort and need way more thought put into the
design (and thus take longer to finish), which is why I'd like for actually
spec out and code Looping 1.0 first.
>
>
> We also need a better waveform control that could display loops
> too... Russell is working on that part for GSoC...
>
> As for how the looping would be implemented in mixxx's code,
> I not really sure...
This summer is definitely an opportune time for looping to be coded, because
whoever is involved with writing looping can work with Russell to figure out a
cool way to integrate it with the new waveform view (and make sure the waveform
view is future-proofed for Looping 2.0).
As for implementation details, I can definitely help out here and mentor anyone
who wants to code looping. Right now there's some unfinished looping code
hacked into EngineBuffer that needs to be blown away. Once that's removed,
you'd create something like a "LoopingControl" class which manages the playback
position. The EngineBuffer objects would each have a LoopingControl object, and
they would ask their LoopingControl objects to update (ie. loop) the play
position for them. This "EngineBuffer asks object X to update the play
position" is precisely how the EngineBufferScale classes work. The
EngineBufferScale classes do pitch/time stretching, which affects rate at which
the playback position changes.
This the general idea. Let's do some brainstorming to figure out exactly what
people want out of Looping 1.0, make sure it's achievable in a reasonable
amount of time, and write the spec on the wiki.
Thoughts/ideas/suggestions?
Thanks,
Albert
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Mixxx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
