Hi Ferran,
the new hot cue list looks really nice.
I am just worrying if this will meet the design of recent DJ controllers.
On My RMX 2, I can switch four button per deck to be loop or hotcue
buttons.
Idea (not sure if good):
A button Grid view of the Cue widget, that represents the Hot-Cue COs
or whatever we may find on controllers.
Allow to map these buttons individually per track to the cues in the list.
Maybe you should add a few sentences about controller mapping.
Kind regards
Daniel
2016-03-22 12:19 GMT+01:00 Ferran Pujol Camins <ferranpujolcam...@gmail.com>
:
> Hello, I've reworked the specification to include some of your
> considerations. What's new:
>
> -I've written the cue point list section (including mock-ups).
> -The editing of cue points is now integrated in the main window.
> -Extended explanation of why I exclude support for cue points not assigned
> to any hot cue.
> -Added explanation of why I leave a cue list filtering feature to a "2.0
> phase" of the project.
> -Minor improvements in the document.
>
> I appreciate your feedback.
>
> Best regards, Ferran.
>
> 2016-03-17 9:53 GMT+01:00 Ferran Pujol Camins <ferranpujolcam...@gmail.com
> >:
>
>> 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=278785351&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
