Okay I think now I understand you.
I think what you mean is the same thing that I called "orphan cue points
support" in the proposal.
In the current proposal, a cue point is always tied to a hot cue. When the
hot cue is cleared, the cue point is deleted rather than simply unassigned.
This means there are no cue points other than the ones assigned to hot cues.
If I understood you correctly, what you call the cue stock would be a list
with cue points assigned to a hot cue but also unassigned cue points
(orphan cue points). If the DJ clears a hot cue, the hot cue is shown empty
(ready to have a new cue point assigned). But the cue point is not deleted,
but rather unassigned, so it can still be accessed through the stock list
and assigned to another hot cue.
Could you confirm that what you meant is actually similar to what I explain
in section 6.1 Support orphan cue points?
2016-03-22 21:00 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>:
> Hi Ferran,
>
> Your current proposal already works for me.
>
> My ideas came up when thinking about a slick controller intergeneration.
>
> After our discussion I am not sure if we need it at all, including the
> button grid.
> It can be probably overdone or hard to handle.
>
> But lets explain my original idea a bit more compared to the current state
> (please correct)
>
> In the current view we have a table of hot-cue slots, statical mapped to
> the hot-cue cos
> The top of the list is always hot cue 1. This is easy and simple.
>
> My idea was to have two representations of a cue list:
> 1: the mapped cues list or button Grid
> 2: A cue stock, which contains all track position markers including hot
> cues.
>
> Now the DJ can add a hotcue marker to any position stored in the stock
> list.
> This will reassign the related hot-cue button on the controller.
> He is also able to sign temporary position to the hot-cue buttons without
> loosing any cue point
> in the stock list or messing around with it.
>
>
>
>
> Am 22.03.2016 um 16:29 schrieb Ferran Pujol Camins:
>
>
> 2016-03-22 16:14 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>:
>
>> 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.
>
>
> So would a 2x4 (2 rows 4 buttons per row) layout with 4 pages work for
> you?
>
> 2016-03-22 16:14 GMT+01:00 Daniel Schürmann < <dasch...@mixxx.org>
> dasch...@mixxx.org>:
>
>> 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.
>>
>
> I'm not sure what you mean here.
> As explained in the proposal, a cue point is always tied to some hot cue.
> This for the sake of simplicity.
>
> A cue point can be set to any hot cue, regardless of its type. There's
> nothing as hot cues that can only hold loops nor hot cues that can only
> hold cue points.
> If a user wants to map a hot cue to a different cue point, he can either
> clear the hot cue and set a new cue point or move the current cue point to
> a new position and rename it.
>
> 2016-03-22 16:14 GMT+01:00 Daniel Schürmann < <dasch...@mixxx.org>
> dasch...@mixxx.org>:
>
>> He probably wants to to map a cue to a button, by doping it to a button
>> grid ..
>>
>
> Again, cue points are always tied to some hot cue.
>
> But I'm afraid I'm not getting your concers. Could you please elaborate
> what worries you a little more?
>
>
>
------------------------------------------------------------------------------
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
