You made some interesting observations, so long mail :) :
2016-03-16 21:28 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>:
> * Recall loop cues:
> IMHO DJSally jump mode requires, that the jump happens on cue button press
> and not after release.
> If you distinguish, the activate mode by a long press, you can't jump
> mediately, which is probably required to mix beat sync by ear. Do you think
> we can introduce a new cue type to distinguish these types of loops?
>
That's a good point I didn't think about. Let's see:
I just realize that the reloop button in Mixxx actually does the
"jump&reloop" mode rather than "only reloop" mode. So first of all I'll
need to add a new CO for it. Binding it to the right click is the obvious
approach, but we need this to be consistent with what we do with loop hot
cues (which won't be right click because it is already used to clear the
hot cue).
Similarly, for the hot cues we'll need two CO: "hotcue_X_activate" and a
new "hotcue_X_reloop" (for cue points that are a time point rather than a
time range both CO will do the same).
Solution 1 is to use a modifier key like control or shift to choose which
trigger mode to use. In fact this is the natural approach for controllers.
But currently we don't use keyboard modifiers to alter mouse behaviour in
Mixxx, don't we? How does this sounds to you?
Solution 2 is to have an additional button (that appears only when the hot
cue is assigned to a loop) that allows to activate the loop without jumping
to it. This is the approach Serato takes:
A similar cue list widget is in the proposal but I haven't got time to
write the corresponding section yet.
The problem with the second approach is that it doesn't fit with our
current cue point buttons. However, what I could do is: implement only the
jump&loop trigger mode first, and once the cue list is done, implement the
other mode. It seems reasonable to me.
I don't really like the idea of two distinct cue types for this. I feel
some users would end up with to identical loops just to be able to choose
how to trigger them.
2016-03-16 21:28 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>:
> * Section cues: We have already "sections" defined by the detected keys I
> wonder how these key sections compares to the cue section. Maybe we can use
> the key infos to help the Dj setting up the cue sections.
How are key sections going to be displayed? Maybe they could be modelled
with a new cue type called "key zone" (or whatever name we find
appropriate).
Key marks are similar to beatgrid: is information that can be empirically
determined. On the other hand, cue sections are more a subjective thing:
sure tracks somehow have a determined structure (intro, break....outr), but
different users might prefer to focus on different track features. For
example, a user might prefer to use section cues to simply mark where the
kick is on or off in the track, while another one might prefer to use
section cues to reflect where the break, intro, outro, etc are.
For this reason, the way I understand it, this sections will be edited in a
different tab in track preferences (the same way beatgrid is). We can
visualize them in the cue points tab waveform (in a similar way we do with
beatgrid) to help user make educated decisions about the section cues
he/she wants to create.
So, the way I see it is: key sections would fit well with my proposal, but
since it is not yet a finished feature, I would prefer to leave it out of
my proposal.
2016-03-16 21:28 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>:
> * 2.3.2 Bottom section
> I am not sure if it is a good idea to display all cue types in a common
> list. This surely works wit a hand full of cues but might getting hard with
> a lot of them. Especially the section cues should be in a separate list.
> How about a simple type filter.
>
Totally agree. Maybe I'm going to schedule this as a 2.0 development phase
for the track preferences pane, but definitely going to include this in my
proposal.
2016-03-16 21:28 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>:
> * Will it be possible to change a cue type live? For example a break
> section can be used as a jump or as a loop. Is it a valid use case or just
> a stupid idea?
Not stupid idea :). I think the general case of using a cue as a different
type from which it was originally created adds unnecessary complexity.
However, you can always trigger a loop cue and immediately exit the loop.
And conversely, you can always jump to a simple cue and immediately set a
loop. You could even set a loop cue and a simple cue to the same place if
you really feel it would be better to you.
2016-03-16 22:24 GMT+01:00 Be <b...@gmx.com>:
> My biggest concern is requiring another window to be opened for the
> fully featured cue point editor. I forsee a few issues with this. First,
> it would require duplicating a lot of design and functionality from the
> main window/skins. It would also present an issue for controller
> mappings as Daniel pointed out. Also, I think the workflow would be
> awkward for editing cues while playing. I think it would be better to
> implement the GUI features as a section of skins that could be toggled
> between showing and hidden. If all features can be intuitively
> controlled from the main window, I think the cue tab in the Track
> Properties window would be redundant and could be removed.
>
I can see your point. My idea was to provide basic cue point editing
capabilities to the main window and delegate a complete editor to the
preferences window, because you are definitely not going to set your
section cues during a live set for example, it is something you want to do
will preparing your tracks.
However, I can see your point and I may like it. I'm going to prepare a
mock-up for how this could be fitted in Deere (Latenight should be about
the same). My biggest concern here is the little sister: Shade. Can this
all be fitted into Shade?
2016-03-16 22:24 GMT+01:00 Be <b...@gmx.com>:
> Is there anything that should be done for "the" cue point? How does it
> fit into this expanded model of cue points?
>
>From a quick analysis: not really. Am I missing something?
2016-03-16 22:24 GMT+01:00 Be <b...@gmx.com>:
> A feature that would compliment what you've proposed and be helpful for
> using controllers would be to create control objects that sequentially
> represent a specific type of cue. For example, setting loop_cue_1 to 1
> would enable whatever the first loop cue is, regardless of what number
> hotcue it is assigned or what number cue it is in the database. This
> would allow controller mappings to have different layers for their
> pads/buttons for using different types of cues. All types of cues should
> be able to be mixed and matched in one big list as well. This would
> allow users to arrange different types of cues however they want in a
> way that makes sense for their use and on their controller. For example,
> a user could set cue 1 to a simple hotcue for a point and cue 2 to a
> loop cue starting at that same point, but the user might not ever want a
> loop at cue 3. The user could either press pad 1 or 2 depending on
> whether they wanted to loop without having to switch to a different
> layer of the mapping.
>
That's something interesting, but it needs think through. How are you going
to render a a loop cue in the waveform? It is going to be cue point nº 3
but maybe loop nº 1. Let me add this to the list of things to do next, it's
a list of cool things to implement but that are second priority (sort of
cue points revamp 2.0 material).
2016-03-16 22:24 GMT+01:00 Be <b...@gmx.com>:
> Another use case I thought of for these automatically activating type of
> loops would be in sample decks. If the load cue is set at the same point
> as an automatically activating loop cue, the user would only have to
> press play on the sampler to utilize a loop without having to use one of
> the main decks or cut that loop out into another file.
>
Maybe we could remove the cue type "Load", and rather add an exclusive flag
to the cue model that indicates that this is the cue point to be used as
Load cue. This way the load cue can be a simple cue or a loop.
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org
Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
