Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-23 Thread Ferran Pujol Camins 
Hi Sébastien,
yes I'm aware of that. In fact I plan to reserve some time to see how to
fit the new widget to Shade. LateNight and Deere are not a problem. In
fact, my mock-ups are actually modifications to the Deere skin, and it
works well with its minimum size.

Thank you for your reminder.

2016-03-23 7:29 GMT+01:00 Sébastien Blaisot :

>
> Hi Daniel, Ferran and all the others,
>
> a grid layout is a nice idea, but keep in mind that we have users with a
> smaller resolution and we need to keep the default skin usable at such
> lowres.
> Hope you will find a way to add that button grid without increasing the
> minimum skin resolution.
>
> regards,
>
> sb
>
> Le 22/03/2016 14:28, Ferran Pujol Camins a écrit :
> >
> > 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.
> >
> >
>
>
>
> --
> 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=/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
>
--
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=/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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-23 Thread Sébastien Blaisot 

Hi Daniel, Ferran and all the others,

a grid layout is a nice idea, but keep in mind that we have users with a 
smaller resolution and we need to keep the default skin usable at such 
lowres.
Hope you will find a way to add that button grid without increasing the 
minimum skin resolution.

regards,

sb

Le 22/03/2016 14:28, Ferran Pujol Camins a écrit :
>
> 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.
>
>


--
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=/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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Ferran Pujol Camins 
Nice to see we have similar points of view.

About the grid layout I have to say I actually like it, supposing my
proposal is chosen I'll ask to the community which layout they prefer and
implement the one that has more support. I can do this while starting to
develop the code changes, which don't require subjective opinion.

Thank you for your explanation.

2016-03-22 23:25 GMT+01:00 Daniel Schürmann :

> Hi Ferran,
>
> Yes, orphan cue point is it. I must have miss read it, since we already
> have this feature in the cue properties tab.
> A position and a hot cue number, where the later can be 0 = orphan.
>
> From this point of view your have proposed (1. from my mail below) a Skin
> integrated "Hot-Cue" widget, with is petty much the same what I had in mind
> when talking about the Button Grid.
>
>
>
> Am 22.03.2016 um 22:52 schrieb Ferran Pujol Camins:
>
> 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 :
>
>> 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 :
>>
>>> 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 :
>>
>>> 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=/4140___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Daniel Schürmann 

Hi Ferran,

Yes, orphan cue point is it. I must have miss read it, since we already 
have this feature in the cue properties tab.

A position and a hot cue number, where the later can be 0 = orphan.

From this point of view your have proposed (1. from my mail below) a 
Skin integrated "Hot-Cue" widget, with is petty much the same what I had 
in mind when talking about the Button Grid.




Am 22.03.2016 um 22:52 schrieb Ferran Pujol Camins:

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 >:


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 >:

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 >:

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 >:

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=/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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Ferran Pujol Camins 
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 :

> 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 :
>
>> 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>:
>
>> 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>:
>
>> 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=/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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Daniel Schürmann 

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 >:


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 >:


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 >:


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=/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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Be 
Another idea: the status of the cue list edit mode could be a CO that is 
accessible by controller scripts. Although I think in most cases it 
would be easiest to do most editing of cue points with a mouse, some 
users may want to do that with a controller.

On 03/22/2016 06:19 AM, Ferran Pujol Camins wrote:
> 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
> >:
>
> You made some interesting observations, so long mail :)  :
>
>
> 2016-03-16 21:28 GMT+01:00 Daniel Schürmann  >:
>
> * 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" 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 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  >:
>
> * 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, breakoutr), 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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Be 
This is turning into a nice proposal :) Some comments and questions for 
this new draft:

1. Cue colors: How to represent these? HTML/CSS style RGB codes? 
Integers mapped to specific colors? I think it would make sense to use 
RGB codes in the backend for maximum flexibility in the future but only 
present the options for a handful of specific colors on the front end. 
By default, I think it would be good to have each type of cue correspond 
to a different color but let the user edit the color manually if they 
would like.

2. There are use cases for manually typing the time of a hotcue in edit 
mode, so an arrow icon in the time field in edit mode would be good. For 
example, a user may be very familiar with a track from listening to it 
in other music players and have a specific time point memorized. Another 
use case would be that a user has a cue point saved in another program, 
such as Amarok or Traktor, that Mixxx doesn't (yet) have a way to import 
cue points from, but wants to put them in exactly the same spots. It 
would be good to support creating a new hotcue in an empty hotcue slot 
this way. This could also alleviate the issue of moving hotcues that are 
close together by dragging and dropping on the waveform.

3. The up/down arrows for moving hotcues in the list would work, but 
could be a bit cumbersome. It would be good to also support dragging and 
dropping, but that could wait till after GSoC.

4. I think cues should be able to be dragged and dropped on the overview 
as well as the detail waveform. Perhaps this should only work while the 
cue list is in edit mode to prevent accidental moving. Dragging & 
dropping on the overview waveform would be particularly helpful for 
section cues.

5. To make sure the complementary features at the end aren't forgotten, 
it would be good to make Launchpad bugs for the ideas that aren't in 
Launchpad already.

6. Regarding numbering of cues on the waveform, perhaps this could 
dynamically change with the filtering of the cue list. If the list shows 
all cues, number the cues on the waveform sequentially. If the list is 
filtered (with any type of filter selected), number cues on the waveform 
sequentially by type.

On 03/22/2016 06:19 AM, Ferran Pujol Camins wrote:
> 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
> >:
>
> You made some interesting observations, so long mail :)  :
>
>
> 2016-03-16 21:28 GMT+01:00 Daniel Schürmann  >:
>
> * 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" 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 trigger mode first, and once the cue list is
>

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Ferran Pujol Camins 
2016-03-22 16:14 GMT+01:00 Daniel Schürmann :

> 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 :

> 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 :

> 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=/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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Daniel Schürmann 
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 
:

> 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"  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 :

> * 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" 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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Ferran Pujol Camins 
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"  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 :
>>>
 * 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" 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 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 :
>>>
 * 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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-22 Thread Daniel Schürmann 
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 
:

> 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  >:
>
>> You made some interesting observations, so long mail :)  :
>>
>>
>> 2016-03-16 21:28 GMT+01:00 Daniel Schürmann :
>>
>>> * 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" 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 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 :
>>
>>> * 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, breakoutr), 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 :
>>
>>> * 2.3.2

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-19 Thread Be 
On 3/16/2016 3:28 PM, Daniel Schürmann wrote:
>
> * 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?
Nothing immediately comes to mind for a good way to distinguish between 
how to activate loops in these different ways if they are treated as a 
monolithic loop type. I think using two different types of cues would work.

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.

> * 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.
> * 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.
> * 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?
> * The current track property pane is somehow bound to the library. The 
> proposed player will be something like a second preview deck without 
> any controller mapping. It would be great if the user is able to use 
> the DJ controller to adjust the cues.
> Do you have an idea how we can achieve that?
>
> Kind regards,
>
> Daniel
>
>
>
>
>
> Am 16.03.2016 um 20:19 schrieb Ferran Pujol Camins:
>> Hello!
>> This is my GSOC proposal for this year: Cue points revamp. It's all 
>> pretty much explained in the document.
>>
>> The proposal is not complete. It lacks the definition of a couple of 
>> features, the work breakdown + code analysis and timeline 
>> elaboration. I have time to finish all this on time.
>>
>> But first I'd like to get some feedback on the features specification 
>> I've got so far. There is a considerable amount of work, but it is a 
>> collection of several features, so functionally complete merges to 
>> trunk can be done.
>>
>> Let me now what you think. Specially things you don't like, things 
>> you don't clearly understand or things you are not sure about. 
>> Comments about the proposal text itself are also welcome.
>>
>> Best regards, Ferran.
>>
>>
>> --
>> 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=/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
>
>
>
> --
> 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=/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


--
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=/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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-19 Thread Ferran Pujol Camins 
You made some interesting observations, so long mail :)  :


2016-03-16 21:28 GMT+01:00 Daniel Schürmann :

> * 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" 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 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 :

> * 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, breakoutr), 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 :

> * 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 :

> * 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 :

> 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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-19 Thread Daniel Schürmann 

Hi Ferran,

thank you for your real nice proposal.

Here some unsorted comments:
* nice Idea using personas for the use cases
* 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?
* 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.

* 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.
* 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?
* The current track property pane is somehow bound to the library. The 
proposed player will be something like a second preview deck without any 
controller mapping. It would be great if the user is able to use the DJ 
controller to adjust the cues.

Do you have an idea how we can achieve that?

Kind regards,

Daniel





Am 16.03.2016 um 20:19 schrieb Ferran Pujol Camins:

Hello!
This is my GSOC proposal for this year: Cue points revamp. It's all 
pretty much explained in the document.


The proposal is not complete. It lacks the definition of a couple of 
features, the work breakdown + code analysis and timeline elaboration. 
I have time to finish all this on time.


But first I'd like to get some feedback on the features specification 
I've got so far. There is a considerable amount of work, but it is a 
collection of several features, so functionally complete merges to 
trunk can be done.


Let me now what you think. Specially things you don't like, things you 
don't clearly understand or things you are not sure about. Comments 
about the proposal text itself are also welcome.


Best regards, Ferran.


--
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=/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


--
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=/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

Re: [Mixxx-devel] GSOC proposal: cue points revamp

2016-03-18 Thread Be 
Hi Ferran, this looks like a great start.

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.

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.

Is there anything that should be done for "the" cue point? How does it 
fit into this expanded model of cue points?

On 3/16/2016 2:19 PM, Ferran Pujol Camins wrote:
> Hello!
> This is my GSOC proposal for this year: Cue points revamp. It's all 
> pretty much explained in the document.
>
> The proposal is not complete. It lacks the definition of a couple of 
> features, the work breakdown + code analysis and timeline elaboration. 
> I have time to finish all this on time.
>
> But first I'd like to get some feedback on the features specification 
> I've got so far. There is a considerable amount of work, but it is a 
> collection of several features, so functionally complete merges to 
> trunk can be done.
>
> Let me now what you think. Specially things you don't like, things you 
> don't clearly understand or things you are not sure about. Comments 
> about the proposal text itself are also welcome.
>
> Best regards, Ferran.
>
>
> --
> 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=/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


--
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=/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