Hi Ferran,
IMHO it is not required to reflect the exactly the controller layout.
It was only my thought about how to reflect a static button grid with
probably multi layers and labels on the controller in your GUI.
If I got it right, the first four Cue-points are tied to the hot cues.
If a user wants to map a hot cue button to a different cue, he has to shift
the new cue to the top.
It is hard to judge about it without trying, but for my feeling the may
think different.
He probably wants to to map a cue to a button, by doping it to a button
grid ..
This allows to keep the cue list in consecutive order.
If we find out the proposed solution works good, it is fine as well.
Kind regards,
Daniel
2016-03-22 14:28 GMT+01:00 Ferran Pujol Camins <ferranpujolcam...@gmail.com>
:
> Hey Daniel,
>
> Good point, a cue grid would better fit current controllers. There are
> some complications:
>
> Different controllers have different have different button layouts. Yours
> is 2x2, a MidiFighter or Kontrol F1 is 4x4 and DDJ-RZ is 2x4. Furthermore,
> if a User splits a 4x4 controller between two decks, he or she probably
> would want left size to control deck A and right side to control deck B,
> leaving us with a 4x2 layout.
>
> So whatever we choose to be our default layout, we will only match the
> controller layout of part of our users. It would be cool to let the user
> choose the layout he or she prefers, but this is a lot of work. Let me add
> this to the wishlist.
>
> However, I'm okay to choose a 2x4 grid layout as the first I implement,
> because I agree with you that it will better fit more users. I'll reflect
> that in the proposal.
>
> Also, what do you exactly mean with "Allow to map these buttons
> individually per track to the cues in the list."? Could you write an
> example?
> El dia 22/03/2016 1:46 p. m., "Daniel Schürmann" <dasch...@mixxx.org> va
> escriure:
>
> 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
