Re: [Mixxx-devel] infrastructure modernization

[Ferran Pujol Camins]

I need an invitation to say hi :)

On 31 Dec 2017 10:28 a.m., "Daniel Schürmann"  wrote:

> Hi Ferran,
>
> we are currently evaluating
> https://mixxx.zulipchat.com/
>
> Just got thumbs up for a FOSS free hosting plan.
>
> Kind regards,
>
> Daniel
>
>
>
> Am 31.12.2017 um 10:16 schrieb Ferran Pujol Camins:
>
> It's ironic that to read this conversation I've needed to look into four
> different email threads. Now I'm not even sure this is the last one.
>
> I Just wanted to add that if we move from email to a new tool as our main
> communication channel, we should make sure that the new tool has a good
> mobile app. Also that people not wanting to install yet another app can get
> a reasonable good experience with mail alerts.
>
> On 19 Nov 2017 12:36 p.m., "Daniel Schürmann"  wrote:
>
>> Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:
>>
>>
>> [...]
>>
>>> I think it could be really helpful to make a GitLab repository for
>>> controller mappings. We could use its issue tracker to take requests for
>>> controller mappings so users could vote for mappings they want. That would
>>> give us data on what hardware is important to map, which could guide us on
>>> what to ask manufacturers for and/or what to spend donations on.
>>>
>>
>> As we did it for manuals, we may split out mappings from the main repo.
>> [...]
>>
>> Now that you mention this, does Git have the concept of externals like
>> Subversion has?  If it does, controllers, skins and manual could be
>> separated repos and the Mixxx repo could use them as externals, so those
>> that work on Mixxx have everything, and other contributors can focus on the
>> manual, skins or controllers.
>>
>>
>> Yes it has. We did experiment with it, but It was annoying to use.
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> 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
>>
>
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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] infrastructure modernization

[Ferran Pujol Camins]

It's ironic that to read this conversation I've needed to look into four
different email threads. Now I'm not even sure this is the last one.

I Just wanted to add that if we move from email to a new tool as our main
communication channel, we should make sure that the new tool has a good
mobile app. Also that people not wanting to install yet another app can get
a reasonable good experience with mail alerts.

On 19 Nov 2017 12:36 p.m., "Daniel Schürmann"  wrote:

> Am 19.11.2017 um 11:46 schrieb Josep Maria Antolin:
>
>
> [...]
>
>> I think it could be really helpful to make a GitLab repository for
>> controller mappings. We could use its issue tracker to take requests for
>> controller mappings so users could vote for mappings they want. That would
>> give us data on what hardware is important to map, which could guide us on
>> what to ask manufacturers for and/or what to spend donations on.
>>
>
> As we did it for manuals, we may split out mappings from the main repo.
> [...]
>
> Now that you mention this, does Git have the concept of externals like
> Subversion has?  If it does, controllers, skins and manual could be
> separated repos and the Mixxx repo could use them as externals, so those
> that work on Mixxx have everything, and other contributors can focus on the
> manual, skins or controllers.
>
>
> Yes it has. We did experiment with it, but It was annoying to use.
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> 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
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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] signal processing background info resources

[Ferran Pujol Camins]

Maybe we can add your links here:
https://mixxx.org/wiki/doku.php/learning_resources
and link this page instead?


2017-12-12 0:05 GMT+01:00 Be :

> Hi,
> I've added some links to resources I've found very helpful for
> understanding audio technology to the wiki:
> https://mixxx.org/wiki/doku.php/developer_guide#prerequisites
> I hope this helps potential contributors become active developers. :)
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> 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
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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

[Mixxx-devel] Interesting webMidi article

[Ferran Pujol Camins]

http://djtechtools.com/2017/05/25/build-next-traktor-midi-controller-google-chrome/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
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 2017

[Ferran Pujol Camins]

I've changed the link to the new cue points blueprint.

Also, I have my proposal for cue points from last year, which is quite
complete. Should I attach it? Or we prefer students to come up with a
proposal from zero?

On 12 Feb 2017 10:20 p.m., "Be"  wrote:

> Cool, I added a handful of ideas that I think would be appropriate in
> scope.
>
> On 02/12/2017 01:22 PM, RJ Ryan wrote:
> > tl;dr we applied for GSoC this year. We'll learn if we're accepted
> > February 27th.
> >
> > * Please add project ideas to this page:
> > https://www.mixxx.org/wiki/doku.php/gsoc2017ideas
> > * Please email gsoc2017-ment...@mixxx.org
> >  if you would like to mentor a
> project.
> >
> > A good rule of thumb is that a GSoC project is something an expert Mixxx
> > developer can take care of in a weekend.
> >
> > We have a bad track record of projects merging into Mixxx. By my count,
> > 8 projects out of the 25 total since 2007 have merged into Mixxx. To
> > improve the situation, last year we tried to require that projects have
> > concrete merge-able milestones, but didn't do a good job of sticking to
> > this. This summer we need to do a better job of keeping the scope
> > smaller and splitting into small deliverables. Please keep this in mind
> > when posting project proposals.
> >
> > Thanks,
> > RJ
> >
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >
> >
> >
> > ___
> > 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
> >
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> 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
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
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] Is --controllerDebug broken in master?

[Ferran Pujol Camins]

2017-01-23 19:59 GMT+01:00 RJ Ryan :

> --debugLevel 4



Yes, this solves the issue. Thanks :)
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
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

[Mixxx-devel] Is --controllerDebug broken in master?

[Ferran Pujol Camins]

I can see incoming midi messages from activated controllers in Mixxx 2.0.0
by passing the option --controllerDebug.

This does not happen in master. Is this a bug or there's something I'm not
aware of?
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
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] Please test these 2.1 Windows builds

[Ferran Pujol Camins]

>
> * No Mixxx logo on splash screen.


Same here.

I've found no problems. Tested sample m4a file from here:
http://techslides.com/sample-files-for-development

Tested in Windows 10 home x64 (version 1607, so version 14393.693), both
x86 and x64 Mixxx versions.

2017-01-19 18:40 GMT+01:00 RJ Ryan :

>
>
> On Thu, Jan 19, 2017 at 12:47 AM Sébastien Blaisot 
> wrote:
>
>>
>>
>>
>> Le 19/01/2017 à 08:35, RJ Ryan a écrit :
>>
>> On Wed, Jan 18, 2017 at 11:23 PM Sébastien Blaisot 
>> wrote:
>>
>>
>>
>> otherwise, seems to work pretty well. album art show correctly (png +
>> jpg), so qt's imageformat are included.
>>
>>
>> The only imageformats .libs that were built in the plugins folder were
>> qico, qsvg, and qtga so I think we may need to link those manually (would
>> explain the logo issue since that's an SVG). The rest are maybe built in?
>>
>>
>> not an SVG issue, since Deere's svg elements are showing well (sandwich
>> menu for exemple).
>>
>
> In our skin system, we use QtSvg classes to parse and render the skin
> SVGs. I think this is different than having support for SVG in QImage,
> which is what the CSS system uses to parse SVGs (and the launch image is
> specified via CSS). So I think it probably is a missing SVG imageformat
> plugin.
>
>
>>
>> or maybe some call to Qt functions to load imageformat after splash
>> screen and before skin drawing that should be moved inside mixxx code.
>>
>>
>> sb
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot__
>> _
>> 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
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> 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
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
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] n-band EQ

[Ferran Pujol Camins]

I'm afraid we will end up with lots of EQs: generic EQs that only differ on
slope or number of bands + eqs that mimic a specific hardware mixer. Thats
confusing.

AFAIK there's two kinds of EQ we are talking about:

1-EQs based on a crossover
2-EQs that are a combination of filters low/hi pass, bell...)

It's hard to fit both kinds under the same general structure. But maybe we
can think of providing a general type of EQ for each.

1) A crossover EQ parametrizable by number of bands and slope.
2) A parametric EQ where filters of different kind can be added

"xone 92 eq", "Model 1 eq" would then become presets of 2)

What do you think? 2) is ambitious, but I think 1) is realistic and we
would already reduce the number of available EQs.

On 17 Jan 2017 3:41 a.m., "Be"  wrote:

> In addition to emulating the Xone:92, it would be fun to have an EQ
> emulating the PLAYdifferently Model 1, which also uses 4 knobs:
> https://bugs.launchpad.net/mixxx/+bug/1581721
>
> On 01/16/2017 06:47 AM, Ferran Pujol Camins wrote:
> > Following discussion in https://github.com/mixxxdj/mixxx/pull/1007
> >
> > Reusing the Qick effect knob for the fourth EQ band, Is IMO very
> handy
> > because it works for the Controller and for the GUI. The GUI still
> > matches 1:1 to the controller.
> >
> > We have also discussed to use the gain knob as fourth EQ band. If we
> > consider that, we need to decouple the GUI/Controller form the
> > Internal CO values from the engine and allow to set a mapping form
> > the EQ preferences.
> >
> > I prefer this over scripting solution, since it will be "midi
> > leanable" and it do not requires to touch all mappings, except
> > changing the names to the new mappable knobs.
> >
> > But you loose either the gain knob or the Quick Effect knob. I want both
> > of them :)
> >
> > IMHO shrinking the knobs so they fit in the same space when n=4 is
> > possible. Again, Traktor does it.
> >
> > Suppose that the 4 knobs can satisfactorily be fit in each skin.
> > Wouldn't you prefer this over loosing gain or Quick Effect knob?
> >
> >
> >
> >
> > 
> --
> > Developer Access Program for Intel Xeon Phi Processors
> > Access to Intel Xeon Phi processor-based developer platforms.
> > With one year of Intel Parallel Studio XE.
> > Training and support from Colfax.
> > Order your platform today. http://sdm.link/xeonphi
> >
> >
> >
> > ___
> > 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
> >
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> 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
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
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] n-band EQ

[Ferran Pujol Camins]

Sure, I expect to find time in a week or so.

On 16 Jan 2017 11:03 p.m., "Daniel Schürmann"  wrote:

>
>
> Am 16.01.2017 um 18:13 schrieb Ferran Pujol Camins:
> > By the way, do you have access to a xone:92 to revers engineer the
> > behavior, or should be just made our own 4 band EQ as a combination
> > of 2 isolators knobs and two EQ knobs?
> >
> >
> > No, just to Traktor's emulation.
>
> Great, would you mind to record the default Traktor EQ? using the
> sweeping sound as described here?
> https://github.com/mixxxdj/mixxx/pull/1007#issuecomment-270592862
> This will threw some light how Mixxx sounds by default compared to Traktor.
>
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> 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
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
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] making GSoC better for Mixxx

[Ferran Pujol Camins]

2017-01-16 21:04 GMT+01:00 Be :

> That is an interesting point that it doesn't matter much if a student is
> in it for the money if the community gets something positive out of it at
> the end. Requiring smaller PRs with community review would help with that.



Also fail a student early. It is highly encouraged by Google. Then in
future GSOCs we can warn: "Hey, last year we failed a student at mid-term
because he did not meet our goals. Make sure you are here for the right
reasons."
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
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] making GSoC better for Mixxx

[Ferran Pujol Camins]

Of three students:

   - One failed.
   - The second one did quite a good job. Code was not merged by the end of
   GSOC. He quit soon after we gave him the pass grade. (I'll send him an
   email to see if I can make him come back :) )
   - The other one did quite a good job. Code was not merged by the end of
   GSOC. Still active in the community.

I think it's easy to encounter students like 2), and that's just because
the pay is tempting. I think this is inevitable and you only know the
student is not going to contribute anymore once GSOC is over. I'm with you:
if code is merged, is not so bad if a student does not become a regular
contributor. However, limiting ourselves to take only one student decreases
the chances to find a student like 3).

What we sure need to handle better is students like 1). AFAIK he was
recruited somehow in a hurry. Maybe we should demand stronger applications
to really tell apart students that are there only for the pay.

2017-01-16 19:48 GMT+01:00 Be :

> I have been thinking lately about how few Google Summer of Code projects
> have been merged into Mixxx. When projects are not merged, in my opinion
> this has a net negative impact on Mixxx because the time the mentor and
> other contributors spent is wasted. I think we need to change how we
> approach GSoC for it to have a net positive impact on Mixxx.
>
> I think we have been selecting too many projects each year. Perhaps we
> could have more success with GSoC if we only accept one project per
> year. This would let the mentor and the community focus more and
> hopefully raise the chance that there is code to merge at the end of the
> internship. Personally, I found it overwhelming to keep up with the
> different projects last summer, so I didn't pay much attention to how
> they were going until one was ready for review. If the community is more
> involved throughout the whole process, I think the community will be
> more invested in ensuring that something gets merged. Also, the
> community will have more opportunity to shape the direction of the
> project early on, which could avoid the need for complicated redesign at
> the end. This would benefit the student too by giving them more of an
> experience of collaborating with a distributed, global group of
> contributors.
>
> Another change that could be helpful would be to require small pull
> requests throughout the internship instead of one big one at the end.
> This would ensure that at least some progress gets merged and make it
> easier for the community to continually review the progress.
>
> What do you think about the above changes? Do you have any other ideas
> for how to make GSoC work better for Mixxx?
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> 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
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
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] n-band EQ

[Ferran Pujol Camins]

>
> IMO we're already doing the right thing here.  The controller preset
> author is best situated to decide what makes sense per controller (usually,
> that corresponds to going with whatever the letters printed on the plastic
> say), and the user is best situated to decide what makes sense for
> themselves. So we allow the controller preset author maximum flexibility
> (Javascript) to do whatever they want, and the user the ability to
> customize that (preset options, MIDI learn).
>
It's true that changing a knob to make it control EQ shold be easy with the
midi learning wizard. So...

Is the following a solution we can all agree?:

1-Skins show 3 or 4 eq knobs based on how many bands the selected EQ has.
2-Each controller will have a default mapping set for 3 or 4 band eq,
according to what makes sense for that controller.
3-Users wanting to adopt a 4-band eq in a controller with a 3-band preset
can use midi learning wizard to change it.

This makes sense if we think that in a future we will have midi presets
with options that can be tweaked from the preferences pane, since mappers
will be able to offer specific solutions to support 4-band eq such as
replacing the gain knob.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
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] n-band EQ

[Ferran Pujol Camins]

What about this:

   1.

   Let mappings declare how many knobs per mixer channel they offer
   (typically 5: 3-band eq, gain and quick effect)
   2.

   Decide what to show and how to map based on number of declared knobs /
   number of bands of the selected EQ:

3 declared knobs:

Number of Eq bands:

No Eq

2

3

1st knob

Gain

Gain

Eq 1

2nd knob

Quick Fx 1

Eq 1

Eq 2

3rd knob

Quick Fx 2

Eq 2

Eq 3



4 declared knobs:


Number of Eq bands:

No Eq

2

3

4

1st knob

Gain

Gain

Gain

Eq 1

2nd knob

Quick Fx 1

Eq 1

Eq 1

Eq 2

3rd knob

Quick Fx 2

Eq 2

Eq 2

Eq 3

4th knob

Quick Fx 3

Quick Fx 1

Eq 3

Eq 4


5 declared knobs:


Number of Eq bands:

No Eq

2

3

4

5

1st knob

Gain

Gain

Gain

Gain

Eq 1

2nd knob

Quick Fx 1

Eq 1

Eq 1

Eq 1

Eq 2

3rd knob

Quick Fx 2

Eq 2

Eq 2

Eq 2

Eq 3

4th knob

Quick Fx 3

Quick Fx 1

Eq 3

Eq 3

Eq 4

5th knob

Quick Fx 4

Quick Fx 2

Quick Fx 1

Eq 4

Eq 5


6 declared knobs:


Number of Eq bands:

No Eq

2

3

4

5

6

1st knob

Gain

Gain

Gain

Gain

Gain

Eq 1

2nd knob

Quick Fx 1

Eq 1

Eq 1

Eq 1

Eq 1

Eq 2

3rd knob

Quick Fx 2

Eq 2

Eq 2

Eq 2

Eq 2

Eq 3

4th knob

Quick Fx 3

Quick Fx 1

Eq 3

Eq 3

Eq 3

Eq 4

5th knob

Quick Fx 4

Quick Fx 2

Quick Fx 1

Eq 4

Eq 4

Eq 5

6th knob

Quick Fx 5

Quick Fx 3

Quick Fx 2

Quick Fx 1

Eq 5

Eq 6


And so on...

By the way, do you have access to a xone:92 to revers engineer the
> behavior, or should be just made our own 4 band EQ as a combination of 2
> isolators knobs and two EQ knobs?
>

No, just to Traktor's emulation.


2017-01-16 16:04 GMT+01:00 Be :

> Maybe we shouldn't add any hacks to the EQ preferences and leave it to
> controller mappings considering that this will only affect controllers.
> This will be more user friendly when we have a better way for users to
> edit mapping options without opening a JavaScript file in a text editor.
>
> On 01/16/2017 08:57 AM, Be wrote:
> > Setting the gain knob to the 4th EQ knob would be odd because the gain
> > knob is typically above EQs. So, to use a 4 band EQ by repurposing a
> > gain knob, it would make more sense to remap the gain + EQ knobs so they
> > go in order down the controller. I don't think an option should be added
> > to the EQ preferences for this.
> >
> > On the other hand, filter knobs are typically below EQs, so I think
> > adding an option in the EQ preferences to use the QuickEffect knob as
> > the 4th EQ knob could work well. This option should only appear when a
> > 4-band EQ is loaded.
> >
> > On 01/16/2017 08:24 AM, Daniel Schürmann wrote:
> >> As said, you can already build a sink with a dynamic amount of knobs.
> >> But you cannot do this on a controller.
> >>
> >> I personally would use the gain knob. (My controller has no filter knob)
> >>
> >> Using a four band EQ on a controller with only 3 knobs does not really
> >> makes sense. So the user needs to "solve" the issue there as well.
> >> Currently he can "learn" the new EQ knobs, but it would be really handy
> >> to have a checkbox or something in the EQ preferences to "user the
> >> filter knob for EQ" or use "gain knob for EQ"
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2017-01-16 13:47 GMT+01:00 Ferran Pujol Camins
> >> mailto:ferranpujolcam...@gmail.com>>:
> >>
> >> Following discussion in https://github.com/mixxxdj/mixxx/pull/1007
> >> <https://github.com/mixxxdj/mixxx/pull/1007>
> >>
> >> Reusing the Qick effect knob for the fourth EQ band, Is IMO very
> >> handy
> >> because it works for the Controller and for the GUI. The GUI
> >> still matches 1:1 to the controller.
> >>
> >> We have also discussed to use the gain knob as fourth EQ band.
> >> If we consider that, we need to decouple the GUI/Controller form
> >> the Internal CO values from the engine and allow to set a
> >> mapping form the EQ preferences.
> >>
> >> I prefer this over scripting solution, since it will be "midi
> >> leanable" and it do not requires to touch all mappings, except
> >> changing the names to the new mappable knobs.
> >>
> >> But you loose either the gain knob or the Quick Effect knob. I want
> >> both of them :)
> >>
> >> IMHO shrinking the knobs so they fit in the same space when n=4 is
> >> possible. Again, Traktor does it.
> >>
> >> Suppose that the 4 knobs can

[Mixxx-devel] n-band EQ

[Ferran Pujol Camins]

Following discussion in https://github.com/mixxxdj/mixxx/pull/1007
>
> Reusing the Qick effect knob for the fourth EQ band, Is IMO very handy
> because it works for the Controller and for the GUI. The GUI still matches
> 1:1 to the controller.
>
> We have also discussed to use the gain knob as fourth EQ band. If we
> consider that, we need to decouple the GUI/Controller form the Internal CO
> values from the engine and allow to set a mapping form the EQ preferences.
>
> I prefer this over scripting solution, since it will be "midi leanable"
> and it do not requires to touch all mappings, except changing the names to
> the new mappable knobs.
>
But you loose either the gain knob or the Quick Effect knob. I want both of
them :)

IMHO shrinking the knobs so they fit in the same space when n=4 is
possible. Again, Traktor does it.

Suppose that the 4 knobs can satisfactorily be fit in each skin. Wouldn't
you prefer this over loosing gain or Quick Effect knob?
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
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

[Mixxx-devel] Crash in master when changing effect chain

[Ferran Pujol Camins]

Are you aware of this?

https://bugs.launchpad.net/mixxx/+bug/1655698
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
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] Left library pane selection

[Ferran Pujol Camins]

Sorry, didn't see the new thread. Please ignore my last mail :)

2016-08-25 9:13 GMT+02:00 Ferran Pujol Camins :

> +1 to Be's proposal.
>
> "It should be possible to open a pane where it was, without
>>
> thinking"
>>
>
> I understand your concerns, but as Be's pointed out, remembered
> associations are confusing. I think it is not the best way to solve your
> problem. My tabs proposal was an idea meant to solve this. Or the focus
> block feature could also work. There are alternatives.
>
> We have to keep finding another approach that suits your use case but does
> not relay on remembered associations :)
>
> 2016-08-21 23:47 GMT+02:00 Daniel Schürmann :
>
>>
>> Am 21.08.2016 um 23:04 schrieb Be:
>> > Okay, I understand your proposal better. There are still differences in
>> > what I'm proposing. I propose that there always be a right pane focused;
>> > there would be no way to unset the focus.
>>
>> If we decide for such a schema, a very important requirement is not
>> fulfilled: "It should be possible to open a pane where it was, without
>> thinking". Without that feature, it is a pain to DJ with two panes, try
>> it out ;-). In addition the simple midi menu -> sub-menu navigation does
>> not work, it will always use the same pane.
>>
>> > There would not be any
>> > corresponding indicator on the feature icons because the new icon
>> > wouldn't create a remembered association. I think any method for
>> > creating a remembered association would get confusing. What is shown on
>> > screen at the present moment should very clearly indicate what will
>> > happen when an icon is pressed without the user having to remember what
>> > they did previously.
>>
>> Yes right, that would be still an issue. This can be solved by temporary
>> preselect the pane (show pointing hand) when hovering over a desired
>> feature button.
>>
>> > If I understand your proposal correctly, it would keep the current
>> > behavior of requiring the feature icon to be clicked again to open the
>> > left pane controls for a feature that already has a right track table
>> > open. IMO this is cumbersome and a little confusing.
>>
>> It is slightly different (note: there is a pending bug in the current
>> branch that prevent this):
>> Lets say you have already a playlist in the right pane.
>> You can preselect the left pane and select the desired second play-list
>> from the playlist tree. Now you have two playlist side by side.
>> If you do not touch the preselect icon, the new playlist will replace
>> the playlist in the right pane. As I understand this would be the same
>> in your proposal.
>>
>> > There should be a
>> > way to show the corresponding left pane controls directly from the right
>> > pane without having to move the cursor away to the feature icons. I
>> > propose that focusing a right pane with the new icon would open its
>> > corresponding left pane.
>>
>> We cannot do this in the current concept, because this would prevent the
>> two playlists side by side use case as outlined above.
>>
>> > With the right pane focus decoupled from
>> > clicking in the track tables, there would not be the issue of annoying
>> > flickering of the left pane when clicking in different track tables.
>>
>> I am fine with changing the LibrarySidebarExpanded only by the button
>> bar. This avoids the mentioned flickering and allows the sorting to
>> playlist use case as discussed earlier.
>>
>> A track table focus dependent change of the LibrarySidebarExpanded will
>> IMHO not add any additional value to the use. The Breadcrumb and the
>> search bar should be sufficient to indicate the table state.
>>
>>
>> >
>> > On 08/21/2016 03:43 PM, Daniel Schürmann wrote:
>> >>
>> >>
>> >> Am 21.08.2016 um 22:33 schrieb Be:
>> >>>>> * When focused, a feature's left pane is shown.
>> >>>>> * Clicking feature icons always opens the feature in the focused
>> right pane.
>> >>>>
>> >>>> I do not understand these suggestions. Is it different from my
>> original
>> >>>> proposal?
>> >>>
>> >>> Yes. You suggested that the track table focus gets reset to the left
>> >>> tr

Re: [Mixxx-devel] Left library pane selection

[Ferran Pujol Camins]

+1 to Be's proposal.

"It should be possible to open a pane where it was, without
>
thinking"
>

I understand your concerns, but as Be's pointed out, remembered
associations are confusing. I think it is not the best way to solve your
problem. My tabs proposal was an idea meant to solve this. Or the focus
block feature could also work. There are alternatives.

We have to keep finding another approach that suits your use case but does
not relay on remembered associations :)

2016-08-21 23:47 GMT+02:00 Daniel Schürmann :

>
> Am 21.08.2016 um 23:04 schrieb Be:
> > Okay, I understand your proposal better. There are still differences in
> > what I'm proposing. I propose that there always be a right pane focused;
> > there would be no way to unset the focus.
>
> If we decide for such a schema, a very important requirement is not
> fulfilled: "It should be possible to open a pane where it was, without
> thinking". Without that feature, it is a pain to DJ with two panes, try
> it out ;-). In addition the simple midi menu -> sub-menu navigation does
> not work, it will always use the same pane.
>
> > There would not be any
> > corresponding indicator on the feature icons because the new icon
> > wouldn't create a remembered association. I think any method for
> > creating a remembered association would get confusing. What is shown on
> > screen at the present moment should very clearly indicate what will
> > happen when an icon is pressed without the user having to remember what
> > they did previously.
>
> Yes right, that would be still an issue. This can be solved by temporary
> preselect the pane (show pointing hand) when hovering over a desired
> feature button.
>
> > If I understand your proposal correctly, it would keep the current
> > behavior of requiring the feature icon to be clicked again to open the
> > left pane controls for a feature that already has a right track table
> > open. IMO this is cumbersome and a little confusing.
>
> It is slightly different (note: there is a pending bug in the current
> branch that prevent this):
> Lets say you have already a playlist in the right pane.
> You can preselect the left pane and select the desired second play-list
> from the playlist tree. Now you have two playlist side by side.
> If you do not touch the preselect icon, the new playlist will replace
> the playlist in the right pane. As I understand this would be the same
> in your proposal.
>
> > There should be a
> > way to show the corresponding left pane controls directly from the right
> > pane without having to move the cursor away to the feature icons. I
> > propose that focusing a right pane with the new icon would open its
> > corresponding left pane.
>
> We cannot do this in the current concept, because this would prevent the
> two playlists side by side use case as outlined above.
>
> > With the right pane focus decoupled from
> > clicking in the track tables, there would not be the issue of annoying
> > flickering of the left pane when clicking in different track tables.
>
> I am fine with changing the LibrarySidebarExpanded only by the button
> bar. This avoids the mentioned flickering and allows the sorting to
> playlist use case as discussed earlier.
>
> A track table focus dependent change of the LibrarySidebarExpanded will
> IMHO not add any additional value to the use. The Breadcrumb and the
> search bar should be sufficient to indicate the table state.
>
>
> >
> > On 08/21/2016 03:43 PM, Daniel Schürmann wrote:
> >>
> >>
> >> Am 21.08.2016 um 22:33 schrieb Be:
> > * When focused, a feature's left pane is shown.
> > * Clicking feature icons always opens the feature in the focused
> right pane.
> 
>  I do not understand these suggestions. Is it different from my
> original
>  proposal?
> >>>
> >>> Yes. You suggested that the track table focus gets reset to the left
> >>> track table when a new feature is opened. I think that behavior would
> be
> >>> confusing. I propose that the focus only shifts when the user
> explicitly
> >>> decides to do so by clicking the new icon. Clicking a feature icon
> would
> >>> not affect where the focus is.
> >>
> >> Sorry for the confusion. I actually meant the same. Every icon has its
> >> own preselection pointing hand. If you preselect a pane, it is used for
> >> the next button bar click. After that the preselection is reset and no
> >> pane is preselected.
> >> A directly flowing click on the button bar will open a feature like it
> >> was seen before.
> >> This is required for a midi push knob with back button where you cannot
> >> preselect a pane.
> >>
> >>
> >>
> >> 
> --
> >> ___
> >> 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] Left library pane selection

[Ferran Pujol Camins]

I think it is a good compromise. I would not complain about it. We can even
reuse the current focus indicator for this. We just have to add a button:
What you propose is essentially:
* Feature opens where focus is, but:
   * Focus is always reset to the first pane when a feature is selected
   * Focus is not set by clicking the pane, but with a dedicated button.

It'd work for me, because the "Feature opens where focus is" behavior is
there :)

2016-08-21 11:26 GMT+02:00 Daniel Schürmann :

> Hi,
>
> resuming all the design issues we had during the project. I seams the
> current solution is quite close to be "good".
>
> * It is (will be) controllable by Midi.
> * It looks polished
> * It supports the two main use-case which where the original reasons for
> the second pane, sorting track and AutoDJ-ing well.
>
> The only issue that the pane selection is unintuitive and different to
> that what might be learned from other app.
>
> Or is there something else?
>
> At one point in our design phase we have coupled the input focus with the
> pane selection. This seams to be a bad decision and the source of confusion.
>
> How about reverting it and replace it by a preselection icon at the right
> end of the breadcrumb. Somehow an inverse pin icon, which may look like a
> pointing down hand. (see attached)
>
> This should work according these rules:
> * A feature opens in the left pane (1) by default.
> * You can override this behaviour by preselecting the right pane (n) via
> setting the pointing hand.
> * After the feature is shown, the preselection is reset.
> * The pane association is stored, if no pane is preselected, the feature
> is shown where it was before.
> * we can enhance this feature by showing a temporary reselection icon when
> hovering the button bar.
>
> From this version, we can enhance this by tabs and pin icon if required.
>
> What do you think?
>
> Kind regards,
>
> Daniel
>
>
>
>
>
>
>
>
>
>
>
>
>
> Am 21.08.2016 um 02:23 schrieb Ferran Pujol Camins:
>
>>
>> 2016-08-21 2:04 GMT+02:00 Daniel Schürmann > <mailto:dasch...@mixxx.org>>:
>>
>>
>> Without the pin feature he can still loose the AutoDJ pane
>> association.
>> There is no way to prevent having the AutoDJ left or in a second Tab,
>> which is undesired in most cases.
>>
>>
>>
>> That's true, the "only one auto-dj feature open" restriction would have
>> to be removed, but this is something that should be done anyway.
>>
>> It is also true that the tab model is very difficult to manage with a
>> controller.
>>
>> So what about the simpler model nº 2) i proposed:
>>
>> 2. Right panes can be blocked (or pinned). A blocked right pane
>> can't get the focus so its feature can't change. This alone does not
>> solve the use cases that worried you, but if you add a third pane
>> that can be hidden/shown you can pin auto-dj there and you are good
>> to go.
>>
>>
>> With it you can always have auto-dj in the same place while I can get
>> "feature always opens where focus is". It is simpler so it should be
>> easier to map to controllers. What do you think?
>>
>> A solution would be to remove all the focus issues and introduce
>> independent selectors for each pane. We could put the button bar
>> into a flout menu and open it always directly left to the focused
>> pane.
>> Unfortunately such a model is hard to control by a Midi.
>>
>>
>> That could also work. It is a promising idea.
>>
>> Or we could open a feature always in the left pane and add a button
>> "Pin right" Or "Pin to new Tab" if you like.
>> Releasing the Pin will remove the tab then.
>>
>>
>> Or even always open features in new tabs that cannot change but can be
>> closed? Maybe the simplest model. I also like this.
>>
>>
>> By the way, we have discussed the same as "sticky views" which have
>> now become the saved searches. If you have a close look to it, you
>> will see that they are similar to your tabs. The save Icon does the
>> same as "open in a new Tab"
>>
>>
>> It's not exactly the same. Here we re talking about features, not search
>> queries.
>>
>
--
___
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] Left library pane selection

[Ferran Pujol Camins]

2016-08-21 2:04 GMT+02:00 Daniel Schürmann :

> Without the pin feature he can still loose the AutoDJ pane association.
> There is no way to prevent having the AutoDJ left or in a second Tab,
> which is undesired in most cases.
>


That's true, the "only one auto-dj feature open" restriction would have to
be removed, but this is something that should be done anyway.

It is also true that the tab model is very difficult to manage with a
controller.

So what about the simpler model nº 2) i proposed:

2. Right panes can be blocked (or pinned). A blocked right pane can't get
> the focus so its feature can't change. This alone does not solve the use
> cases that worried you, but if you add a third pane that can be
> hidden/shown you can pin auto-dj there and you are good to go.
>

With it you can always have auto-dj in the same place while I can get
"feature always opens where focus is". It is simpler so it should be easier
to map to controllers. What do you think?

A solution would be to remove all the focus issues and introduce
> independent selectors for each pane. We could put the button bar into a
> flout menu and open it always directly left to the focused pane.
> Unfortunately such a model is hard to control by a Midi.
>

That could also work. It is a promising idea.

Or we could open a feature always in the left pane and add a button
> "Pin right" Or "Pin to new Tab" if you like.
> Releasing the Pin will remove the tab then.
>

Or even always open features in new tabs that cannot change but can be
closed? Maybe the simplest model. I also like this.


By the way, we have discussed the same as "sticky views" which have now
> become the saved searches. If you have a close look to it, you will see
> that they are similar to your tabs. The save Icon does the same as "open in
> a new Tab"


It's not exactly the same. Here we re talking about features, not search
queries.
--
___
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] Left library pane selection

[Ferran Pujol Camins]

2016-08-21 1:04 GMT+02:00 Ferran Pujol Camins :

> It is not the same. Imagine you have Library in first right pane and
> AutoDj in the second left pane. Then you open a new tab on the second left
> pane (auto-dj tab gets hidden) and select another feature there. While
> auto-dj tab is hidden, no matter whatever you do, it remains there. And the
> only thing you have to do to bring it back where it was is to click its
> tab. That's the key point. It's similar to pin a pane, but since you have
> another tab on that pane you can reuse it.


Made a mistake: correct version :)


It is not the same. Imagine you have Library in first right pane and AutoDj
in the second right pane. Then you open a new tab on the second right  pane
(auto-dj tab gets hidden) and select another feature there. While auto-dj
tab is hidden, no matter what you do, auto-dj remains there. And the only
thing you have to do to bring it back where it was is to click its tab.
That's the key point. It's similar to pin a pane, but since you have
another tab on that pane you can reuse it.
--
___
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] Left library pane selection

[Ferran Pujol Camins]

>
> It sound like you are strongly supporting "A feature is opened in the
> focused tab without any exceptions" right?
> Since this is exactly what causes issues for my drunken eyes ;-)
>

Yes I am :)
What you want is to always have certain features at the same place.
Your way to guarantee this is: "if a feature gets hidden, make it appear
where it was". This is the root of the behaviors that annoy me :)

I truly believe there is a way to guarantee the same without the current
unintuitive behavior (yes, unintuitiveness might subjective here, but I bet
you a beer we'll get lots of complaints in our forum)

I assume you are thinking about a context menu item "open in a new Tab",
> right?
>

Yes. Or open a new tab and then select the desired feature.


> Than we will have n panes arranged in tabs, we have it somehow already
> since we are already supporting n panes. Not sure, but I think it is
> already a skin option. Instead of switching a tab, you could today collapse
> on pane by the splitter to simulate the tab behaviour.
> Interesting is the right click idea.
> "open in pane 1/2" could be a nice addition.
>

It is not the same. Imagine you have Library in first right pane and AutoDj
in the second left pane. Then you open a new tab on the second left pane
(auto-dj tab gets hidden) and select another feature there. While auto-dj
tab is hidden, no matter whatever you do, it remains there. And the only
thing you have to do to bring it back where it was is to click its tab.
That's the key point. It's similar to pin a pane, but since you have
another tab on that pane you can reuse it.

I think this covers your use case and fulfills your requirements. But it
can done with "new feature is always open where focus is", which is mine :)
Don't you agree?
--
___
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] Left library pane selection

[Ferran Pujol Camins]

I think the new model is a step backwards. It is totally unintuitive to me.

We'll have lots of users complaining either that they don't understand how
it works or that it is broken.

Users will have to learn how it works. The first time they'll open Mixxx,
they will understand nothing. And every time they'll want to open a feature
to an specific pane, they'll have to think how to do it. This is not a good
idea with low light and drunken eyes ;)

For me, the way to go to produce an easy interface that meets your goals is
either:

   1. Library right panes have tabs. A feature is always open in the
   current tab of the focused right pane. Tabs can be opened and closed like
   in a web browser, independently for each right pane.

   or:

   2. Right panes can be blocked (or pinned). A blocked right pane can't
   get the focus so its feature can't change. This alone does not solve the
   use cases that worried you, but if you add a third pane that can be
   hidden/shown you can pin auto-dj there and you are good to go.

2. and 1. are very similar, I think 1. is more general and the best
solution.


For the left pane selection issue, I think tabs are also the best solution.
Covers all use cases and is intuitive. All users are used to tabs.

2016-08-19 23:09 GMT+02:00 Daniel Schürmann :

> Hi Mixxx developers,
>
> Joan has just finished a new version of his "Library layout redesign" PR
> https://github.com/mixxxdj/mixxx/pull/991 which contains the fixes for
> the issues found in the first review and a prototype for an improved
> focus and pane selection schema.
>
> While preparing it, we have tested some different options how to select
> the pane for a selected feature. We have finally managed to meld the
> ideas an requirements down to a few rules.
>
> "Last pane restore feature":
> A feature opens, in the pane where is was last seen. (Feature hidden /
> First click on the button bar). If a feature is already shown, it uses
> the focused pane (Feature visible / First click on the button bar)
>
> This means:
> If the focus has changed after the fist click on the button bar, the
> second click opens a new track table in the focused pane. If the feature
> allows only one pane like AutoDJ, the pane left and right panes are
> swapped.
>
> This behaviour fits exactly for the two main use cases for a two track
> table view:
>
> * AutoDJ supported DJing.
> By default the AutoDJ track table is shown right. All other features are
> shown left. Now you can switch features
> as you like, without caring about the focused pane. AutoDJ sticks always
> in sight in the right pane. No pane will move unless you enable an
> enabled feature again.
>
> * Sorting tracks to Playlist / crates / AutoDJ from Library.
> By default the library feature is enabled with a track table left.
> The AutoDJ track table is on the right.
> Focus the right pane; enable library feature again; Left and right panes
> are swapped.
> Now you can switch the desired drop target features as you like, without
> caring about the focused pane. The Library table sticks in the right pane.
>
>
> The current version of the "Library layout redesign" PR works almost
> like that. We want to receive your feedback to know if it is worth to
> clean ups the code to release quality and fix remaining issues.
>
> Does it work for your use cases as well?
> Do we need additional controls or preference options to control the
> behaviour? Pros and cons 
>
> Thank you for your help!
>
>
> Kind regards,
>
> Daniel
>
>
>
>
>
>
>
>
>
>
>
> Am 19.08.2016 um 22:20 schrieb Daniel Schürmann:
> > Hi Ferran,
> >
> > Joan and me have discussed the model some time ago. But we have
> > discarded the idea, because it somehow duplicates the button bar as
> > Tabs. The tabs are somehow a button bar horizontal, but horizontal space
> > it rar.
> >
> > But the underlying behaviour is interesting, treat the button bar as
> > vertical tabs.
> > This fits somehow to the schema, to control the panes content by the
> > button bar and not vice versa. A left to right control flow.
> >
> > I will introduce our ideas it in a separate Mail.
> >
> > Kind regards,
> >
> > Daniel
> >
> >
> >
> > Am 19.08.2016 um 11:36 schrieb Ferran Pujol Camins:
> >> What about tabs for the left pane? One tab for each distinct feature
> >> open in a right pane. Similar to tabs in a web browser. Then, controls
> >> to cycle through the different features' left pane would provide an easy
> >> way to handle this from a controller. Plus it works well with n > 2
> >> right panes

Re: [Mixxx-devel] Left library pane selection

[Ferran Pujol Camins]

What about tabs for the left pane? One tab for each distinct feature open
in a right pane. Similar to tabs in a web browser. Then, controls to cycle
through the different features' left pane would provide an easy way to
handle this from a controller. Plus it works well with n > 2 right panes.

2016-08-15 22:50 GMT+02:00 Daniel Schürmann :

> Yes, that's the other issue. Do you have an idea how to fix it?
> An pin Icon for the tree view pane?
>
>
> Am 15.08.2016 um 22:04 schrieb Be:
> > We also have the related question of how to control which feature's left
> > pane appears. It seems there are two design goals:
> >
> > 1. Dragging a track from a right pane to a different feature's left pane
> > should be easy. The most prominent use case for this is sorting many
> > tracks into many crates.
> > 2. Selecting the left pane for a feature with an open right pane should
> > be easy. An example use case is having Library and Auto DJ both open
> > with the Library tree on the left. It should be easy to access the Auto
> > DJ controls in Auto DJ's left pane from this situation.
> >
> > Currently, the most obvious way for a user to drag a track from a right
> > pane to a different feature's left pane (#1) is:
> > * Click the feature icon corresponding to the right pane with the
> > desired item to drag (for example, a track in Library).
> > * Focus the other right pane.
> > * Click the feature icon that has the left pane with desired drop target
> > (for example, a crate in the Crates tree). This has the side effect of
> > opening the feature's right pane as well.
> > * Drag and drop easily between left & right.
> > * When a different left pane is desired, click the corresponding feature
> > icon.
> >
> > This works well for design goal #1 but does not accomplish design goal
> > #2. The most intuitive way to accomplish design goal #2 would be to open
> > the left pane for a feature when its corresponding right pane is
> > focused. Currently, users must click the feature icon for the feature
> > with the left pane they want to access.
> >
> > This creates a confusing situation because clicking the feature icons
> > has two different purposes: opening a left & right pane for a feature
> > that is not open, plus opening a left pane for a feature that already
> > has a right pane open. This is especially a problem for unstickied
> > features (currently only Crates and Playlists) because the user has to
> > be careful to focus the right pane that already has that feature open
> > before clicking the feature icon. Otherwise, clicking the feature icon
> > will open the desired left pane but also open the undesired right pane
> > where the focus currently is, hiding a right feature pane the user may
> > have wanted to keep open.
> >
> > However, the obvious way for accomplishing design goal #2 (opening the
> > left pane for a feature when its right pane is focused) would make the
> > steps outlined above for design goal #1 impossible. There already is
> > another way to drag & drop many tracks between many crates (#1) though:
> >
> > * Click the feature icon corresponding to the right pane with the
> > desired item to drag (for example, a track in Library).
> > * Drag a track from the right pane
> > * Hover cursor over feature icon for the feature that has the left pane
> > with the desired drop target (for example, Crates list)
> > * Desired left pane opens, mouse can be released onto drop target
> >
> > If the user clicks again on a new item in the right pane, the left pane
> > that opened by hovering the cursor for the first drag & drop operation
> > stays open. The focus has not shifted between the two right panes. This
> > makes it easy to do many more drag & drop operations without having to
> > hover over a feature icon every time. The problem is that this is not
> > easily discoverable. However, I doubt this is something that many users
> > will want to do live or even every day. So, I think it will be okay as
> > long as this way of dragging & dropping many tracks is documented in the
> > manual.
> >
> > On 08/15/2016 11:55 AM, Daniel Schürmann wrote:
> >> Hi Mixxx developers
> >>
> >> During the review of the library redesign branch, we discovered a design
> >> issue about how to select where a track table of a feature is shown.
> >> https://github.com/mixxxdj/mixxx/pull/991
> >>
> >> Basically there are two valid requirements that at somehow incompatible.
> >>
> >> 1. A feature track table should re-appear where it was before. It turns
> >> out in live test, that undesired panes swapping is annoying, especially
> >> late at night.
> >>
> >> 2. User expect, that a track table appears in the focused pane. This
> >> allows to intuitive arrange the desired panes side by side. It is a
> >> known paradigm from two panes file manager like Nemo.
> >>
> >> In the current implementation we have tried to predict what is the best
> >> behaviour. Unfortunately it suffers some pending issues. And even if
> >> they are solved,

Re: [Mixxx-devel] Focus two library panes

[Ferran Pujol Camins]

> Why not having two feature list, one on the left as it is actually to
switch the left pane, and one on the right to switch le right pane ?

That is not possible with n>2 panes.

I like the pin idea as Daniel described. We have to be careful on how to
implement the pane pinning though. Two approaches:
1) Prevent a pinned pane from getting the focus, so its feature can't be
changed.
2) Allow a pinned pane to get the focus anyway, but don't allow it to
change its feature.

2) is the way to go, because with 1) this would happen :

* User pins right pane (focus is moved to the left pane)
* User keeps djing for a while.
* User selects right pane because he wants to change it but forgot that it
is pinned (focus keeps on left pane because right pane is pinned)
* User selects a fea
Outcome: Right pane still displays the pinned feature and left pane
changed. User wanted to do exactly the opposite.

Also, 2) will work better with the "tree pane follows focus" issue as
discussed in the other mail thread.

> I know that this does not fullfil my original requirement. It is less
smart, end requires some more clicks for some use cases but at least they
are there.

Remember that we can add a third hiddable pane. You could pin auto-dj there
and show/hide it on demand. Would this better accommodate your needs?

Another possibility: Panes have tabs. A tab can be created/deleted (much
like web browsers). You can then pin a feature to a new tab do you can
quickly switch to it in a specific pane. The drawback to this is that tabs
somehow duplicate what feature list does.

> I have also thought about a right click menu "open in the left pane"
but that is hard to discover.

This is something useful we want to add. But I agree that it's hard to
discover, so we can't rely on it as the only way to solve this issue.

> I think we have to rethink this topic again

I think we are converging to a good design! :)
--
___
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] ComboBox widget tag

[Ferran Pujol Camins]

Right now it is only used to determine the number of states. Am I wrong?

2016-08-14 18:46 GMT+02:00 S.Brandt :

>
>
> > On 14.08.2016, at 17:08, Ferran Pujol Camins <
> ferranpujolcam...@gmail.com> wrote:
> >
> > What does the  tag of the combo box widget do? If it is missing
> a skin error is thrown. However, I cannot see how does this tag effect the
> behavior of the widget.
> >
>
> Hi,
> should be the number of selectable items in a combobox.
>
> 
>  
>1
>Text A
>
>  
>  
>[DeckLayout],10
>  
>  
>2
>Text B
>
>
>  [DeckLayout],20
>
>  
>  
>3
>Text C
>
>
>  [DeckLayout],30
>
>  
> 
>
> In this example, we draw a combobox with 3 selectable items, with ``Text
> A`` being the default visible items.
> The items are here connected to a (fictional) [DeckLayout] widgetstack,
> which potentially allows to switch between different deck layouts.
>
>  is optional , relative to the skin path, e,g,
> ``image/foo.png``. Draws an image in front of the items text.
>
>
> Hope it helps,
> jus
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
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

[Mixxx-devel] ComboBox widget tag

[Ferran Pujol Camins]

What does the  tag of the combo box widget do? If it is missing a
skin error is thrown. However, I cannot see how does this tag effect the
behavior of the widget.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. http://sdm.link/zohodev2dev___
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] Multiple language keyboard mapping

[Ferran Pujol Camins]

(Sorry about my previous message, I misunderstood what was going on).

Maybe this key translation thing is a little bit overcomplicated? Isn't it
better to just let the mapping creator do the job? If a mapping does not
explicitly define shortcuts for a layout, just don't do nothing. It is more
work for the mapping creator to support all layouts, but it is simpler to
understand.

2016-06-25 20:20 GMT+02:00 Jordi Ortolá Ankum :

> Oh, dead keys. Of course..
>
> Storing a mapped key, alongside with it's keyboard layout seems to me like
> a good plan. Also, overloading a key sequence to target a specific keyboard
> layout seems great to me, especially for dead keys.
>
> If I understand you correctly, for the XML it would be like this, right?
>
> On a de_DE keyboard layout, this will be translated to 'z', because of the
> z and y being switched for German keyboards.
> y
>
> In this case, on a de_DE keyboard layout, it will go and find a "de_DE"
> keyseq. So, no need for translating.
> `
> q
>
> But what if a user opens the keymapping GUI (when the GUI is done) and
> assigns an action to a key that is not a dead key on his keyboard layout,
> but is on an other keyboard layout? I think that in that case, we should
> warn the user: "Warning: the pressed shortcut combination: `, will not work
> for keyboard layouts: de_DE".
>
> Any other thoughts on this? If not, I think I can begin with the
> implementation :-)
>
> Best,
> Jordi
>
> --
> Date: Sat, 25 Jun 2016 15:09:25 +0200
> Subject: RE: [Mixxx-devel] Multiple language keyboard mapping
> From: dasch...@mixxx.org
> To: jordi...@hotmail.com
> CC: mixxx-devel@lists.sourceforge.net; bzk0...@aol.com
>
>
> Cool, it sounds like we are getting close.
>
> Unfortunately a pure position depended papping will not work, because of
> dead keys. On a German keyboard for instance there are some keys like the
> "ˆ" which are stored inside the OS until the next key is pressed. They are
> transfered as a complete character "â" in case of a consecutive "a".
>
> How about this.
> * Store the mapped key along with it's keyboard layout.
> * Allow to add additional keys for other layouts.
>
> If a key event arrives and there is a mapping for the key and it's layout,
> use it.
> If not, translate the key back to the position and forth to the primary
> keyboard layout, used to create the mapping.
>
> For example: The user selects the default en-US mapping. If he switches to
> a de-DE keyboard. All keys are translated to en-US, Y becomes Z. We are
> able to move mappings on dead keys to other locations by adding dedicated
> de-DE keys to the mapping. This is required for the en-US "’" key which is
> the de-DE dead key "ˆ".
>
> What do you think about it?
> Am 25.06.2016 1:50 nachm. schrieb "Jordi Ortolá Ankum" <
> jordi...@hotmail.com>:
>
> Hi all,
>
> @Patric For some reason, your mail didn't show up at my inbox in outlook
> at all, not even in my spam box.
> @Daniel: Thanks for replying, so that I can read it now.
>
> If we only had access to the key scancode, it would be perfect. But as
> Daniel already pointed out, we can't.. :/ Qt does provide a method that
> gets the job done: QKeyEvent::nativeScanCode(), but unfortunately it
> doesn't work for OSX, because there is no way to get the scan code from
> Carbon or Cocoa.
>
> So, since the position info of the key is lost, I think that it will be
> tricky to support custom keyboard layouts. However, we do have access to
> the current input locale. So, we could maybe make a lookup-table which will
> tell what the key position is for a certain key, for a certain keyboard
> layout.
>
> For example:
> getKeyPosition(key, currentLocale);
>
> getKeyPosition('q', "en_US") // will return position 17 (French keyboards
> have the Q and the A switched)
> getKeyPosition('a', "fr_FR")   // will return position 17
>
> https://www.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.keyboardtechref/doc/kybdtech/figures/kybdt1.jpg
>
> This way we could have just one keyboard preset, based on keyboard
> positions (or en_US shortcuts?). If we ever wanted to support more keyboard
> layouts, we would only have to update the lookup table used by
> getKeyPosition(), and wouldn't have to update the keyboard presets.
>
> I don't know how the implementation would be yet, and I am not sure if
> it's possible 100%, but it seems logical. What do you think?
>
> Kind regards,
> Jordi
>
>
>
>
>
> --
> From: dasch...@mixxx.org
> Date: Sat, 25 Jun 2016 11:18:48 +0200
> To: bzk0...@aol.com
> CC: mixxx-devel@lists.sourceforge.net
> Subject: Re: [Mixxx-devel] Multiple language keyboard mapping
>
> Hi Patric,
>
> Your mail was rated as spam from my Gmail.
>
> @all: see Patric's original mail below.
>
> Mixxx can read the selected Keyboard layout form the OS independent from
> other local settings.
>
> Mixxx should provide a default keyboard mapping that works out of the box
> for almost all users,
> without swapping 

Re: [Mixxx-devel] scons clean

[Ferran Pujol Camins]

I see, thank you.

2016-06-25 18:40 GMT+02:00 RJ Ryan :

> Nope: https://bugs.launchpad.net/mixxx/+bug/1164051
>
> Just a little thing nobody has ever taken the time to fix :).
>
> On Sat, Jun 25, 2016 at 4:08 AM, Ferran Pujol Camins <
> ferranpujolcam...@gmail.com> wrote:
>
>> I can't perform scons -c if I have unmet dependencies. Is this expected
>> behaviour?
>>
>>
>> --
>> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
>> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
>> present their vision of the future. This family event has something for
>> everyone, including kids. Get more information and register today.
>> http://sdm.link/attshape
>> ___
>> 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
>>
>
>
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
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

[Mixxx-devel] scons clean

[Ferran Pujol Camins]

I can't perform scons -c if I have unmet dependencies. Is this expected
behaviour?
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
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] Multiple language keyboard mapping

[Ferran Pujol Camins]

What about treating different keyboard layouts as different controllers? So
a users would only see mappings corresponding to their layout.

2016-06-23 0:47 GMT+02:00 Daniel Schürmann :

> Hi Jordi,
>
> great! This would fix:
> https://bugs.launchpad.net/mixxx/+bug/997811
>
> Kind regards,
>
> Daniel
>
> Am 23.06.2016 um 00:15 schrieb Jordi Ortolá Ankum:
> > Hi folks!
> >
> > Now that I am working on the Keyboard Controller
> >  I am re-implementing all
> > aspects of the keyboard, but in the form of a controller. One of those
> > aspects is supporting multiple keyboard layouts for different languages
> > and choosing the right one depending on the current locale.
> >
> > Currently we have 12 different files, one file per keyboard layout
> > (en_US.kbd.cfg, es_ES.kbd.cfg, etc), from which one is loaded in while
> > booting Mixxx (if custom mapping isn't found). But now, if the keyboard
> > is a controller and is listed under "preferences -> controllers", it is
> > suddenly possible to change keyboard mapping (KeyboardControllerPresets)
> > at runtime by clicking on the preset dropdown menu.
> >
> > Now here is the thing. If we keep having one file per language, that
> > means that me, having a en_US keyboard layout, I will also get the
> > russian keyboard layout listed as an option. As a user I shouldn't be
> > amused (no offense to the Russians ^^, the same goes for other foreign
> > layouts), especially considering that I just wanted to go and choose the
> > default mapping. /But oh, wait.. there are 12 default mapping presets?/
> >
> > I would say that if those 12 different presets, which actually represent
> > the same mapping, where just in one file: Default.kbd.xml, that would be
> > a lot clearer. I propose to make the new keyboard presets multi-language
> > compatible and ship just one file, containing default mappings for all
> > languages. When the user selects a preset and the XML is parsed, it
> > would only load in the mapping for the current local keyboard layout or
> > default to en_US if the selected preset doesn't support your layout. If
> > the keyboard layout was changed at runtime, the keyboard controller
> > would go and see if the current preset has mappings for the new keyboard
> > layout, and if found, load them in.
> >
> > What do you think?
> >
> > --Jordi
> >
> >
> >
> --
> > Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> > Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> > present their vision of the future. This family event has something for
> > everyone, including kids. Get more information and register today.
> > http://sdm.link/attshape
> >
> >
> >
> > ___
> > 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
> >
>
>
> --
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> ___
> 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
>
--
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape___
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] mapping for playing samples

[Ferran Pujol Camins]

Hello Ron,
Did you check out
https://www.mixxx.org/manual/latest/chapters/advanced_topics.html#making-a-custom-keyboard-mapping

Hope it helps
El dia 04/06/2016 4:32 p. m., "ron camron"  va
escriure:

> I believe I tried contacting the forum but got no response so i'm
> asking here.  Is it possible to map in hotkeys for the sampler decks
> and/or a 4 deck mix mode configuration for mixxx? using keyboard only.
> I have found a set of accessibility qt files that has allowed me to
> successfully work with playlists, crates, even use the search feature
> within the program itself successfully. However when I load a file to
> the sampler decks I can't play them.  I tried typing in to the text
> file the way I found most of the commands in that particular file are
> laid out but no joy.  for example I typed:
> "[Sampler1]
> Play NumPad1
> hotcue_1_Activate Shift+Numpad+1"
>
> etc.
> All in a bid to use more and more features. Would like some help if
> possible please.
>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> 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
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
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] Library Layout Redesign [Wiki]

[Ferran Pujol Camins]

>
> Full Tree: I think we do not nee the legacy full tree, we need a tree of
> all drop targets, right? The crates and playlist tree should be sufficient.
>

Agree, but Autodj playlist is also a relevant drop target.


A full tree node, on every left pane breaks somehow the ButtoBar + Fetaure
> Idea.
> How can we combine both?
>
> How about move this Full Tree node as button to the button bar. This could
> be a special feature without a right pane.
>

I don't feel the button that makes the full tree appear should belong to
the button bar, because it is not a feature by itself. Creates, playlists
and autodj already have they own features. Maybe this button could be
placed at the bottom of the left pane (first picture). Then if the button
is pressed, the tree (playlists, crates and autodj list) appears and stays
there until the button is pressed again (second picture). If the button is
hovered while dragging tracks, the tree appears but hides when the drop is
done.

How do you feel about this?


​



​




>
> I want to remark that is quite important to allow users to configure the
> new library to look similar to current one (one single pane + complete
> tree). Feature specific tree + collapsable complete tree would also work
> for me.
>
>
> I am not sure if I missed a point, why it is required to keep a view that
> look similar to current one. Is there an other use case we have missed?
>

Forget that, as long as you provide quick access to all relevant drop
targets and allow to only display one feature this would be ok for me.


Another thing you might want to think about is how this will affect the
drag and drop of tracks from OS file explorer. I'm not sure how this works
now, but you can add tracks to the library by dragging them from outside
Mixxx right? For every feature on the button bar, you might want to think
what will happen when an external track is dragged with that feature open.
What about when two features are open at the same time?

Hope this helps you to improve the project definition :)
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
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] Library Layout Redesign [Wiki]

[Ferran Pujol Camins]

>
> The second way is the "Copy to Context menu". Unfortunately the menu
> vanishes after the copy. Conclusion: Not easy.
>
Why is this "not easy"?



> How about adding a root node to the Crates and  Playlist Feature that
> displays the All tracks? That would allow dragging any track to any Crate
> /Playlist.


1) This doesn't allow users to add tracks from playlist to crates.

2) Maybe the user is looking at the auto-dj queue and thinks "this track is
totally hot, I should add it to the Hits crate". He can't because from the
auto-dj pane he can't access the playlist tree. For me this is not a
solution.

once we have a Crate hierarchies, it could be as hard to drop to one from
> 100 crates. This cam be solved ba a Bookmark feature that contains only a
> few relevant Crates.
>
What do you think? Any other idea?
>
Keep showing the whole tree of features in every pane: Show the tree
corresponding to the current pane. Add an additional node, collapsed by
default that shows the whole tree. Something like this:

-Crate 1
-Crate 2
---Sub Crate 2.1
-Crate 3
-Full Tree
---...


Isn't this a simple but effective solution?


I want to remark that is quite important to allow users to configure the
new library to look similar to current one (one single pane + complete
tree). Feature specific tree + collapsable complete tree would also work
for me.
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
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] Library Layout Redesign [Wiki]

[Ferran Pujol Camins]

1) Will users be able to configure the library to look exactly like it does
now? I mean, single list with the complete tree on the left.

My concern is: As far as I can understand, the only way to drag a song to a
playlist will be with two opened panes, because the playlist tree will only
be shown with the playlist pane open. Isn't it?

2016-06-03 16:43 GMT+02:00 Joan Marcè i Igual :

>
> I'd like to push back on this a little bit just to see whether it can be
>> made more general.
>>
>> Why hard-code any orientations into this? And why 2 panes instead of N?
>>
> Yes it will be N panes (maybe it's not well explained) but for simplicity
> I only created the examples with 2 pane. There will be only 2 panes for
> each feature (left and right pane) but there can be up to N right pane
> containers.
>
>
>>
>> What if a skin author wanted a "top" and "bottom" frame? Or 3 frames? Or
>> only 1 frame?
>>
>>  Although it has the names left pane and right pane it has nothing to do
> with orientation, there will be the skin elements *LibraryLeftPane *and
> *LibraryRightPane* that can be declared anywhere, and the
> *LibraryRightPane* can be declared N times to allow the skin designer to
> have as many right panes as he/she wants.
>
>
>> Maybe instead of coding specific orientations, we just keep a list of
>> available panes and then the logic for considering which pane to load a
>> library feature's view into can consider the least recently used pane (or
>> whatever the scheme is for loading views to panes)?
>>
>> BTW, maybe I missed it -- but how will the user choose which pane to load
>> a sidebar item into? Is it automatic or a specific choice by the user (i.e.
>> dragging an item from the sidebar into a pane).
>>
>> Is automatic, when the user has a pane container focused and clicks to
> load a feature in the button bar the feature is loaded in the current
> focused pane container. With this it should be very evident to the user
> which is the current focused pane to avoid confusion. Even so I like the
> dragging idea and if there's enough time I'll add it.
>
> Could you add some actual skin XML examples for various configurations?
>> i.e. maybe an example of how to skin each of your example mock ups and then
>> an example of how to do a completely different mockup (i.e. with the
>> sidebar on the top?).
>>
> I'll add it as soon as possible
>
>
>> In the updated diagram, it looks like LibraryPaneManager creates two
>> WLibrarys -- but in the skin logic, there is no way to constrain the skin
>> author on how many WLibrary widgets to create -- so I'm just curious how
>> that would look in skin.xml such that you can still style/position each
>> widget individually, etc. Does LibraryPaneManager get access to WLibrary
>> through a bindWidget process similar to how the Library class does today?
>> (Is LibraryPaneManager in the "frontend" or the "backend" under this
>> design?)
>>
>> It is the *LegacySkinParser* the one who creates the two *WLibrarys and 
>> *there
> will be two different *WLibrarys* for each *LibraryPaneManager.*  One
> will be the right pane and the other for the left. Every
> *LibraryPaneManager* will always have this two widgets but the *WLibrary* 
> dedicated
> to the left pane of every *LibraryPaneManager* will be put in one stacked
> widget with the other left widgets of other *LibraryPaneManagers* so,
> when a user focuses one pane it's easy to show the left pane of the focused
> right pane container.
> And with this the LibraryPane is a very frontend element. However, it
> relies absolutely on the LibraryFeature interface that does all the backend
> tasks.
>
> I will be waiting for your answer,
> Joan
>
>>
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
> ___
> 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
>
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing lis

Re: [Mixxx-devel] Keyboard Mapping GUI

[Ferran Pujol Camins]

Hello, since Jordi is bringing the keyboard into the controller system, I
expect scripting will be straightforward to get. :)
El dia 19/05/2016 3:23 p. m., "Jordi Ortolá Ankum" 
va escriure:

> It turns out that your reply went straight into the spam-folder in my
> outlook
> account, so I didn't read it till just a moment ago, sorry!
>
> The GSoC is from May 23th till August 27th, so that gives me three months.
> The aim is to firstly focus on implementing the keyboard controller, in
> the first
> six weeks. Adding support for scripting looks to me like an important
> feature,
> regarding it's a controller. So I will certainly look into that :) The
> second half of
> the summer, after the midterm evaluation that is, I will be focusing on
> making
> the GUI for the newly created controller.
>
> As I am having an increasing understanding of the Mixxx codebase, I have
> not a full grasp yet on how everything interacts. Could somebody indicate
> globally which code changes will be needed and potential which I couldn't
> be
> aware of yet?
>
> One of my mentors, Ferran Pujol, already made a work breakdown, but it's
> not completed yet:
>http://mixxx.org/wiki/doku.php/gsoc2016_keyboard_work_breakdown
>
> -Jordi
>
>
>
> > To: mixxx-devel@lists.sourceforge.net
> > From: b...@gmx.com
> > Date: Wed, 4 May 2016 11:16:45 -0500
> > Subject: Re: [Mixxx-devel] Keyboard Mapping GUI
> >
> > Great that someone is taking this up! :) Do you plan on adding support
> > for scripting the keyboard? I don't know if that would be beyond the
> > scope of what you can get done for GSoC. If someone implemented
> > https://bugs.launchpad.net/mixxx/+bug/374239 , then users would be able
> > to extend the functionality of controller mappings by using a few keys
> > on their keyboard to change the behavior of the controller.
> >
> > It would be great if you took up this:
> > https://bugs.launchpad.net/mixxx/+bug/1343112 . That would make Mixxx
> > more usable with just a keyboard.
> >
> > On 05/04/2016 10:50 AM, Jordi Ortolá Ankum wrote:
> > > Hi folks!
> > >
> > > My name is Jordi Ortolá, and this summer I will be developing a GUI for
> > > keyboard mapping as a part of the
> > > GSoC program. In order to make the GUI, I will make a new controller
> > > type: /keyboard,/ which will live alongside
> > > the current controller types: /HUD /and /MIDI/. The goal is to make it
> > > as easy as possible for the users to change
> > > keyboard mapping, without having to modify a /*.cfg/file and without
> > > having to restart Mixxx.
> > >
> > > The project abstract is found here:
> > > https://summerofcode.withgoogle.com/projects/#5540261090295808
> > >
> > >
> > >
> --
> > > Find and fix application performance issues faster with Applications
> Manager
> > > Applications Manager provides deep performance insights into multiple
> tiers of
> > > your business applications. It resolves application problems quickly
> and
> > > reduces your MTTR. Get your free trial!
> > > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > >
> > >
> > >
> > > ___
> > > 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
> > >
> >
> >
> --
> > Find and fix application performance issues faster with Applications
> Manager
> > Applications Manager provides deep performance insights into multiple
> tiers of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > ___
> > 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
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> 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
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devi

Re: [Mixxx-devel] Mixxx boot speed improvements

[Ferran Pujol Camins]

Wow! Thank you for the work and for the explanation. Nice.

2016-05-12 22:22 GMT+02:00 RJ Ryan :

> Spending a few days with a profiler I trimmed a lot of low hanging fruit
> from our bootup process. On my laptop (well-specced macbook) Mixxx
> previously booted into LateNight in 5.3 (+/- 1) seconds and now it takes
> 2.1 (+/- 0.2) seconds.
>
> Here're the dominant parts of how those 2.1 seconds are spent, roughly.
> The times I'm citing are samples from a profiler sampling at 40
> microseconds / sample -- not direct timing measurements so they are
> approximate.
>
> - 439ms The actual work of skin loading / parsing.
> (SkinLoader::loadDefaultSkin). This is a mix of file I/O, image decoding,
> malloc'ing our giant widget tree, Qt inefficiencies (style sheet
> computation before the skin is even shown) and SvgParser inefficiencies.
>
> - 680ms QFontDatabase::load. Mac-specific, I think. This happens
> regardless of whether we install our custom fonts. This happens once during
> QApplication construction and again the first time we create a widget that
> relies on font size information (e.g. a QGroupBox -- so any dialog). So
> this alone accounts for 30% of the startup time on my machine. WTF Qt. I
> believe this is fixed in Qt 5.
>
> - 108ms Creating the preferences dialog. (DlgPreferences::DlgPreferences)
>
> There's no reason to create the preferences dialog on bootup instead of
> when the user first requests it. Unfortunately, our Preference dialog
> actually performs a role in initializing the user state and setting up
> controls that tell the rest of Mixxx the user's current preferences. We
> should eliminate these so that we can create the preferences dialog on
> demand.
>
> - 102ms deck / microphone / aux / preview deck construction (PlayerManager
> methods).
>   -> Most of the time spent in these methods is creating ControlObjects.
> QObject::connect is a particular hotspot since we call it so much.
> QMetaObject::normalizedSignature shows up a lot here. On Qt 4.8 we can use
> QMetaMethod instead of const char* signal/slot names.
>   -> We spend 2ms per deck creating RubberBand.
>
> - 26ms Library creation (Library::Library)
>
> - 18ms WaveformWidgetFactory::WaveformWidgetFactory
>
> - 26ms EffectsManager::setupDefaults (almost all of this is creating
> Controls -- QObject::connect/QMetaObject::normalizedSignature features
> prominently)
>
> -13ms SoundManager creation and setupDevices (probably varies a lot based
> on your system -- I know ALSA can take a long time here).
>
> There's a lot of room for improvement here. This also provides strong
> motivation for pushing as much work as we can into separate threads. For
> example -- moving controller enumerators to the ControllerManager thread
> save 200ms on my machine (initializing CoreMIDI). Moving XML parsing of our
> ~100 presets into the CM thread was good for another ~130ms.
>
> I have a fix that uses QMetaMethod to connect signals in some specific
> hotspots that shaves another ~50ms off of engine creation and
> EffectsManager::setupDefaults but it only works on Qt 4.8 and greater.
>
> It's nice to have Mixxx bootup (sort of) quickly again!
>
>
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> 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
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j___
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] software main & headphone gain knobs and mapping guidelines

[Ferran Pujol Camins]

I see, thank you for explaining!


2016-04-07 0:43 GMT+02:00 Be :

> All sound cards work differently, but I don't think it matters whether the
> sound card has digital or analog gain. Either works better with a stronger
> signal coming in.
>
> My sound card has digital gains and meters on the device, so I can
> actually see whether the signal is at the same level to confirm this. I
> just experimented turning the main gain in Mixxx down with the sound card
> all the way up versus leaving the main gain knob at unity in Mixxx and
> turning down the sound card. The former definitely sounded worse than the
> latter.
>
> On 04/06/2016 05:19 PM, Ferran Pujol Camins wrote:
>
>> I understand, but isn't the OS mixer just decreasing or increasing the
>> volume digitally? In that case, if the OS mixer volume is 100% (no
>> volume modification) and mixxx gain is 30% is the same than Os mixer 30%
>> and mixxx 100%, am I wrong?
>>
>> 2016-04-07 0:13 GMT+02:00 Be mailto:b...@gmx.com>>:
>>
>> It's better to have Mixxx sending the sound card a signal with a
>> high signal-to-noise ratio than turn the gain down in Mixxx and send
>> a signal with a lower S/N ratio to the sound card. To reach a
>> comparable volume, the signal would have to be amplified somewhere
>> down the line (sound card, mixer, amplifier, or whatever), which
>> would amplify more noise. Or to turn the volume down, it would still
>> sound better to send a strong signal out of Mixxx and attenuate it
>> further down the signal chain.
>>
>>
>> http://mixxx.org/manual/latest/chapters/djing_with_mixxx.html#djing-gain-staging
>>
>> On 04/06/2016 05:02 PM, Ferran Pujol Camins wrote:
>>
>> But why is it better?
>>
>> 2016-04-06 23:59 GMT+02:00 Be > <mailto:b...@gmx.com> <mailto:b...@gmx.com <mailto:b...@gmx.com
>> >>>:
>>
>>
>>  The gain in Mixxx controls the signal that is sent to the
>> sound
>>  card. The OS mixer controls the sound card.
>>
>>  On 04/06/2016 04:57 PM, Ferran Pujol Camins wrote:
>>
>>  What's the difference between lowering the volume in
>> mixxx and
>>  in the OS
>>  mixer?
>>
>>  2016-04-06 23:43 GMT+02:00 Be > <mailto:b...@gmx.com>
>>  <mailto:b...@gmx.com <mailto:b...@gmx.com>>
>> <mailto:b...@gmx.com <mailto:b...@gmx.com> <mailto:b...@gmx.com
>> <mailto:b...@gmx.com>>>>:
>>
>>
>>
>>   I've been working on the wiki and reviewing
>> controller
>>  mappings lately.
>>   I did a little editing to the language of the DJ
>> Hardware Guide
>>
>>   (http://mixxx.org/wiki/doku.php/hardware_compatibility ),
>>  split the
>>   custom caps section to its own page, and revived
>> the old
>>  headphones
>>   section on its own page.
>>
>>   In reviewing mappings, it has become apparent that
>> there
>>  should be
>>   guidelines on how to handle main & headphone gain
>> knobs on
>>  controllers.
>>   I added a section to the Contributing Mappings page
>>
>>
>> (
>> http://mixxx.org/wiki/doku.php/contributing_mappings#main_headphone_gain_knobs
>>   ) with some guidelines and started a new page
>>
>>   (http://mixxx.org/wiki/doku.php/operating_system_mixer ) with
>>   information about adjusting sound card levels. It
>> would be
>>  great if
>>   others could contribute details and screenshots to
>> the new
>>  Operating
>>   System Mixer page.
>>
>>   Two cases that I'd like to ask about is when a
>> controller
>>  has a sound
>>   card without any gain controls or doesn't have a
>> sound card
>>  but does
>>   have main & headphone gain controls. In these
>> cases, shou

Re: [Mixxx-devel] software main & headphone gain knobs and mapping guidelines

[Ferran Pujol Camins]

I understand, but isn't the OS mixer just decreasing or increasing the
volume digitally? In that case, if the OS mixer volume is 100% (no volume
modification) and mixxx gain is 30% is the same than Os mixer 30% and mixxx
100%, am I wrong?

2016-04-07 0:13 GMT+02:00 Be :

> It's better to have Mixxx sending the sound card a signal with a high
> signal-to-noise ratio than turn the gain down in Mixxx and send a signal
> with a lower S/N ratio to the sound card. To reach a comparable volume, the
> signal would have to be amplified somewhere down the line (sound card,
> mixer, amplifier, or whatever), which would amplify more noise. Or to turn
> the volume down, it would still sound better to send a strong signal out of
> Mixxx and attenuate it further down the signal chain.
>
>
> http://mixxx.org/manual/latest/chapters/djing_with_mixxx.html#djing-gain-staging
>
> On 04/06/2016 05:02 PM, Ferran Pujol Camins wrote:
>
>> But why is it better?
>>
>> 2016-04-06 23:59 GMT+02:00 Be mailto:b...@gmx.com>>:
>>
>> The gain in Mixxx controls the signal that is sent to the sound
>> card. The OS mixer controls the sound card.
>>
>> On 04/06/2016 04:57 PM, Ferran Pujol Camins wrote:
>>
>> What's the difference between lowering the volume in mixxx and
>> in the OS
>> mixer?
>>
>> 2016-04-06 23:43 GMT+02:00 Be > <mailto:b...@gmx.com> <mailto:b...@gmx.com <mailto:b...@gmx.com
>> >>>:
>>
>>
>>
>>  I've been working on the wiki and reviewing controller
>> mappings lately.
>>  I did a little editing to the language of the DJ Hardware
>> Guide
>>  (http://mixxx.org/wiki/doku.php/hardware_compatibility ),
>> split the
>>  custom caps section to its own page, and revived the old
>> headphones
>>  section on its own page.
>>
>>  In reviewing mappings, it has become apparent that there
>> should be
>>  guidelines on how to handle main & headphone gain knobs on
>> controllers.
>>  I added a section to the Contributing Mappings page
>>
>> (
>> http://mixxx.org/wiki/doku.php/contributing_mappings#main_headphone_gain_knobs
>>  ) with some guidelines and started a new page
>>  (http://mixxx.org/wiki/doku.php/operating_system_mixer )
>> with
>>  information about adjusting sound card levels. It would be
>> great if
>>  others could contribute details and screenshots to the new
>> Operating
>>  System Mixer page.
>>
>>  Two cases that I'd like to ask about is when a controller
>> has a sound
>>  card without any gain controls or doesn't have a sound card
>> but does
>>  have main & headphone gain controls. In these cases, should
>> the controls
>>  be mapped to the software gains in Mixxx or not? If they
>> should be
>>  mapped, then I think the controller's wiki page should
>> advise users not
>>  to use them in most cases and link to the OS Mixer page.
>>
>>  I also split the Contributing Mappings page into smaller
>> sections and
>>  put a bit more context in the introduction. I added a
>> little section on
>>  documenting how microphone inputs work too.
>>
>>
>>
>> --
>>  ___
>>  Get Mixxx, the #1 Free MP3 DJ Mixing software Today
>> http://mixxx.org
>>
>>
>>  Mixxx-devel mailing list
>> Mixxx-devel@lists.sourceforge.net
>> <mailto:Mixxx-devel@lists.sourceforge.net>
>>  <mailto:Mixxx-devel@lists.sourceforge.net
>> <mailto:Mixxx-devel@lists.sourceforge.net>>
>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>>
>>
>>
>>
--
___
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] software main & headphone gain knobs and mapping guidelines

[Ferran Pujol Camins]

But why is it better?

2016-04-06 23:59 GMT+02:00 Be :

> The gain in Mixxx controls the signal that is sent to the sound card. The
> OS mixer controls the sound card.
>
> On 04/06/2016 04:57 PM, Ferran Pujol Camins wrote:
>
>> What's the difference between lowering the volume in mixxx and in the OS
>> mixer?
>>
>> 2016-04-06 23:43 GMT+02:00 Be mailto:b...@gmx.com>>:
>>
>>
>> I've been working on the wiki and reviewing controller mappings
>> lately.
>> I did a little editing to the language of the DJ Hardware Guide
>> (http://mixxx.org/wiki/doku.php/hardware_compatibility ), split the
>> custom caps section to its own page, and revived the old headphones
>> section on its own page.
>>
>> In reviewing mappings, it has become apparent that there should be
>> guidelines on how to handle main & headphone gain knobs on
>> controllers.
>> I added a section to the Contributing Mappings page
>> (
>> http://mixxx.org/wiki/doku.php/contributing_mappings#main_headphone_gain_knobs
>> ) with some guidelines and started a new page
>> (http://mixxx.org/wiki/doku.php/operating_system_mixer ) with
>> information about adjusting sound card levels. It would be great if
>> others could contribute details and screenshots to the new Operating
>> System Mixer page.
>>
>> Two cases that I'd like to ask about is when a controller has a sound
>> card without any gain controls or doesn't have a sound card but does
>> have main & headphone gain controls. In these cases, should the
>> controls
>> be mapped to the software gains in Mixxx or not? If they should be
>> mapped, then I think the controller's wiki page should advise users
>> not
>> to use them in most cases and link to the OS Mixer page.
>>
>> I also split the Contributing Mappings page into smaller sections and
>> put a bit more context in the introduction. I added a little section
>> on
>> documenting how microphone inputs work too.
>>
>>
>> --
>> ___
>> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
>> http://mixxx.org
>>
>>
>> Mixxx-devel mailing list
>> Mixxx-devel@lists.sourceforge.net
>> <mailto:Mixxx-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>>
>>
>>
--
___
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] software main & headphone gain knobs and mapping guidelines

[Ferran Pujol Camins]

What's the difference between lowering the volume in mixxx and in the OS
mixer?

2016-04-06 23:43 GMT+02:00 Be :

> I've been working on the wiki and reviewing controller mappings lately.
> I did a little editing to the language of the DJ Hardware Guide
> (http://mixxx.org/wiki/doku.php/hardware_compatibility ), split the
> custom caps section to its own page, and revived the old headphones
> section on its own page.
>
> In reviewing mappings, it has become apparent that there should be
> guidelines on how to handle main & headphone gain knobs on controllers.
> I added a section to the Contributing Mappings page
> (
> http://mixxx.org/wiki/doku.php/contributing_mappings#main_headphone_gain_knobs
> ) with some guidelines and started a new page
> (http://mixxx.org/wiki/doku.php/operating_system_mixer ) with
> information about adjusting sound card levels. It would be great if
> others could contribute details and screenshots to the new Operating
> System Mixer page.
>
> Two cases that I'd like to ask about is when a controller has a sound
> card without any gain controls or doesn't have a sound card but does
> have main & headphone gain controls. In these cases, should the controls
> be mapped to the software gains in Mixxx or not? If they should be
> mapped, then I think the controller's wiki page should advise users not
> to use them in most cases and link to the OS Mixer page.
>
> I also split the Contributing Mappings page into smaller sections and
> put a bit more context in the introduction. I added a little section on
> documenting how microphone inputs work too.
>
>
> --
> ___
> 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
>
--
___
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] CO list

[Ferran Pujol Camins]

How can it be I've never seen that button before? I need glasses.

Thank you Daniel.

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

> In 2.1 you are also able to export all cos including their current value
> to a csv file
> (the Truth). Start mixxx with ich the developer flag and you will find the
> button in the Co table.
> Am 24.03.2016 6:57 nachm. schrieb "Ferran Pujol Camins" <
> ferranpujolcam...@gmail.com>:
>
>> Wow, sorry for my poor research.
>>
>> Thank you Be.
>>
>> 2016-03-24 18:50 GMT+01:00 Be :
>>
>>> http://mixxx.org/wiki/doku.php/mixxxcontrols
>>>
>>> On 03/24/2016 12:37 PM, Ferran Pujol Camins wrote:
>>> > Hello,
>>> > is there a list of all the CO with a short description of what they do?
>>> >
>>> > 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=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
>>> >
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> --
>> 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
>>
>
--
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

Re: [Mixxx-devel] CO list

[Ferran Pujol Camins]

Wow, sorry for my poor research.

Thank you Be.

2016-03-24 18:50 GMT+01:00 Be :

> http://mixxx.org/wiki/doku.php/mixxxcontrols
>
> On 03/24/2016 12:37 PM, Ferran Pujol Camins wrote:
> > Hello,
> > is there a list of all the CO with a short description of what they do?
> >
> > 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=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
> >
>
>
> --
> 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
>
--
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

[Mixxx-devel] CO list

[Ferran Pujol Camins]

Hello,
is there a list of all the CO with a short description of what they do?

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

Re: [Mixxx-devel] GSoC 2016 GUI Revamp

[Ferran Pujol Camins]

Sir, your Nykto skin is just amazing! A nice looking skin like this will
certainly attract more Mixxx users.

I'm specially excited for the Reorderable widgets feature. Maybe in your
proposal you could discuss a possible extension or generalization of it:

1-Define drop zones where specific widgets can be dropped in. So for
example a user might drag the filter knob not only inside the mixer channel
but also drop it in a zone in the deck header.
2-Additional custom controls can be dropped by the user to those zones.
This additional controls could be tied to the scripting engine to allow
users to add custom functionality to Mixxx.

This I suggest is something big, you don't need to add this to your goals
but maybe you might want to discuss it briefly. Just an idea.

Best regards, Ferran.

2016-03-23 9:14 GMT+01:00 Сергей (zezic) :

> About compatibility:
> I think we just can add attribute to wanted WidgetGroups to enable
> children reorder functionality and leave old behaviour for WidgetGroups
> without that attribute so this feature should be compatible with all
> existing skins. I add this to proposal.
>
> About timeline: i need some time to learn how widget addition process in
> Mixxx skin engine works so approximately 2/5 of available time goes to
> learning this, 2/5 to actually coding and 1/5 to markup skin (because I can
> do this fast). I can write detailed plan.
>
> 23.03.2016, 10:41, "Tuukka Pasanen" :
> > Hello,
> > Ok now I got it. Are older skins going to be compatible with new engine
> > or do they need altering at least re-ordable widgets need some thought
> > in older skins.
> >
> > There is no timeline or needed resources etc.
> >
> > Tuukka
> >
> > 23.03.2016, 09:36, Сергей (zezic) kirjoitti:
> >>  I'm going to modify current GUI engine to suit needs in proposal
> starting at this section http://zezic.ru/mixxx#how and write completely
> new skin for it.
> >>
> >>  23.03.2016, 10:29, "Tuukka Pasanen" :
> >>>  Hello,
> >>>  Nice looking proposal. You are going to revamp whole GUI engine or
> write new one?
> >>>
> >>>  Tuukka
> >>>
> >>>  23.03.2016, 09:12, Сергей (zezic) kirjoitti:
> >>>
>   I write short document for my proposal: http://zezic.ru/mixxx
> 
>   May be it will be interesting for our mentors and somebody else.
> 
> 
>  
> --
> 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
> >>>  ,
> >>>
> >>>
>  
> --
> >>>  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
>
>
> --
> 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
>
--
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

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

[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&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
>
--
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

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

[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&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

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

[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&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

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

[Ferran Pujol Camins]

2016-03-22 17:44 GMT+01:00 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.


Yes! Every new control will have its corresponding CO created by Mixxx and
not the skins. This means they will be the same regardless of users' skin
choice and of course MIDI mapable :)


2016-03-22 17:47 GMT+01:00 Be :

> The proposal only mentioned dragging and dropping on the detail waveform.
> I am suggesting that the same functionality should be accessible on the
> overview waveform.
>

That's true, I'll add the same functionality for the overview. It's clearly
convenient to move a cue point a long distance.


Thank you for your observations.
--
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

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

[Ferran Pujol Camins]

2016-03-22 16:59 GMT+01:00 Be :

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


Y totally agree, that's what I had in mind.


2016-03-22 16:59 GMT+01:00 Be :

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


Nice idea! I'll also add the possibility to change the default colors in
the whislist (extra features).


2016-03-22 16:59 GMT+01:00 Be :

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

Didn't think about that. Totally agree. I'll add this to the proposal. I'll
think how to handle invalid times, like a loop with the end point before
the start point.


2016-03-22 16:59 GMT+01:00 Be :

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

I excluded this feature because it doesn't allow to move a cue point across
pages. Well it can be done by triggering a page change when a cue is
dragged over the page indicator. I'm ok with adding this to the wishlist.


2016-03-22 16:59 GMT+01:00 Be :

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

I'm not sure what you mean with that. Do you mean to move the position of a
cue point by dragging its waveform mark? If that is the case, that's what I
describe in *2.2.1 Draggable marks to move cue points*, maybe I did not
explain it clearly enough? I see I omitted the possibility to also drag in
the waveform overview besides the detail waveform, I'll include that.


2016-03-22 16:59 GMT+01:00 Be :

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

Sure! I'll also group them in a blueprint.

2016-03-22 16:59 GMT+01:00 Be :

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


I like this solution. But I will still leave this as an extra feature.
Although very useful, I feel that it's not core to the proposal and the
other features need to be implemented first.


Thank you both for your comments. I really feel they are on point and I
like the direction this is taking!
--
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

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

[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&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

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

[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&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
>>&

Re: [Mixxx-devel] Skin variable to choose color

[Ferran Pujol Camins]

Oh, It actually doesn't work either. I can however, place a variable and
static text inside a  for a label and it works as expected. Might be
that variables are not processed for  nodes?

2016-03-20 13:34 GMT+01:00 Ferran Pujol Camins <ferranpujolcam...@gmail.com>
:

> Oh, I thought it was supposed to work.
>
> Thank you for the help.
>
> 2016-03-20 0:12 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>:
>
>> Hi Ferran
>>
>> I guess the parser is not able to combine a static part + a variable.
>> Probably
>> <Style><Variable name="Color"/>
>> with:
>> background-color: #FF;
>> will work.
>>
>> I did not read the code though ...
>>
>> Kind regards,
>>
>> Daniel
>>
>>
>>
>>
>> Am 19.03.2016 um 20:47 schrieb Ferran Pujol Camins:
>>
>> Hello, I've made a template and I'd like to configure a color via a
>> variable. I've tried:
>> background-color: <Variable name="Color"/>;
>> But for some reason it doesn't work.
>>
>> If I change  for #FF it works. The variable
>> is correctly set because I can place a label that displays its content.
>>
>> What I am missing?
>>
>>
>> --
>> 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 Todayhttp://mixxx.org
>>
>>
>> Mixxx-devel mailing 
>> listMixxx-devel@lists.sourceforge.nethttps://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&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
>>
>
>
--
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

Re: [Mixxx-devel] Skin variable to choose color

[Ferran Pujol Camins]

Oh, I thought it was supposed to work.

Thank you for the help.

2016-03-20 0:12 GMT+01:00 Daniel Schürmann :

> Hi Ferran
>
> I guess the parser is not able to combine a static part + a variable.
> Probably
> <Variable name="Color"/>
> with:
> background-color: #FF;
> will work.
>
> I did not read the code though ...
>
> Kind regards,
>
> Daniel
>
>
>
>
> Am 19.03.2016 um 20:47 schrieb Ferran Pujol Camins:
>
> Hello, I've made a template and I'd like to configure a color via a
> variable. I've tried:
> background-color: <Variable name="Color"/>;
> But for some reason it doesn't work.
>
> If I change  for #FF it works. The variable is
> correctly set because I can place a label that displays its content.
>
> What I am missing?
>
>
> --
> 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 Todayhttp://mixxx.org
>
>
> Mixxx-devel mailing 
> listMixxx-devel@lists.sourceforge.nethttps://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&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
>
--
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

[Mixxx-devel] Skin variable to choose color

[Ferran Pujol Camins]

Hello, I've made a template and I'd like to configure a color via a
variable. I've tried:
background-color: ;
But for some reason it doesn't work.

If I change  for #FF it works. The variable is
correctly set because I can place a label that displays its content.

What I am missing?
--
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

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

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

> * 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 controller
> mappings as Daniel pointed out. Also, I think the workflow would be
> awkwar

Re: [Mixxx-devel] CO time resolution

[Ferran Pujol Camins]

I see, I will reflect that in the proposal and then we can further discuss
it.

Thanks for your input :)

2016-03-06 23:24 GMT+01:00 Daniel Schürmann :

> Yes, that is a good example, but it requires a lot more than just
> recording CO changes. How will Mixxx know how a random CO change compares
> to its internal state.
> Which state (Deck or Sampler state) changed state will trigger which
> CO state.
>
> How will the interface look like, to recode and recall such macros?
> Maybe some of similar tasks are requiring conditions similar to the break
> effect added in some controller scripts.
>
> A hand full more of these examples will be quite useful.
>
>
>
>
>
> Am 06.03.2016 um 22:50 schrieb Ferran Pujol Camins:
>
>> For example, a user could record himself setting a 4 bar loop and
>> successively halving it, a good known Dj trick. Then at the press of a
>> button this trick would automatically happen (macros will be time-scaled
>> to match different bpm). This is actually a requested feature:
>> https://bugs.launchpad.net/mixxx/+bug/1084352
>>
>> Aren't this kind of possibilities not appealing to you? Or I don't get
>> what you mean in your last sentence.
>>
>> Kind regards, Ferran.
>>
>> 2016-03-06 22:28 GMT+01:00 Daniel Schürmann > <mailto:dasch...@mixxx.org>>:
>>
>> Yes, right. A good solution will also work from the GUI.
>>
>> The idea was just that a midi file has already the capability to
>> store control commands along with timestamps. Since there is a
>> standard,
>> there are already third party apps and libraries we may re-use.
>> The sysex extensions offers the option to add Mixxx specific features.
>>
>> So it looks like form the techical point of view it looks like it
>> will work. If we find out it does not work or we hav not enough
>> benefits, it is also a good result. ;-)
>>
>> If we compare a possible Mixxx macro recording with lets say Open
>> Office Calc, there is an important difference: The real timing.
>>
>> So IMHO the use cases are not obvious. It is important to define
>> some good common use cases, that we have a good reference we can
>> compare our ideas against. That is probably one of the hardest part
>> of your project idea.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Am 06.03.2016 um 20:17 schrieb Ferran Pujol Camins:
>>
>> Also, I feel we should not think in terms of recording MIDI, but
>> recording CO changes. This way users using the GUI can also
>> record macros.
>>
>> 2016-03-06 20:15 GMT+01:00 Ferran Pujol Camins
>> > <mailto:ferranpujolcam...@gmail.com>
>> <mailto:ferranpujolcam...@gmail.com
>> <mailto:ferranpujolcam...@gmail.com>>>:
>>
>>  Yes, the raw recorded data is a linear representation. The
>> idea is
>>  to reduce the number of data points by interpolating the
>> data with
>>  cubic curves, sort of a simplification of the data (as seen
>> in the
>>  drawing of my previous mail).
>>
>>  Do you feel macro recording only appeals to a minority of
>> users? I
>>  think it's pretty impressive. And as I already explained,
>> other cool
>>  features (like your auto-dj sequencer) can be built from
>> it. This
>>  interpolation thing is only a part of what needs to be
>> done, but I
>>  really feel it is needed if we want our users to edit
>> recorded
>>  sequences.
>>
>>  I appreciate your feedback!
>>
>>  2016-03-06 20:05 GMT+01:00 Daniel Schürmann
>> mailto:dasch...@mixxx.org>
>>  <mailto:dasch...@mixxx.org <mailto:dasch...@mixxx.org>>>:
>>
>>
>>  Ah yes macro recording will be a cool feature.
>>  I habe not yet understood how you will be able to record
>> a
>>  becubic curve.
>>  The result will be always a linear representation from
>> audio
>>  callback to audio callback.
>>  It may send to have a abstract editor that converts a
>> cubic
>>  curve to a row of linear changes quantisiced by the
>> size of the
>>  audio buffer

Re: [Mixxx-devel] CO time resolution

[Ferran Pujol Camins]

For example, a user could record himself setting a 4 bar loop and
successively halving it, a good known Dj trick. Then at the press of a
button this trick would automatically happen (macros will be time-scaled to
match different bpm). This is actually a requested feature:
https://bugs.launchpad.net/mixxx/+bug/1084352

Aren't this kind of possibilities not appealing to you? Or I don't get what
you mean in your last sentence.

Kind regards, Ferran.

2016-03-06 22:28 GMT+01:00 Daniel Schürmann :

> Yes, right. A good solution will also work from the GUI.
>
> The idea was just that a midi file has already the capability to store
> control commands along with timestamps. Since there is a standard,
> there are already third party apps and libraries we may re-use.
> The sysex extensions offers the option to add Mixxx specific features.
>
> So it looks like form the techical point of view it looks like it will
> work. If we find out it does not work or we hav not enough benefits, it is
> also a good result. ;-)
>
> If we compare a possible Mixxx macro recording with lets say Open Office
> Calc, there is an important difference: The real timing.
>
> So IMHO the use cases are not obvious. It is important to define some good
> common use cases, that we have a good reference we can compare our ideas
> against. That is probably one of the hardest part of your project idea.
>
>
>
>
>
>
>
>
>
>
> Am 06.03.2016 um 20:17 schrieb Ferran Pujol Camins:
>
>> Also, I feel we should not think in terms of recording MIDI, but
>> recording CO changes. This way users using the GUI can also record macros.
>>
>> 2016-03-06 20:15 GMT+01:00 Ferran Pujol Camins
>> mailto:ferranpujolcam...@gmail.com>>:
>>
>> Yes, the raw recorded data is a linear representation. The idea is
>> to reduce the number of data points by interpolating the data with
>> cubic curves, sort of a simplification of the data (as seen in the
>> drawing of my previous mail).
>>
>> Do you feel macro recording only appeals to a minority of users? I
>> think it's pretty impressive. And as I already explained, other cool
>> features (like your auto-dj sequencer) can be built from it. This
>> interpolation thing is only a part of what needs to be done, but I
>> really feel it is needed if we want our users to edit recorded
>> sequences.
>>
>> I appreciate your feedback!
>>
>> 2016-03-06 20:05 GMT+01:00 Daniel Schürmann > <mailto:dasch...@mixxx.org>>:
>>
>> Ah yes macro recording will be a cool feature.
>> I habe not yet understood how you will be able to record a
>> becubic curve.
>> The result will be always a linear representation from audio
>> callback to audio callback.
>> It may send to have a abstract editor that converts a cubic
>> curve to a row of linear changes quantisiced by the size of the
>> audio buffer.
>>
>> I actually thought about that
>> https://blueprints.launchpad.net/mixxx/+spec/midi-auto-dj
>>
>> How do you think about that? Storing the command in a midi file
>> has the advantage that we are able to record the original input,
>> including the original timestamps.
>>
>> The midi decoding is already in place so we have it for free an
>> only need to implement q midi player that is treated as a
>> controller.
>>
>> If I look too a possible gsoc project. It might be difficult
>> since it probably matters only a minority to our users.
>> To have a chance for a successful proposal, you have to make
>> sure that you issue also problems that matters a majority of our
>> users.
>>
>> Am 06.03.2016 2:45 nachm. schrieb "Ferran Pujol Camins"
>> mailto:ferranpujolcam...@gmail.com
>> >>:
>>
>> Macro recording is a cool feature by itself: you record some
>> cool routine and you can reproduce it with the click of a
>> button. But it also serves as the foundation of other
>> demanded features like Session action recording
>> <https://bugs.launchpad.net/mixxx/+bug/669009>, on-the-fly
>> macros
>> <
>> https://blueprints.launchpad.net/mixxx/+spec/deferred-button-execution>
>> or cool custom auto-dj transitions.
>>
>> It is desirable to be able to edit a macro, something
>> similar to what

Re: [Mixxx-devel] CO time resolution

[Ferran Pujol Camins]

Also, I feel we should not think in terms of recording MIDI, but recording
CO changes. This way users using the GUI can also record macros.

2016-03-06 20:15 GMT+01:00 Ferran Pujol Camins 
:

> Yes, the raw recorded data is a linear representation. The idea is to
> reduce the number of data points by interpolating the data with cubic
> curves, sort of a simplification of the data (as seen in the drawing of my
> previous mail).
>
> Do you feel macro recording only appeals to a minority of users? I think
> it's pretty impressive. And as I already explained, other cool features
> (like your auto-dj sequencer) can be built from it. This interpolation
> thing is only a part of what needs to be done, but I really feel it is
> needed if we want our users to edit recorded sequences.
>
> I appreciate your feedback!
>
> 2016-03-06 20:05 GMT+01:00 Daniel Schürmann :
>
>> Ah yes macro recording will be a cool feature.
>> I habe not yet understood how you will be able to record a becubic curve.
>> The result will be always a linear representation from audio callback to
>> audio callback.
>> It may send to have a abstract editor that converts a cubic curve to a
>> row of linear changes quantisiced by the size of the audio buffer.
>>
>> I actually thought about that
>> https://blueprints.launchpad.net/mixxx/+spec/midi-auto-dj
>>
>> How do you think about that? Storing the command in a midi file has the
>> advantage that we are able to record the original input, including the
>> original timestamps.
>>
>> The midi decoding is already in place so we have it for free an only need
>> to implement q midi player that is treated as a controller.
>>
>> If I look too a possible gsoc project. It might be difficult since it
>> probably matters only a minority to our users.
>> To have a chance for a successful proposal, you have to make sure that
>> you issue also problems that matters a majority of our users.
>> Am 06.03.2016 2:45 nachm. schrieb "Ferran Pujol Camins" <
>> ferranpujolcam...@gmail.com>:
>>
>>> Macro recording is a cool feature by itself: you record some cool
>>> routine and you can reproduce it with the click of a button. But it also
>>> serves as the foundation of other demanded features like Session action
>>> recording <https://bugs.launchpad.net/mixxx/+bug/669009>, on-the-fly
>>> macros
>>> <https://blueprints.launchpad.net/mixxx/+spec/deferred-button-execution>
>>> or cool custom auto-dj transitions.
>>>
>>> It is desirable to be able to edit a macro, something similar to what
>>> you would do in a daw. Problem: editing a curve represented by lots of
>>> short linear segments is not easy. Interpolating with cubic splines, the
>>> curve is represented in a more convenient way for editing:
>>>
>>>
>>>
>>> This might also be more memory efficient, but I think this wouldn't be a
>>> big problem anyway.
>>>
>>> The interpolation algorithm is just an auxiliary feature for the main
>>> feature of my proposal, which is macro recording. The interpolation
>>> algorithm will not improve Mixxx in any way that is not macro recording
>>> (although the algorithm will be properly isolated from the macro recording
>>> code, so we can further think if other Mixxx features can benefit from it,
>>> but this is out-of scope of my proposal).
>>>
>>> The algorithm I'm drafting is not real time, so it won't immediately
>>> solve it.
>>> You'll get the full proposal soon :)
>>>
>>> 2016-03-05 23:39 GMT+01:00 Daniel Schürmann :
>>>
>>>> Hi Ferran
>>>>
>>>> That sound interesting but I do not get the use case.
>>>>
>>>> What will be possible with such an algorithm what we cannot do yet?
>>>> What kind of users will benefit from it.
>>>>
>>>> A related real world issue is for example this:
>>>> https://bugs.launchpad.net/mixxx/+bug/1157570
>>>> Will your solution solve it?
>>>>
>>>> Kind regards,
>>>>
>>>> Daniel
>>>>
>>>>
>>>> Am 05.03.2016 um 17:26 schrieb Ferran Pujol Camins:
>>>>
>>>>> Thank you for the explanation Daniel.
>>>>> I'm writing my proposal for GSOC. I aim for macro recording.
>>>>> COs taking a finite set of values are not a big deal. But continuous CO
>>>>> are, because if we want to let the user edit the macro, a curve formed
&

Re: [Mixxx-devel] CO time resolution

[Ferran Pujol Camins]

Yes, the raw recorded data is a linear representation. The idea is to
reduce the number of data points by interpolating the data with cubic
curves, sort of a simplification of the data (as seen in the drawing of my
previous mail).

Do you feel macro recording only appeals to a minority of users? I think
it's pretty impressive. And as I already explained, other cool features
(like your auto-dj sequencer) can be built from it. This interpolation
thing is only a part of what needs to be done, but I really feel it is
needed if we want our users to edit recorded sequences.

I appreciate your feedback!

2016-03-06 20:05 GMT+01:00 Daniel Schürmann :

> Ah yes macro recording will be a cool feature.
> I habe not yet understood how you will be able to record a becubic curve.
> The result will be always a linear representation from audio callback to
> audio callback.
> It may send to have a abstract editor that converts a cubic curve to a row
> of linear changes quantisiced by the size of the audio buffer.
>
> I actually thought about that
> https://blueprints.launchpad.net/mixxx/+spec/midi-auto-dj
>
> How do you think about that? Storing the command in a midi file has the
> advantage that we are able to record the original input, including the
> original timestamps.
>
> The midi decoding is already in place so we have it for free an only need
> to implement q midi player that is treated as a controller.
>
> If I look too a possible gsoc project. It might be difficult since it
> probably matters only a minority to our users.
> To have a chance for a successful proposal, you have to make sure that you
> issue also problems that matters a majority of our users.
> Am 06.03.2016 2:45 nachm. schrieb "Ferran Pujol Camins" <
> ferranpujolcam...@gmail.com>:
>
>> Macro recording is a cool feature by itself: you record some cool routine
>> and you can reproduce it with the click of a button. But it also serves as
>> the foundation of other demanded features like Session action recording
>> <https://bugs.launchpad.net/mixxx/+bug/669009>, on-the-fly macros
>> <https://blueprints.launchpad.net/mixxx/+spec/deferred-button-execution>
>> or cool custom auto-dj transitions.
>>
>> It is desirable to be able to edit a macro, something similar to what you
>> would do in a daw. Problem: editing a curve represented by lots of short
>> linear segments is not easy. Interpolating with cubic splines, the curve is
>> represented in a more convenient way for editing:
>>
>>
>>
>> This might also be more memory efficient, but I think this wouldn't be a
>> big problem anyway.
>>
>> The interpolation algorithm is just an auxiliary feature for the main
>> feature of my proposal, which is macro recording. The interpolation
>> algorithm will not improve Mixxx in any way that is not macro recording
>> (although the algorithm will be properly isolated from the macro recording
>> code, so we can further think if other Mixxx features can benefit from it,
>> but this is out-of scope of my proposal).
>>
>> The algorithm I'm drafting is not real time, so it won't immediately
>> solve it.
>> You'll get the full proposal soon :)
>>
>> 2016-03-05 23:39 GMT+01:00 Daniel Schürmann :
>>
>>> Hi Ferran
>>>
>>> That sound interesting but I do not get the use case.
>>>
>>> What will be possible with such an algorithm what we cannot do yet?
>>> What kind of users will benefit from it.
>>>
>>> A related real world issue is for example this:
>>> https://bugs.launchpad.net/mixxx/+bug/1157570
>>> Will your solution solve it?
>>>
>>> Kind regards,
>>>
>>> Daniel
>>>
>>>
>>> Am 05.03.2016 um 17:26 schrieb Ferran Pujol Camins:
>>>
>>>> Thank you for the explanation Daniel.
>>>> I'm writing my proposal for GSOC. I aim for macro recording.
>>>> COs taking a finite set of values are not a big deal. But continuous CO
>>>> are, because if we want to let the user edit the macro, a curve formed
>>>> by a dense set of linear segments is not practical.
>>>> I'm drafting an interpolation algorithm that combines sections of linear
>>>> interpolation with sections of cubic interpolation. I ask this because I
>>>> want to draft the algorithm in matlab as a proof of concept, so I need
>>>> to generate data similar to what Mixxx would give. Then if my proposal
>>>> is accepted, the algorithm would be further fine tuned with real data
>>>> from Mixxx.
>>>> The algorithm should als

Re: [Mixxx-devel] CO time resolution

[Ferran Pujol Camins]

Macro recording is a cool feature by itself: you record some cool routine
and you can reproduce it with the click of a button. But it also serves as
the foundation of other demanded features like Session action recording
<https://bugs.launchpad.net/mixxx/+bug/669009>, on-the-fly macros
<https://blueprints.launchpad.net/mixxx/+spec/deferred-button-execution> or
cool custom auto-dj transitions.

It is desirable to be able to edit a macro, something similar to what you
would do in a daw. Problem: editing a curve represented by lots of short
linear segments is not easy. Interpolating with cubic splines, the curve is
represented in a more convenient way for editing:



This might also be more memory efficient, but I think this wouldn't be a
big problem anyway.

The interpolation algorithm is just an auxiliary feature for the main
feature of my proposal, which is macro recording. The interpolation
algorithm will not improve Mixxx in any way that is not macro recording
(although the algorithm will be properly isolated from the macro recording
code, so we can further think if other Mixxx features can benefit from it,
but this is out-of scope of my proposal).

The algorithm I'm drafting is not real time, so it won't immediately solve
it.
You'll get the full proposal soon :)

2016-03-05 23:39 GMT+01:00 Daniel Schürmann :

> Hi Ferran
>
> That sound interesting but I do not get the use case.
>
> What will be possible with such an algorithm what we cannot do yet?
> What kind of users will benefit from it.
>
> A related real world issue is for example this:
> https://bugs.launchpad.net/mixxx/+bug/1157570
> Will your solution solve it?
>
> Kind regards,
>
> Daniel
>
>
> Am 05.03.2016 um 17:26 schrieb Ferran Pujol Camins:
>
>> Thank you for the explanation Daniel.
>> I'm writing my proposal for GSOC. I aim for macro recording.
>> COs taking a finite set of values are not a big deal. But continuous CO
>> are, because if we want to let the user edit the macro, a curve formed
>> by a dense set of linear segments is not practical.
>> I'm drafting an interpolation algorithm that combines sections of linear
>> interpolation with sections of cubic interpolation. I ask this because I
>> want to draft the algorithm in matlab as a proof of concept, so I need
>> to generate data similar to what Mixxx would give. Then if my proposal
>> is accepted, the algorithm would be further fine tuned with real data
>> from Mixxx.
>> The algorithm should also provide some improvement on the size of the
>> data.
>>
>> 2016-03-05 12:12 GMT+01:00 Daniel Schürmann > <mailto:dasch...@mixxx.org>>:
>>
>>
>> do you facing a specific issue?
>>
>> Here how it works:
>> The new value is stored almost immediately in the global atomic
>> double.
>> A latency and jitter comes in when we look at the threads.
>> Let's look at the midi wheel to audio sample pass:
>> The midi values are sampled in a 1 ms (5 ms Linux) cycle. MIDI
>> supports rates up to 0.32 ms. This means a steady wheel turn of a
>> high speed midi device results in a buffer of 15 midi messages that
>> are processed at once. (unfortunately the midi timestamp is ignored)
>> the result is stored into the COs immediately waiting for the audio
>> thread which consumes the value every 23 ms (default audio buffer
>> size). If the engine thread is not scheduled before the midi thread
>> runs again the Co value is overwritten by a new one. The routing
>> samples are passed through on or two extra threads (depending on the
>> API implementation. Which introduces another delay of > 23 ms.
>>
>> How to improve It:
>> -sync the midi thread with the engine thread to eliminate the random
>> jitter.
>> -Take the midi timestamp into account to calculate the wheel speed
>> And acceleration.
>> - Add a filter like we have for mouse scratching that removes the
>> remaining jitter bits from the calculated values.
>>
>> We have currently an other Issue:
>> Let's say you want to play a track for 10 ms. You press play and
>> pause on the controller. Now it depends on the schedule moment of
>> the engine thread if the track is played 23 ms or not. In case play
>> and pause are processed between a engine callback play is
>> overwritten by pause. IMHO this behaviour is correct in this case.
>> If we need follow every Co change the consumer can register a change
>> callback. In this case every single change (or update if you wish)
>> is delivered either as a direct callback or queued on the threads qt
>> message queue.
>>
>> Kind regards, Daniel
>>
>>
>>
--
___
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] CO time resolution

[Ferran Pujol Camins]

Thank you for the explanation Daniel.
I'm writing my proposal for GSOC. I aim for macro recording.
COs taking a finite set of values are not a big deal. But continuous CO
are, because if we want to let the user edit the macro, a curve formed by a
dense set of linear segments is not practical.
I'm drafting an interpolation algorithm that combines sections of linear
interpolation with sections of cubic interpolation. I ask this because I
want to draft the algorithm in matlab as a proof of concept, so I need to
generate data similar to what Mixxx would give. Then if my proposal is
accepted, the algorithm would be further fine tuned with real data from
Mixxx.
The algorithm should also provide some improvement on the size of the data.

2016-03-05 12:12 GMT+01:00 Daniel Schürmann :

> do you facing a specific issue?
>
> Here how it works:
> The new value is stored almost immediately in the global atomic double.
> A latency and jitter comes in when we look at the threads.
> Let's look at the midi wheel to audio sample pass:
> The midi values are sampled in a 1 ms (5 ms Linux) cycle. MIDI supports
> rates up to 0.32 ms. This means a steady wheel turn of a high speed midi
> device results in a buffer of 15 midi messages that are processed at once.
> (unfortunately the midi timestamp is ignored) the result is stored into the
> COs immediately waiting for the audio thread which consumes the value every
> 23 ms (default audio buffer size). If the engine thread is not scheduled
> before the midi thread runs again the Co value is overwritten by a new one.
> The routing samples are passed through on or two extra threads (depending
> on the API implementation. Which introduces another delay of > 23 ms.
>
> How to improve It:
> -sync the midi thread with the engine thread to eliminate the random
> jitter.
> -Take the midi timestamp into account to calculate the wheel speed And
> acceleration.
> - Add a filter like we have for mouse scratching that removes the
> remaining jitter bits from the calculated values.
>
> We have currently an other Issue:
> Let's say you want to play a track for 10 ms. You press play and pause on
> the controller. Now it depends on the schedule moment of the engine thread
> if the track is played 23 ms or not. In case play and pause are processed
> between a engine callback play is overwritten by pause. IMHO this behaviour
> is correct in this case.
> If we need follow every Co change the consumer can register a change
> callback. In this case every single change (or update if you wish) is
> delivered either as a direct callback or queued on the threads qt message
> queue.
>
> Kind regards, Daniel
>
--
___
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

[Mixxx-devel] CO time resolution

[Ferran Pujol Camins]

How much fast does Mixxx checks for a change in a CO. It is some internal
Qt implementation?
If I were to record all the changes Mixxx from a CO how close would the
samples be?

I understand that a CO value change signal is thrown when the value changes
more than a ceratin threshold, rather than the value being regularly
sampled. But does Mixxx limit how fast a CO can emit this signals?
--
___
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

[Mixxx-devel] Google summer of code

[Ferran Pujol Camins]

Will Mixxx apply for Google Summer of code this year? Mentoring
organizations can begin submitting applications today :)
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&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

Re: [Mixxx-devel] Mapping export?

[Ferran Pujol Camins]

Ok, I just wanted to see if a bug needed to be filled. For some reason
(late at night?) I didn't find it.
Thank you.
El dia 08/01/2016 3:30 a. m., "Sean M. Pappalardo - D.J. Pegasus" <
spappala...@mixxx.org> va escriure:

>
>
> On 01/06/2016 03:18 AM, Ferran Pujol Camins wrote:
> > Couldn't Mixxx export mappings that were edited?
>
> Wouldn't this just be a file copy and rename?
>
> Sincerely,
> Sean M. Pappalardo
> "D.J. Pegasus"
> Mixxx Developer - Controller Specialist
>
>
>
> --
>
> ___
> 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
>
--
___
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

[Mixxx-devel] Mapping export?

[Ferran Pujol Camins]

Couldn't Mixxx export mappings that were edited? As far as I can see in the
controllers section we no longer can, isn't it?
--
___
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] A&H Xone K2 wiki documentation missing

[Ferran Pujol Camins]

Also, looking at the script, pushing the top encoders only resets the tempo
if shift is not pressed. Could you fix it so it does that always?
El dia 25/12/2015 12:35 a. m., "Be"  va escriure:

> Perhaps that unused control could be mapped to [Master],headSplit now. It
> would make sense considering shift + turning the encoder controls the
> headphone mix.
>
> On 12/24/2015 04:34 PM, Owen Williams wrote:
>
>> oh, hm, sync_master shouldn't be exposed in the published controller
>> config.  That's for explicit master sync which is a feature that is
>> unreleased.  I'll fix that so the button does nothing.
>>
>> owen
>>
>> On Thu, 2015-12-24 at 20:47 +0100, Ferran Pujol Camins wrote:
>>
>>> I honestly have no idea what sync master is.
>>> I fixed the other issues.
>>>
>>> 2015-12-24 20:00 GMT+01:00 Be :
>>>
>>>> Thanks, it looks good. A few small issues:
>>>> * the yellow text is difficult to read on the white background. Try
>>>> a darker yellow?
>>>> * pressing the bottom left push encoder is labeled as "sync
>>>> master". Looking at the XML file, it uses the CO
>>>> [Master],sync_master. The wiki (
>>>> http://mixxx.org/wiki/doku.php/mixxxcontrols ) lists sync_master as
>>>> a CO for [ChannelX] groups. What does it do for [Master]?
>>>> *SVG is preferable to PNG for easier editing later
>>>>
>>>> On 12/24/2015 09:19 AM, Ferran Pujol Camins wrote:
>>>>
>>>>>   I've finally documented it :)
>>>>>
>>>>> 2015-12-22 9:17 GMT+01:00 Ferran Pujol Camins
>>>>> mailto:ferranpujolcam...@gmail.com>
>>>>>
>>>>>> :
>>>>>>
>>>>>
>>>>>  I own one. However I won't have time until mid January.
>>>>>
>>>>>  2015-12-18 23:20 GMT+01:00 Be >>>> b...@gmx.com>>:
>>>>>
>>>>>
>>>>>  The Allen & Heath Xone K2 controller has a Mixxx
>>>>> Certified
>>>>>  mapping but
>>>>>  has no documentation. I asked the author of the PR that
>>>>> updated
>>>>>  it for
>>>>>  2.0 to document it a while ago, but they have not
>>>>> responded. Could
>>>>>  someone who has this controller please document the
>>>>> mapping?
>>>>>
>>>>>  http://mixxx.org/wiki/doku.php/allen_heath_xone_k2
>>>>>
>>>>>  -
>>>>> -
>>>>>  ___
>>>>>  Get Mixxx, the #1 Free MP3 DJ Mixing software Today
>>>>>  http://mixxx.org
>>>>>
>>>>>
>>>>>  Mixxx-devel mailing list
>>>>>  Mixxx-devel@lists.sourceforge.net
>>>>>  <mailto:Mixxx-devel@lists.sourceforge.net>
>>>>>  https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -
>>> -
>>> ___
>>> 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
>>>
>>
--
___
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] A&H Xone K2 wiki documentation missing

[Ferran Pujol Camins]

I honestly have no idea what sync master is.
I fixed the other issues.

2015-12-24 20:00 GMT+01:00 Be :

> Thanks, it looks good. A few small issues:
> * the yellow text is difficult to read on the white background. Try a
> darker yellow?
> * pressing the bottom left push encoder is labeled as "sync master".
> Looking at the XML file, it uses the CO [Master],sync_master. The wiki (
> http://mixxx.org/wiki/doku.php/mixxxcontrols ) lists sync_master as a CO
> for [ChannelX] groups. What does it do for [Master]?
> *SVG is preferable to PNG for easier editing later
>
> On 12/24/2015 09:19 AM, Ferran Pujol Camins wrote:
>
>> I've finally documented it :)
>>
>> 2015-12-22 9:17 GMT+01:00 Ferran Pujol Camins
>> mailto:ferranpujolcam...@gmail.com>>:
>>
>> I own one. However I won't have time until mid January.
>>
>> 2015-12-18 23:20 GMT+01:00 Be mailto:b...@gmx.com>>:
>>
>>
>> The Allen & Heath Xone K2 controller has a Mixxx Certified
>> mapping but
>> has no documentation. I asked the author of the PR that updated
>> it for
>> 2.0 to document it a while ago, but they have not responded. Could
>> someone who has this controller please document the mapping?
>>
>> http://mixxx.org/wiki/doku.php/allen_heath_xone_k2
>>
>>
>> --
>> ___
>> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
>> http://mixxx.org
>>
>>
>> Mixxx-devel mailing list
>> Mixxx-devel@lists.sourceforge.net
>> <mailto:Mixxx-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>>
>>
>>
>>
--
___
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] A&H Xone K2 wiki documentation missing

[Ferran Pujol Camins]

I've finally documented it :)

2015-12-22 9:17 GMT+01:00 Ferran Pujol Camins :

> I own one. However I won't have time until mid January.
>
> 2015-12-18 23:20 GMT+01:00 Be :
>
>>
>> The Allen & Heath Xone K2 controller has a Mixxx Certified mapping but
>> has no documentation. I asked the author of the PR that updated it for
>> 2.0 to document it a while ago, but they have not responded. Could
>> someone who has this controller please document the mapping?
>>
>> http://mixxx.org/wiki/doku.php/allen_heath_xone_k2
>>
>>
>> --
>> ___
>> 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
>>
>
>
--
___
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

[Mixxx-devel] Mixxx useless on windows 10: No sound API detected

[Ferran Pujol Camins]

Hello! Some people including me, are having problems with windows 10. Mixxx
presents no sound api at all, so it is completely useless!

https://bugs.launchpad.net/mixxx/+bug/1490181

I don't know if we officially support windows 10 for Mixxx 2.0 (I think we
should). I f this is the case this is totally a release blocker for me.
--
___
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] A&H Xone K2 wiki documentation missing

[Ferran Pujol Camins]

I own one. However I won't have time until mid January.

2015-12-18 23:20 GMT+01:00 Be :

>
> The Allen & Heath Xone K2 controller has a Mixxx Certified mapping but
> has no documentation. I asked the author of the PR that updated it for
> 2.0 to document it a while ago, but they have not responded. Could
> someone who has this controller please document the mapping?
>
> http://mixxx.org/wiki/doku.php/allen_heath_xone_k2
>
>
> --
> ___
> 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
>
--
___
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] hardware donation policy?

[Ferran Pujol Camins]

I own one, if that helps you.
El dia 15/12/2015 12:20 a. m., "Be"  va escriure:

> I want to ask DJ Tech Tools if they'll donate a MIDI Fighter Twister to
> me. Sean mentioned on IRC there may have been some policy regarding
> hardware donations. He said there was a document about it but couldn't
> find that. Is there some policy I should be aware of? If there is, it
> should be clearly on the wiki.
>
>
> --
> ___
> 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
>
--
___
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] brainstorming for future mapping format

[Ferran Pujol Camins]

I also own a MF Twister, if you need beta testers count on me ;)

2015-10-17 9:27 GMT+02:00 Be :

> I plan on developing a prototype of the layering JS library and
> rewriting the Electrix Tweaker mapping to use it. I also plan on getting
> a MIDI Fighter Twister soon and using the prototype JS library to map
> that. However, I'm not sure if the library should be included into Mixxx
> until the other issues in that blueprint
> (https://bugs.launchpad.net/mixxx/+bug/1507089 and
> https://bugs.launchpad.net/mixxx/+bug/398350 ) are resolved because it
> may make sense to change the library's API significantly after that.
>
> On 10/17/2015 02:07 AM, Be wrote:
> > I have started a blueprint on Launchpad:
> > https://blueprints.launchpad.net/mixxx/+spec/scripting-2.0
> >
> > I wrote out a description for the layered mapping system in this bug:
> > https://bugs.launchpad.net/mixxx/+bug/1507093
> >
> > On 06/22/2015 01:34 PM, Be wrote:
> >> I've been thinking what could be better about how Mixxx maps controllers
> >> and keyboards. I have outlined some design goals and really rough
> >> sketches of what the format could look like:
> >>
> >> http://mixxx.org/wiki/doku.php/new_control_mapping_format
> >>
> >>
> --
> >> Monitor 25 network devices or servers for free with OpManager!
> >> OpManager is web-based network management software that monitors
> >> network devices and physical & virtual servers, alerts via email & sms
> >> for fault. Monitor 25 devices for free with no restriction. Download now
> >> http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
> >> ___
> >> 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
> >>
> >
> >
> --
> > ___
> > 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
> >
>
>
> --
> ___
> 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
>
--
___
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

[Mixxx-devel] Catalan localization forum thread

[Ferran Pujol Camins]

Hello, I've added a new thread so us catalan translators can discuss the
localization. I've also linked some resources that are useful to translate
Mixxx into catalan.

http://www.mixxx.org/forums/viewtopic.php?f=10&t=7599

I just wanted to notify the catalans in the list :)
--
___
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] Database extension

[Ferran Pujol Camins]

Oh, one last thing: is there any test for db? I haven't find nothing that
seemed like that to me.

2015-10-09 20:08 GMT+02:00 Ferran Pujol Camins 
:

> Nice, thank you!
>
> 2015-10-09 20:06 GMT+02:00 RJ Ryan :
>
>> 1) Add a new revision to res/schema.xml:
>>
>> 
>> 
>>   ... description ...
>> 
>> 
>>   ALTER TABLE cues ADD COLUMN visible INTEGER DEFAULT 1;
>> 
>>   
>>
>> (min_compatible is the version of the schema this is backwards compatible
>> with -- adding a new column is pretty much always backwards compatible
>> since older versions of mixxx will just ignore it)
>>
>> 2) Update kRequiredSchemaVersion to 25 in library/trackcollection.cpp
>>
>> When you run Mixxx, it will alter the table to add a "visible" column
>> that defaults to 1. Update CueDao to read this column and do stuff based on
>> it.
>>
>> That should be it!
>> RJ
>>
>>
>>
>> On Fri, Oct 9, 2015 at 10:46 AM, Ferran Pujol Camins <
>> ferranpujolcam...@gmail.com> wrote:
>>
>>> Hi!
>>>
>>> I want to add a visible bool to cuepoints. What do I need to change
>>> beyond cuedao to achieve this?
>>>
>>> Cheers.
>>>
>>>
>>> --
>>>
>>> ___
>>> 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
>>>
>>
>>
>
--
___
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] Database extension

[Ferran Pujol Camins]

Nice, thank you!

2015-10-09 20:06 GMT+02:00 RJ Ryan :

> 1) Add a new revision to res/schema.xml:
>
> 
> 
>   ... description ...
> 
> 
>   ALTER TABLE cues ADD COLUMN visible INTEGER DEFAULT 1;
> 
>   
>
> (min_compatible is the version of the schema this is backwards compatible
> with -- adding a new column is pretty much always backwards compatible
> since older versions of mixxx will just ignore it)
>
> 2) Update kRequiredSchemaVersion to 25 in library/trackcollection.cpp
>
> When you run Mixxx, it will alter the table to add a "visible" column that
> defaults to 1. Update CueDao to read this column and do stuff based on it.
>
> That should be it!
> RJ
>
>
>
> On Fri, Oct 9, 2015 at 10:46 AM, Ferran Pujol Camins <
> ferranpujolcam...@gmail.com> wrote:
>
>> Hi!
>>
>> I want to add a visible bool to cuepoints. What do I need to change
>> beyond cuedao to achieve this?
>>
>> Cheers.
>>
>>
>> --
>>
>> ___
>> 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
>>
>
>
--
___
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

[Mixxx-devel] Database extension

[Ferran Pujol Camins]

Hi!

I want to add a visible bool to cuepoints. What do I need to change beyond
cuedao to achieve this?

Cheers.
--
___
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] Official skins license

[Ferran Pujol Camins]

Understood! Thank you for explaining it to me!

2015-08-23 5:19 GMT+02:00 RJ Ryan :

>
>
> On Sat, Aug 22, 2015 at 7:54 PM, Ferran Pujol Camins <
> ferranpujolcam...@gmail.com> wrote:
>
>> But isn't there this incompatibility issue? Since we ship the skins with
>> Mixxx, they form a whole product that is under GPLv2 (What does it mean
>> to say a license is “compatible with the GPL?”
>> <http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean>).
>>
>
> The various barbs in the GPL that cause it to be viral really only affect
> code -- specifically code that's linked together with a linker. This is why
> a GPL'd kernel (Linux) doesn't require the programs that run on it (i.e.
> Android, lots of apps shipped with Ubuntu) to be GPL and two processes that
> talk over a data pipe (network or UNIX socket) don't have to have the same
> license even if they're part of the same distributed "product". ("Open
> core" projects like MySQL use this trick to keep proprietary blobs
> closed-source by structuring their plugin APIs so that they are independent
> processes that talk over network sockets).
>
> Since skins are just data processed by Mixxx they aren't affected by the
> license.
>
> Copyright applies to specific physical works (i.e. the text of a book, an
> executable binary, an artwork file, a text file containing C++ code) -- not
> Mixxx as an abstract "product". Our source code is licensed under the GPLv2
> and when it's linked into the mixxx binary that binary is a "derivative
> work" -- so those are the only two works we distribute that carry the GPLv2
> license. We're free to choose whatever license we want for the artwork and
> other data files (database schema file, skin XML, MIDI/HID preset XML/JS,
> etc.).
>
> The Javascript for MIDI / HID is an interesting case because it's code
> that's interpreted by the Mixxx binary, not linked -- so we can choose
> whatever license we want for it and also distribute scripts written by
> authors who picked a GPL-incompatible license for their Javascript (for
> some reason? maybe they just really like the MPL ;) ).
>
> But CC-BY-SA can't be "translated" to GPLv2 as seen here
>> <http://www.gnu.org/licenses/license-list.html.en#ccbysa> (the yellow
>> dotted line indicates it isn't compatible with GPL).
>>
>> If I understand it correctly, if we didn't include the skins with the
>> release but instead we offered them as a separate download there would be
>> no issue. But since we ship them with Mixxx, both things are a whole
>> product.
>>
>> I'm sorry for being nitpicky, I just want to make sure I understand the
>> thing properly and that we make things right :)
>>
>
> No worries :) IANAL but I have a fair bit of experience with copyright in
> an open-source setting and by coincidence as part of my "real life" job
> talk to copyright lawyers on a regular basis. What we do with Mixxx is OK
> -- as I understand it. Getting the advice of a real lawyer for Mixxx may be
> useful to do though -- especially since we can discuss things with them in
> a privileged setting.
>
>
>> 2015-08-23 4:45 GMT+02:00 RJ Ryan :
>>
>>> Hey Ferran,
>>>
>>> We release the Mixxx binary under GPLv2 -- the GPL may be used for other
>>> works but it is primarily oriented towards code and I think the legalese
>>> around it makes it unclear what obligations there are to uphold as an
>>> artist. I think CC-BY-SA makes it much more clear and is better known among
>>> artists.
>>>
>>> Cheers,
>>> RJ
>>>
>>> On Sat, Aug 22, 2015 at 12:38 AM, Ferran Pujol Camins <
>>> ferranpujolcam...@gmail.com> wrote:
>>>
>>>> Hello, I've read a bit about the GPL and CC licenses.
>>>>
>>>> Our three official skins (Deere, LateNight and Shade) currently are
>>>> under a CC-BY-SA <http://creativecommons.org/licenses/by-sa/3.0/>
>>>> license, but we release them with Mixxx under a GPLv2 license. This is
>>>> incompatible because we are releasing the skins as a whole product with a
>>>> different license. Shouldn't we just remove the CC license for the skins
>>>> and release all under the GPLv2? This is what's recommended here:
>>>>
>>>> http://www.gnu.org/licenses/license-recommendations.html#data
>>>>
>>>>
>>>> --
>>>>
>>>> ___
>>>> 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
>>>>
>>>
>>>
>>
>
--
___
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] Official skins license

[Ferran Pujol Camins]

But isn't there this incompatibility issue? Since we ship the skins with
Mixxx, they form a whole product that is under GPLv2 (What does it mean to
say a license is “compatible with the GPL?”
<http://www.gnu.org/licenses/gpl-faq.html#WhatDoesCompatMean>).
But CC-BY-SA can't be "translated" to GPLv2 as seen here
<http://www.gnu.org/licenses/license-list.html.en#ccbysa> (the yellow
dotted line indicates it isn't compatible with GPL).

If I understand it correctly, if we didn't include the skins with the
release but instead we offered them as a separate download there would be
no issue. But since we ship them with Mixxx, both things are a whole
product.

I'm sorry for being nitpicky, I just want to make sure I understand the
thing properly and that we make things right :)

2015-08-23 4:45 GMT+02:00 RJ Ryan :

> Hey Ferran,
>
> We release the Mixxx binary under GPLv2 -- the GPL may be used for other
> works but it is primarily oriented towards code and I think the legalese
> around it makes it unclear what obligations there are to uphold as an
> artist. I think CC-BY-SA makes it much more clear and is better known among
> artists.
>
> Cheers,
> RJ
>
> On Sat, Aug 22, 2015 at 12:38 AM, Ferran Pujol Camins <
> ferranpujolcam...@gmail.com> wrote:
>
>> Hello, I've read a bit about the GPL and CC licenses.
>>
>> Our three official skins (Deere, LateNight and Shade) currently are under
>> a CC-BY-SA <http://creativecommons.org/licenses/by-sa/3.0/> license, but
>> we release them with Mixxx under a GPLv2 license. This is incompatible
>> because we are releasing the skins as a whole product with a different
>> license. Shouldn't we just remove the CC license for the skins and release
>> all under the GPLv2? This is what's recommended here:
>>
>> http://www.gnu.org/licenses/license-recommendations.html#data
>>
>>
>> --
>>
>> ___
>> 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
>>
>
>
--
___
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

[Mixxx-devel] Official skins license

[Ferran Pujol Camins]

Hello, I've read a bit about the GPL and CC licenses.

Our three official skins (Deere, LateNight and Shade) currently are under a
CC-BY-SA  license, but we
release them with Mixxx under a GPLv2 license. This is incompatible because
we are releasing the skins as a whole product with a different license.
Shouldn't we just remove the CC license for the skins and release all under
the GPLv2? This is what's recommended here:

http://www.gnu.org/licenses/license-recommendations.html#data
--
___
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] brainstorming for future mapping format

[Ferran Pujol Camins]

I've now well Traktor mapping system. It wouldn't be that bad (provided we
have scripting anyway) if:

1-Execution order of sentences could be determined.
2-Modifiers could have an arbitrary value (double, text, etc...) instead of
just 0,..7.
3-More than two conditionals could be defined for a sentence.
4-The number of modifiers wasn't limited to 8.
5-Modifiers could have a name.

2015-08-11 19:14 GMT+02:00 Be :

> I actually played around with Traktor's mapping system last night and it
> isn't that great. Complex mappings quickly get messy. We can do better. :)
>
> On 08/10/2015 04:29 PM, Be wrote:
> >
> >
> > On 07/07/2015 10:14 AM, raskolni...@es.gnu.org wrote:
> >>
> >> On the OP topic: I think your proposed sintaxes look good and could be
> >> useful, it's nice that you open this discussion!
> >>
> >> On the other hand, I have the impression that what we really need is a
> >> two simple functions `map[Output,Input]Control(channel, value, group,
> >> name, options)` that allows to define a MIDI mapping at run-time.  This
> >> would be the JS equivalent of the  tags.
> >>
> >> On top of this low-level API many richer high-level APIs can be
> >> explored, including your JSON-style formats, Mixco, and further.  But
> >> most importantly, it would be possible to write advanced controllers
> >> with JS mode switching, that are as performant as the pure XML scripts.
> >>Right now, a important limitation in the framework is that it's all
> or
> >> nothing, either you bind a MIDI signal statically in the XML, or handle
> >> the MIDI events completely in JS -- an interesting approach is to be
> >> able to create direct binding for Mixxx controls from JS that then
> >> bypass the script for the individual events, providing better
> performance.
> >>
> >> Cheers!
> >>
> >> JP
> >>
> >>
> >
> > I think this is the most reasonable way forward from where Mixxx is.
> > This could facilitate a smooth phasing out of the XML format and a
> > transition to JSON. All the info contained in the header of XML files
> > could be defined in JSON with a metadata object.
> >
> > Looking into other programs' mapping systems, it looks like Traktor and
> > possibly Ableton are the only ones that have mapping systems worth
> > taking ideas from. Serato's system is primitive (at least the
> > user-definable part; no one knows the secrets of how official,
> > unmodifiable Serato certified mappings work). VirtualDJ has its own
> > clunky mini-scripting language. Ableton allows scripting with Python but
> > at first glace I don't see much documentation for it and I've heard
> > there is no debugging output. Traktor's mapping system is flexible but
> > tries to do so much in GUI that it ends up being cumbersome. I think it
> > would be awesome to implement a GUI interface similar to Traktor's but
> > allow direct input of JavaScript snippets from the GUI. For example,
> > instead of selecting [Channel1] as the group for a mapping in the GUI, a
> > user could type in a JS variable that could be toggled between
> > [Channel1] and [Channel3]. Also, custom JS functions could be typed into
> > the GUI. This could combine the best of a GUI interface and the
> > flexibility of JavaScript.
> >
> > I got another idea that I think would be both powerful and
> > straightforward: mappings could be built from layers, which would be JS
> > objects containing groups of input and output mappings. In the GUI,
> > layers would be presented as tabs at the top of the mapping editor.
> > Button presses (or whatever) would be mapped to switch between layers.
> > By default, activating a layer would overwrite active mappings that
> > overlap with the layer being activated. Mixxx could remember the
> > previously active mappings and revert to that when a layer is disabled,
> > which would make implementing shift button layers trivially easy. Would
> > it make more sense to implement layering functionality in C++ or as a
> > JavaScript library making use of a new mapping (dis)connection function?
> >
> >
> --
> > ___
> > 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
> >
>
>
> --
> ___
> 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
>
--
___
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

Re: [Mixxx-devel] Deere state

[Ferran Pujol Camins]

The fx section is a skinning nightmare when the 4 fx chains have the echo
at the same time and all the mic and aux inputs are assigned. There's no
way to make it look good.
If no one complains soon, I will just implement the solution I proposed, as
a band-aid:


> As we don't have a polished fx workflow yet, I propose to just adopt the
> same 2x2 fx approach Shade has. This way the skins will be consistent and
> we avoid space issues.


I've also filed a bug to discuss this issue:
https://bugs.launchpad.net/mixxx/+bug/1481083

2015-08-02 23:32 GMT+02:00 Sébastien Blaisot :

>
> Hey, that's really cool ! I didn't even know this was possible with the
> skin engine.
>
> Thanks.
>
> sb
>
>
> Le 02/08/2015 22:53, S.Brandt a écrit :
>
> Once you configured mic 1-4, and aux 1-4 in the Preferences> Sound
> Hardware, they become available in the Mic rack, and selectable in the FX
> section.
>
> 
> S.Brandt
> Mixxx - Free Digital DJ Mixing Software
> www.mixxx.org | Get Involved 
>
> On Aug 1, 2015, at 6:27 PM, Sébastien Blaisot  wrote:
>
>
> What an improvement ! I find Deere far more usable now.
>
> However, it would be nice if the "mic" section could show 2 mic as well
> as an "aux" section to control aux passthrough.
>
> I will try to add that if I have some time after my vacations.
>
> regards,
>
> sb
>
>
>
>
> --
>
> ___
> 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
>
--
___
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] Deere state

[Ferran Pujol Camins]

I've just opened PR #666 <https://github.com/mixxxdj/mixxx/pull/666> (😈).
I'll push there improvements to skins that fit what we've discussed so far.
It might grow a little (or not, I don't know). But I promise I'll make
concise, easy to review commits that will mostly be self-contained.


I'd also like to hear people thoughts on what I proposed for the fx
sections:

As we don't have a polished fx workflow yet, I propose to just adopt the
> same 2x2 fx approach Shade has. This way the skins will be consistent and
> we avoid space issues.
>

2015-07-31 19:35 GMT+02:00 Ferran Pujol Camins 
:

> > By the way I wouldn't be opposed to hiding the pingpong knob in Echo if
> it makes our lives easier :) :).
>
> Heh, I was thinking the same for the send knob :)
>
> 2015-07-31 19:32 GMT+02:00 Owen Williams :
>
>> On Fri, 2015-07-31 at 19:24 +0200, Ferran Pujol Camins wrote:
>> >
>> > The skins are also inconsistent in the way they handle the fx.
>> >
>>
>> Yeah this is unfortunate but we've mostly decided to let them be
>> inconsistent for now.  My hope is that people will decide that one of
>> the approaches is best and then we can standardize on it using the
>> templating system.
>>
>> Does anyone see a drawback to copying Shade's fx approach for now?  By
>> the way I wouldn't be opposed to hiding the pingpong knob in Echo if it
>> makes our lives easier :) :).
>>
>> >
>> > As we don't have a polished fx workflow yet, I propose to just adopt
>> > the same 2x2 fx approach Shade has. This way the skins will be
>> > consistent and we avoid space issues.
>> >
>> >
>> > 2015-07-31 18:44 GMT+02:00 Owen Williams :
>> > On Fri, 2015-07-31 at 18:19 +0200, Daniel Schürmann wrote:
>> >
>> > > > I am trying to keep the amount of work to a minimum to
>> > expedite the
>> > > release.
>> > >
>> > > How is this related to the view menu?
>> > > Thanks to Jercaianu Adding a new view option is a 10 lines
>> > patch
>> > > around
>> > https://github.com/mixxxdj/mixxx/blob/master/src/mixxx.cpp#L937
>> >
>> > That's 10 lines after we've had a discussion about what the
>> > option
>> > should be, how it should be worded and translated, and what
>> > the key
>> > binding should be, and then testing, and then making sure the
>> > other
>> > skins still work... There's a lot more to implementing a
>> > feature than
>> > just the code.  So for now, let's please just stick to working
>> > with skin
>> > files.
>> >
>> > Owen
>> >
>> >
>> >
>> >
>>  
>> --
>> > ___
>> > 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
>> >
>> >
>>
>>
>>
>
--
___
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] Deere state

[Ferran Pujol Camins]

> By the way I wouldn't be opposed to hiding the pingpong knob in Echo if
it makes our lives easier :) :).

Heh, I was thinking the same for the send knob :)

2015-07-31 19:32 GMT+02:00 Owen Williams :

> On Fri, 2015-07-31 at 19:24 +0200, Ferran Pujol Camins wrote:
> >
> > The skins are also inconsistent in the way they handle the fx.
> >
>
> Yeah this is unfortunate but we've mostly decided to let them be
> inconsistent for now.  My hope is that people will decide that one of
> the approaches is best and then we can standardize on it using the
> templating system.
>
> Does anyone see a drawback to copying Shade's fx approach for now?  By
> the way I wouldn't be opposed to hiding the pingpong knob in Echo if it
> makes our lives easier :) :).
>
> >
> > As we don't have a polished fx workflow yet, I propose to just adopt
> > the same 2x2 fx approach Shade has. This way the skins will be
> > consistent and we avoid space issues.
> >
> >
> > 2015-07-31 18:44 GMT+02:00 Owen Williams :
> > On Fri, 2015-07-31 at 18:19 +0200, Daniel Schürmann wrote:
> >
> > > > I am trying to keep the amount of work to a minimum to
> > expedite the
> > > release.
> > >
> > > How is this related to the view menu?
> > > Thanks to Jercaianu Adding a new view option is a 10 lines
> > patch
> > > around
> > https://github.com/mixxxdj/mixxx/blob/master/src/mixxx.cpp#L937
> >
> > That's 10 lines after we've had a discussion about what the
> > option
> > should be, how it should be worded and translated, and what
> > the key
> > binding should be, and then testing, and then making sure the
> > other
> > skins still work... There's a lot more to implementing a
> > feature than
> > just the code.  So for now, let's please just stick to working
> > with skin
> > files.
> >
> > Owen
> >
> >
> >
> >
>  
> --
> > ___
> > 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
> >
> >
>
>
>
--
___
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] Deere state

[Ferran Pujol Camins]

PS: if this gains consensus, I volunteer to commit the changes,

2015-07-31 19:24 GMT+02:00 Ferran Pujol Camins 
:

> I don't care delaying some skin polishing to 1.13 or whatever :)
>
> But let's make 1.12 happen ASAP. For me, the biggest headache with Deere
> is the fx section. Just try to put the four units with the echo effect and
> expand the fx section. Theres no room for all the knobs in my 1366x768
> screen. The skins are also inconsistent in the way they handle the fx.
>
> As we don't have a polished fx workflow yet, I propose to just adopt the
> same 2x2 fx approach Shade has. This way the skins will be consistent and
> we avoid space issues.
>
> 2015-07-31 18:44 GMT+02:00 Owen Williams :
>
>> On Fri, 2015-07-31 at 18:19 +0200, Daniel Schürmann wrote:
>>
>> > > I am trying to keep the amount of work to a minimum to expedite the
>> > release.
>> >
>> > How is this related to the view menu?
>> > Thanks to Jercaianu Adding a new view option is a 10 lines patch
>> > around https://github.com/mixxxdj/mixxx/blob/master/src/mixxx.cpp#L937
>>
>> That's 10 lines after we've had a discussion about what the option
>> should be, how it should be worded and translated, and what the key
>> binding should be, and then testing, and then making sure the other
>> skins still work... There's a lot more to implementing a feature than
>> just the code.  So for now, let's please just stick to working with skin
>> files.
>>
>> Owen
>>
>>
>>
>>
>> --
>> ___
>> 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
>>
>
>
--
___
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] Deere state

[Ferran Pujol Camins]

I don't care delaying some skin polishing to 1.13 or whatever :)

But let's make 1.12 happen ASAP. For me, the biggest headache with Deere is
the fx section. Just try to put the four units with the echo effect and
expand the fx section. Theres no room for all the knobs in my 1366x768
screen. The skins are also inconsistent in the way they handle the fx.

As we don't have a polished fx workflow yet, I propose to just adopt the
same 2x2 fx approach Shade has. This way the skins will be consistent and
we avoid space issues.

2015-07-31 18:44 GMT+02:00 Owen Williams :

> On Fri, 2015-07-31 at 18:19 +0200, Daniel Schürmann wrote:
>
> > > I am trying to keep the amount of work to a minimum to expedite the
> > release.
> >
> > How is this related to the view menu?
> > Thanks to Jercaianu Adding a new view option is a 10 lines patch
> > around https://github.com/mixxxdj/mixxx/blob/master/src/mixxx.cpp#L937
>
> That's 10 lines after we've had a discussion about what the option
> should be, how it should be worded and translated, and what the key
> binding should be, and then testing, and then making sure the other
> skins still work... There's a lot more to implementing a feature than
> just the code.  So for now, let's please just stick to working with skin
> files.
>
> Owen
>
>
>
>
> --
> ___
> 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
>
--
___
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] Deere state

[Ferran Pujol Camins]

Oh, what are the items on your TODO? I have time to work now, so please
share your thoughts about what I pointed and lets see if we can agree what
needs to be done.

2015-07-28 13:14 GMT+02:00 Ferran Pujol Camins 
:

> I must say I'm impressed, you've even taken care of a wish I made time ago
> to hide the BPM info :)
>
> Ok, here are my thoughts. There's a lot of things, keep in mind I say all
> this with a constructive attitude and that this is just my personal opinion
> :)
>
> -I love the spinnies, they are neat and cool. However, they are a bit
> deformed near the gap, you can see this when they spin.
>
> -The buttons next to the overview waveform don't follow the same layout
> than the latest Deere and Shade (PR #639
> <https://github.com/mixxxdj/mixxx/pull/639>). In particular, the
> crossfader assign button is missing. We could add the slip mode button to
> LateNight and Shade as well to keep consistency between skins. We could
> ditch the key lock switch to make room for the slip mode button, it would
> be better placed next to the key knob like it already is in Deere.
>
> -When on 4 decks mode, if I switch to stacked waveforms, the window
> becomes too big for my screen which is annoying. This option should be
> disabled if the user's screen is too small. If this is not possible with
> the current codebase maybe we can omit this feature for 1.12, we already
> have LateNight for people wanting stacked waveforms.
>
> -The buttons of the mixer are tiny, difficult to see if the DJ is at a
> distance from the screen and they can't be easily clicked.
>
> -I would ditch the skin settings pane. It's clever, but is not standard
> among skins. From my point of view, we should avoid custom skin CO and
> confine ourselves to the standard CO until we have a way to fully integrate
> these skin specific CO to Mixxx (make them appear to the view menu for
> example).
> -The view section is already managed by the view menu in (PR #639
> <https://github.com/mixxxdj/mixxx/pull/639>).
> -The option to show cover art either on the spinnies or the title is
> cool. We could add this to all skins and add a new default CO.
>  Otherwise I wouldn't include it to 1.12. The same for hide/show bpm
> and track info.
> -For the samplers and FX advanced mode we already have the
> corresponding show/hide CO. They also have a button on the skin.
> -Maximize library needs a button right on the skin. The upper bar is a
> good place.
>
> -I don't see a point on being able to hide the library when no other
> widgets take advantage of the space it leaves. I would disable this option
> in these situations, like the latest LateNight does (PR #639
> <https://github.com/mixxxdj/mixxx/pull/639>).
>
> -The slip mode spinny keeps running when the cue button is pressed. But
> this might be a bug in Mixxx.
>
> -The look of the faders is not consistent with the look of the knobs.
>
> -The skin minimum width needs to be increased a bit.
>
> -We could show more cue points automatically with a SizeAwareStack.
>
> -The loop and beat jump numbers could be decreased with a right click.
> Also, can be deck-independent?
>
> -Just opinion: what if we make the colors darker?
>
>
>
> 2015-07-24 16:23 GMT+02:00 Owen Williams :
>
>> How about we create a sub-branch of 1.12 and merge your work there, and
>> then we can have others help out.  When it's in good shape we can merge
>> it back into 1.12.  (That way 1.12 stays pristine while we are cleaning
>> things up.)
>>
>> On Fri, 2015-07-24 at 16:11 +0200, S.Brandt wrote:
>> > Hi,
>> > Deere maintainer here.
>> > My current dev branch: [1]
>> > Fixes (mostly) all bugs for the skin listed: [2]
>> > It merges cleanly [3], but i`ve submitted no PR yet since it is still
>> > unfinished, some items on my todo.
>> >
>> >
>> > Unfortunately, time is an major issue.
>> >
>> >
>> > Suggestion?
>> > Test the skin in its current state and comment and/or submit PR.
>> >
>> >
>> > [1]:  https://github.com/esbrandt/mixxx/tree/deere_updates
>> > [2]:  https://blueprints.launchpad.net/mixxx/+spec/1.12-skins
>> > [3]:
>> >
>> https://github.com/mixxxdj/mixxx/compare/1.12...esbrandt:deere_updates?expand=1
>> > 
>> > S.Brandt
>> > Mixxx - Free Digital DJ Mixing Software
>> > www.mixxx.org | Get Involved
>> >
>> > > On Jul 23, 2015, at 8:28 PM, Ferran Pujol Camins
>> > >  wrote:
>> > >
>> > > Hello, I thought I could put som

Re: [Mixxx-devel] Deere state

[Ferran Pujol Camins]

I must say I'm impressed, you've even taken care of a wish I made time ago
to hide the BPM info :)

Ok, here are my thoughts. There's a lot of things, keep in mind I say all
this with a constructive attitude and that this is just my personal opinion
:)

-I love the spinnies, they are neat and cool. However, they are a bit
deformed near the gap, you can see this when they spin.

-The buttons next to the overview waveform don't follow the same layout
than the latest Deere and Shade (PR #639
<https://github.com/mixxxdj/mixxx/pull/639>). In particular, the crossfader
assign button is missing. We could add the slip mode button to LateNight
and Shade as well to keep consistency between skins. We could ditch the key
lock switch to make room for the slip mode button, it would be better
placed next to the key knob like it already is in Deere.

-When on 4 decks mode, if I switch to stacked waveforms, the window becomes
too big for my screen which is annoying. This option should be disabled if
the user's screen is too small. If this is not possible with the current
codebase maybe we can omit this feature for 1.12, we already have LateNight
for people wanting stacked waveforms.

-The buttons of the mixer are tiny, difficult to see if the DJ is at a
distance from the screen and they can't be easily clicked.

-I would ditch the skin settings pane. It's clever, but is not standard
among skins. From my point of view, we should avoid custom skin CO and
confine ourselves to the standard CO until we have a way to fully integrate
these skin specific CO to Mixxx (make them appear to the view menu for
example).
-The view section is already managed by the view menu in (PR #639
<https://github.com/mixxxdj/mixxx/pull/639>).
-The option to show cover art either on the spinnies or the title is
cool. We could add this to all skins and add a new default CO.
 Otherwise I wouldn't include it to 1.12. The same for hide/show bpm
and track info.
-For the samplers and FX advanced mode we already have the
corresponding show/hide CO. They also have a button on the skin.
-Maximize library needs a button right on the skin. The upper bar is a
good place.

-I don't see a point on being able to hide the library when no other
widgets take advantage of the space it leaves. I would disable this option
in these situations, like the latest LateNight does (PR #639
<https://github.com/mixxxdj/mixxx/pull/639>).

-The slip mode spinny keeps running when the cue button is pressed. But
this might be a bug in Mixxx.

-The look of the faders is not consistent with the look of the knobs.

-The skin minimum width needs to be increased a bit.

-We could show more cue points automatically with a SizeAwareStack.

-The loop and beat jump numbers could be decreased with a right click.
Also, can be deck-independent?

-Just opinion: what if we make the colors darker?



2015-07-24 16:23 GMT+02:00 Owen Williams :

> How about we create a sub-branch of 1.12 and merge your work there, and
> then we can have others help out.  When it's in good shape we can merge
> it back into 1.12.  (That way 1.12 stays pristine while we are cleaning
> things up.)
>
> On Fri, 2015-07-24 at 16:11 +0200, S.Brandt wrote:
> > Hi,
> > Deere maintainer here.
> > My current dev branch: [1]
> > Fixes (mostly) all bugs for the skin listed: [2]
> > It merges cleanly [3], but i`ve submitted no PR yet since it is still
> > unfinished, some items on my todo.
> >
> >
> > Unfortunately, time is an major issue.
> >
> >
> > Suggestion?
> > Test the skin in its current state and comment and/or submit PR.
> >
> >
> > [1]:  https://github.com/esbrandt/mixxx/tree/deere_updates
> > [2]:  https://blueprints.launchpad.net/mixxx/+spec/1.12-skins
> > [3]:
> >
> https://github.com/mixxxdj/mixxx/compare/1.12...esbrandt:deere_updates?expand=1
> > 
> > S.Brandt
> > Mixxx - Free Digital DJ Mixing Software
> > www.mixxx.org | Get Involved
> >
> > > On Jul 23, 2015, at 8:28 PM, Ferran Pujol Camins
> > >  wrote:
> > >
> > > Hello, I thought I could put some love to Deere. But before I start
> > > to commit things that may not be appropriate, I would like to know
> > > if there are any specific plans for it. Whose the maintainer? Any
> > > suggestions?
> >
> >
> >
> --
> > ___
> > 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
>
>
>
--
___
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

[Mixxx-devel] Deere state

[Ferran Pujol Camins]

Hello, I thought I could put some love to Deere. But before I start to
commit things that may not be appropriate, I would like to know if there
are any specific plans for it. Whose the maintainer? Any suggestions?
--
___
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] 1.12 release progress

[Ferran Pujol Camins]

Well, you've already reviewed PR #639
<https://github.com/mixxxdj/mixxx/pull/639>, you might want to check one
more time. The only issue I see to it is that sometimes the show library
option on the view menu does nothing. But, AFAIK, the skin has no way to
tell Mixxx when this option should be grayed out and when it should be
active.

2015-07-22 23:02 GMT+02:00 Owen Williams :

> For PRs that people think are ready and would like to merge in, can you
> list the actual numbers?  Our PR list is very dense and fast-moving.
>
> I am willing to take a look at the PRs that are in flight, but I can't
> guarantee that I will agree that everything is low risk or ready to
> merge.  If people trust me enough to make that decision then the process
> can work, but if not then I'd rather not spend the time doing the
> review.  If someone asks for my review and they don't like the answer,
> then they didn't want a review, they wanted a rubber stamp :).  I am
> admittedly quite conservative when it comes to LGTMing a PR for the
> beta, but I'd argue that's what we need.
>
> It would also be nice if our milestone list was more realistic:
> https://launchpad.net/mixxx/+milestone/1.12.0  There are tons of bugs
> targeted to 1.12 that will not get fixed and shouldn't block the
> release.  I'd like people to go through the list and remove the target
> milestone if they don't think a bug should really block the release.
> (Don't switch the milestone to the next version either, just remove it.)
> This even goes for crashers that are just too hard to reproduce.
>
> For instance, as much as it annoys me that the analyze pane doesn't pick
> up the custom font choice, it's not worth blocking over.
> (https://bugs.launchpad.net/mixxx/+bug/1427368)
>
> Owen
>
> On Wed, 2015-07-22 at 10:50 -0500, Be wrote:
> > Most of the issues listed by Sebastian and I are low risk and pretty
> > much ready to merge. The points that aren't being addressed yet are the
> > flaky broadcasting connection, Opus crash, and library search bar focus
> > issue. I'd be fine merging the key sorting as is without polishing it
> > for the Lancelot notation system if that's not ready by release time.
> >
> > On 07/22/2015 09:12 AM, RJ Ryan wrote:
> > > Daniel/RAWRR are right -- the goal posts are moving slightly and we're
> > > scope creeping.
> > >
> > > Active, trivial / low-risk PRs can merge if they are ready but
> shouldn't
> > > be blocking.
> > >
> > > For me, the final blocker is the manual and website / press material --
> > > which we simply can't launch without. :)
> > >
> > > Best regards,
> > > RJ
> > >
> > > On Wed, Jul 22, 2015 at 8:11 AM, Ferran Pujol Camins
> > > mailto:ferranpujolcam...@gmail.com>>
> wrote:
> > >
> > >  From my point of view, marketing wise, we could consider 1.12 a
> > > modest release. Because despite the huge amount of work there's
> > > behind it, every review out there will essentially say "it is great
> > > and finally have FX, but the built in FX are weak".
> > >
> > > So my modest opinion is the same that Daniel.
> > >
> > > El dia 22/07/2015 12:16,  > > <mailto:re-cy...@hushmail.com>> va escriure:
> > >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > >
> > >
> > > On Wed, 22 Jul 2015 06:28:38 + "Daniel Schürmann"
> > > mailto:dasch...@mixxx.org>> wrote:
> > >  >Hi,
> > >  >
> > >  >We have to be careful to consider what is a release blocker.
> > >  >Mixxx 1.12 beta is already so much better than 1.11 that it
> is not
> > >  >worth to
> > >  >block it at all from this point of view.
> > >  >
> > >  >Of cause we should try to fix all critical bugs before a
> release
> > >  >date, but
> > >  >in this stage I consider a
> > >  >release blocker only a regression that prevents one from
> using
> > >  >1.12.
> > >  >>From this point of view only this one is a blocker:
> > >  >* flaky broadcasting connections: LP 1277274
> > >  >
> > >  >The other topics are its the over all quality issue.
> > >  >
> > >  >Everyone can 

Re: [Mixxx-devel] 1.12 release progress

[Ferran Pujol Camins]

Are the manual sources updated? I can translate to Spanish and Catalan but
I'd like to wait until I know the sources won't change anymore (or change
very slightly).

2015-07-22 16:12 GMT+02:00 RJ Ryan :

> Daniel/RAWRR are right -- the goal posts are moving slightly and we're
> scope creeping.
>
> Active, trivial / low-risk PRs can merge if they are ready but shouldn't
> be blocking.
>
> For me, the final blocker is the manual and website / press material --
> which we simply can't launch without. :)
>
> Best regards,
> RJ
>
>
> On Wed, Jul 22, 2015 at 8:11 AM, Ferran Pujol Camins <
> ferranpujolcam...@gmail.com> wrote:
>
>> From my point of view, marketing wise, we could consider 1.12 a modest
>> release. Because despite the huge amount of work there's behind it, every
>> review out there will essentially say "it is great and finally have FX, but
>> the built in FX are weak".
>>
>> So my modest opinion is the same that Daniel.
>> El dia 22/07/2015 12:16,  va escriure:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>>
>>>
>>> On Wed, 22 Jul 2015 06:28:38 + "Daniel Schürmann"
>>>  wrote:
>>> >Hi,
>>> >
>>> >We have to be careful to consider what is a release blocker.
>>> >Mixxx 1.12 beta is already so much better than 1.11 that it is not
>>> >worth to
>>> >block it at all from this point of view.
>>> >
>>> >Of cause we should try to fix all critical bugs before a release
>>> >date, but
>>> >in this stage I consider a
>>> >release blocker only a regression that prevents one from using
>>> >1.12.
>>> >>From this point of view only this one is a blocker:
>>> >* flaky broadcasting connections: LP 1277274
>>> >
>>> >The other topics are its the over all quality issue.
>>> >
>>> >Everyone can already use 1.12 beta. What is the difference to a
>>> >1.12
>>> >release?
>>> >IMHO it is all the shiny stuff that makes the difference from a
>>> >project to
>>> >a product.
>>> >It is marketing, design, manual, advertising texts, screen shots
>>> >and so on.
>>> >A product with good maketing/design is always considered as high
>>> >quality,
>>> >regardless
>>> >of the number of critical bugs.
>>> >
>>> >Unfortunately marketing experts are rare among our contributors.
>>> >Any Idea to change this?
>>> >
>>>
>>> Yeah.
>>>
>>> If the betas really are that close, arrive at a consensus regarding
>>> some reasonable candidate among these beta versions to designate as
>>> a release, publish it, and continue on behind the scenes
>>> developing, like you do.
>>>
>>> Mixxx is marketed really well already. If you are thinking
>>> representation to the public is unclear, consider that perception
>>> will be clarified when the download page has a "release", and
>>> further accentuated with the usual rounds of well-crafted press
>>> submissions to various DJ industry and tech sites and magazines
>>> (which one of you folks usually does that anyway?).
>>>
>>> It seems like everyone in development wants 1.12 to be a singular,
>>> glorious debut - but I think looking for that misses the mark.
>>> There is an actual glorious debut, but it was and is the momentum
>>> in productivity that fired up six months or so ago and will push
>>> all the way through 1.12 to the continuing evolution of the
>>> project, and a more modern style of development cycle.
>>>
>>> 
>>>
>>> Also my personal two cents about the roadmap (apologies if it is
>>> off-base): I think new feature sprawl might be happening? If so, I
>>> myself probably contributed to it. I know this observation won't be
>>> popular!! Everyone wants and loves new features. But I think many
>>> of the debates going on will be less exasperating and more
>>> manageable when there are fewer projects underway in general.
>>> Between 1.11 and 1.12, so much got piled on the plate!! Even as
>>> someone without responsibilities free to simply observe, I find it
>>> difficult to keep track of all the threads underway.
>>>
>>> ~RAWRR
>>>
>>> >Kind regards,
>>> >

Re: [Mixxx-devel] 1.12 release progress

[Ferran Pujol Camins]

>From my point of view, marketing wise, we could consider 1.12 a modest
release. Because despite the huge amount of work there's behind it, every
review out there will essentially say "it is great and finally have FX, but
the built in FX are weak".

So my modest opinion is the same that Daniel.
El dia 22/07/2015 12:16,  va escriure:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> On Wed, 22 Jul 2015 06:28:38 + "Daniel Schürmann"
>  wrote:
> >Hi,
> >
> >We have to be careful to consider what is a release blocker.
> >Mixxx 1.12 beta is already so much better than 1.11 that it is not
> >worth to
> >block it at all from this point of view.
> >
> >Of cause we should try to fix all critical bugs before a release
> >date, but
> >in this stage I consider a
> >release blocker only a regression that prevents one from using
> >1.12.
> >>From this point of view only this one is a blocker:
> >* flaky broadcasting connections: LP 1277274
> >
> >The other topics are its the over all quality issue.
> >
> >Everyone can already use 1.12 beta. What is the difference to a
> >1.12
> >release?
> >IMHO it is all the shiny stuff that makes the difference from a
> >project to
> >a product.
> >It is marketing, design, manual, advertising texts, screen shots
> >and so on.
> >A product with good maketing/design is always considered as high
> >quality,
> >regardless
> >of the number of critical bugs.
> >
> >Unfortunately marketing experts are rare among our contributors.
> >Any Idea to change this?
> >
>
> Yeah.
>
> If the betas really are that close, arrive at a consensus regarding
> some reasonable candidate among these beta versions to designate as
> a release, publish it, and continue on behind the scenes
> developing, like you do.
>
> Mixxx is marketed really well already. If you are thinking
> representation to the public is unclear, consider that perception
> will be clarified when the download page has a "release", and
> further accentuated with the usual rounds of well-crafted press
> submissions to various DJ industry and tech sites and magazines
> (which one of you folks usually does that anyway?).
>
> It seems like everyone in development wants 1.12 to be a singular,
> glorious debut - but I think looking for that misses the mark.
> There is an actual glorious debut, but it was and is the momentum
> in productivity that fired up six months or so ago and will push
> all the way through 1.12 to the continuing evolution of the
> project, and a more modern style of development cycle.
>
> 
>
> Also my personal two cents about the roadmap (apologies if it is
> off-base): I think new feature sprawl might be happening? If so, I
> myself probably contributed to it. I know this observation won't be
> popular!! Everyone wants and loves new features. But I think many
> of the debates going on will be less exasperating and more
> manageable when there are fewer projects underway in general.
> Between 1.11 and 1.12, so much got piled on the plate!! Even as
> someone without responsibilities free to simply observe, I find it
> difficult to keep track of all the threads underway.
>
> ~RAWRR
>
> >Kind regards,
> >
> >Daniel
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >2015-07-22 7:55 GMT+02:00 Be :
> >
> >>
> >>
> >> On 07/22/2015 12:00 AM, Sébastien BLAISOT wrote:
> >> > Hi all,
> >> >
> >> > Some more blockers :
> >> >
> >> > * (win) installing 1.12 on top of a previous version
> >installation
> >> > (lp:1457618) => PR621 is *still* waiting for merge. Please
> >review and
> >> > discuss if we move version to beta2
> >> >
> >> > * (win) Eject symbol not shown in LateNight skin (lp:1454649)
> >=> PR627
> >> > is *still* waiting for review and merge
> >>
> >> Who can review these? Who uses Windows?
> >>
> >> > About startup time, I noticed, under windows, that startup
> >time is
> >> > *very* long if I have network shares mounted and a slow (like
> >> > slooow) network connection. Mixxx probably tries to
> >enumerate all
> >> > drives at startup, even network ones. I think it should be
> >limited to
> >> > local drives. Launch time is short if I unmount network shares
> >before
> >> > launching mixxx. Hope this can be of any help in sorting out
> >this issue.
> >>
> >> Why does Mixxx need to enumerate all drives at startup?
> >Shouldn't it
> >> only need to enumerate drives that the library is configured to
> >scan in?
> >>
> >> > ---
> >> > Sébastien Blaisot
> >> >
> >> > Le 22/07/2015 00:03, Be a écrit :
> >> >
> >> >> Where are we now? Let's make a list of release blockers:
> >> >> * skin polish: Ferran's updates to LateNight in PR #639 is a
> >good step
> >> >> and he said he'd work on Deere too
> >> >> * weird bug with library search bar focus in LateNight:
> >> >> https://bugs.launchpad.net/mixxx/+bug/1462061
> >> >> * Startup time: Mixxx takes a long time to start up on some
> >systems. PR
> >> >> #655 and PR #650 will alleviate the issue without risking
> >regressions 

[Mixxx-devel] Additional effect racks from controller script

[Ferran Pujol Camins]

Can a controller script create additional effects rack?
I mean for example, create a fifth effect rack even though it is not shown
in the GUI.
Is this currently possible?
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
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

[Mixxx-devel] slider scalemode

[Ferran Pujol Camins]

I'm working on a expandable/shrinkable slider. It's basically a size aware
stack of sliders of different sizes. I want each slider to be stretched
before the stack jumps to the next one. I've tried this, as seen on the
wiki:


rate

skin:expandable_pitch_slider/knob.svg
skin:expandable_pitch_slider/6.svg
false

[Channel1],rate



But this doesn't work, it makes the slider disappear. What I'm doing wrong?
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
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] Latenight widgetgroup borders

[Ferran Pujol Camins]

Here is a first attempt. What do you think?

https://github.com/mixxxdj/mixxx/pull/639

2015-07-01 22:15 GMT+02:00 Ferran Pujol Camins 
:

> Hi,
> I've changed LateNight so it now has independent controls for each deck
> spinny like the rest of the skins ([SpinnyN] show_spinny).
> However, now the play position indicator of the waveforms with the spinny
> hidden are not aligned with those that have the spinny visible.
>
> Can this be solved with the current code base?
>
> If the answer is not, I've thought that I could add a new integer element
> "" to  that would offset the playposition a
> given amount of pixels. Does the waveform engine currently support to
> offset the playposition?
>
> 2015-06-26 20:29 GMT+02:00 Ferran Pujol Camins <
> ferranpujolcam...@gmail.com>:
>
>> Nice, I'll start working on this as soon as I end my exams.
>>
>> 2015-06-26 20:11 GMT+02:00 Owen Williams :
>>
>>> If we're targeting the master branch I think that sounds ok.  Definitely
>>> all the skins will have to support all of the UI switches, or else there
>>> will have to be design work for how a skin can tell Mixxx which UI
>>> switches it supports.
>>>
>>>
>>> On Fri, 2015-06-26 at 20:00 +0200, Ferran Pujol Camins wrote:
>>> > I can try to add the hide/show crossfader feature to deere and Shade
>>> > too.
>>> >
>>> >
>>> >
>>> > Just to see if we have some kind of consensus. Would you be happy with
>>> > a pull request that:
>>> >
>>> >
>>> > 1 - Removes the top layout options buttons bar (where to place the
>>> > latency bar and the clock is to be discussed, lets imagine for now
>>> > that there's a place we all like to put these two things).
>>> >
>>> >
>>> > 2 - Adds the hide/show crossfader feature to Shade and LateNight
>>> > (Deere? it's all messed up, maybe it doesn't make sense to add this
>>> > without knowing if the layout it has right now is definitive)
>>> >
>>> >
>>> > 3 - Adds to the view menu the missing layout options (show/hide
>>> > crossfader, EQ, mixer, library, spinnies and 2/4 decks) and maybe find
>>> > a more logical order and grouping for it.
>>> >
>>> >
>>> > The next logical step would be to add hide/show EQ to shade (and
>>> > Deere?)
>>> >
>>> >
>>> > 2015-06-26 19:18 GMT+02:00 Owen Williams :
>>> > The top row of selectors is not ideal, I agree.  But adding
>>> > skin-specific options to app-wide menus gets painful quickly.
>>> > If you add
>>> > "hide crossfader" to the menu you'll also have to add support
>>> > for hidden
>>> > crossfader to Deere and Shade as well. Otherwise people using
>>> > those
>>> > skins will file bugs saying they tried to hide the crossfader
>>> > and it's
>>> > not working.  So unless you are committed to adding show/hide
>>> > options
>>> > for eqs, crossfader, and whatever else to all three skins,
>>> > your PR has
>>> > no chance of being accepted.
>>> >
>>> > owen
>>> >
>>> > On Fri, 2015-06-26 at 19:05 +0200, Ferran Pujol Camins wrote:
>>> > > Agree. The "performance-critical" layout options are already
>>> > grouped
>>> > > together on the lower side and we don't to touch them.
>>> > > We are talking about removing only those buttons that appear
>>> > on the
>>> > > upper side of the skin. They are likely to be setup once and
>>> > not be
>>> > > changed again during a performance, so they waste a little
>>> > amount of
>>> > > space and are a visuall clutter from my point of view.
>>> > >
>>> > >
>>> > > 2015-06-26 18:44 GMT+02:00 Mel Grubb :
>>> > > I think there are some buttons that should be
>>> > > available directly on the UI because they represent
>>> > things
>>> > > that are needed during a performance. Toggling
>>> > samplers on and
>&

Re: [Mixxx-devel] Keyboard shortcuts

[Ferran Pujol Camins]

Thank you Daniel,

I've finally been able (I think) to find the appropriate characters to put
on each locale keyboard file to make it work. I've tested it in my gnome
desktop changing the keyboard language. However, the reason why it works
this way is black magic to me:

LocaleCharacter printed by the keyCharacter I had to put on the keyboard
file to make it work correctlycs_CZ='da_DK+'de_CH''de_DEß+el_GR-+en_US-'
es_ES''fi_FI++fr_CH''fr_FR)'it_IT''ru_RU--



2015-07-02 8:26 GMT+02:00 Daniel Schürmann :

> Hi Ferran,
>
> that the reason why
> we ship keyboard mappings for different keyboard layouts.
>
> So you may do it similar to:
>
> https://github.com/mixxxdj/mixxx/blob/afb21edd6f8ce295ec83f4f8d2406e8fede42b06/src/mixxx.cpp#L1438
>
> See also: http://doc.qt.io/qt-5/qkeysequence.html#keyboard-layout-issues
>
> Hope that helps.
>
> Kind regards,
>
> Daniel
>
>
>
> 2015-07-02 2:48 GMT+02:00 Ferran Pujol Camins  >:
>
>> Hi,
>>
>> I've added entries to the view menu and I've run out of numbers to assign
>> the keyboard shortcuts, so I've decided to also use the key next to the 0.
>>
>> The problem is that I can't make the shortcut work for some locales:
>>
>> Localesymbol in that keyworks?
>> cs_CZ   = No
>> da_DK   + No
>> de_CH' Yes
>> de_DE   ß No
>> el_GR-  No
>> en_US   -  No
>> es_ES'  Yes
>> fi_FI   + No
>> fr_CH  ) No
>> fr_FR  )  No
>> it_IT'  Yes
>> ru_RU  - No
>>
>> As you can see only the locales that have an apostrophe there work.
>>
>> The parsed shortcut matches the shortcut detected when pressing the keys:
>> e.g.
>> on en_US locale, I get:
>>
>> *Debug [Main]: control: "ViewMenu_ShowCoverArt" value: "Ctrl+-"*
>>
>> on Mixxx start and:
>>
>> *Debug [Main]: keyboard press:  "Ctrl+-"*
>>
>> when pressing the keys.
>>
>> Changing to for example "Ctrl+a" makes it work.
>>
>> Any hint on what's wrong?
>>
>>
>> --
>> Don't Limit Your Business. Reach for the Cloud.
>> GigeNET's Cloud Solutions provide you with the tools and support that
>> you need to offload your IT needs and focus on growing your business.
>> Configured For All Businesses. Start Your Cloud Today.
>> https://www.gigenetcloud.com/
>> ___
>> 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
>>
>
>
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
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

[Mixxx-devel] Keyboard shortcuts

[Ferran Pujol Camins]

Hi,

I've added entries to the view menu and I've run out of numbers to assign
the keyboard shortcuts, so I've decided to also use the key next to the 0.

The problem is that I can't make the shortcut work for some locales:

Localesymbol in that keyworks?
cs_CZ   = No
da_DK   + No
de_CH' Yes
de_DE   ß No
el_GR-  No
en_US   -  No
es_ES'  Yes
fi_FI   + No
fr_CH  ) No
fr_FR  )  No
it_IT'  Yes
ru_RU  - No

As you can see only the locales that have an apostrophe there work.

The parsed shortcut matches the shortcut detected when pressing the keys:
e.g.
on en_US locale, I get:

*Debug [Main]: control: "ViewMenu_ShowCoverArt" value: "Ctrl+-"*

on Mixxx start and:

*Debug [Main]: keyboard press:  "Ctrl+-"*

when pressing the keys.

Changing to for example "Ctrl+a" makes it work.

Any hint on what's wrong?
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
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] Latenight widgetgroup borders

[Ferran Pujol Camins]

Hi,
I've changed LateNight so it now has independent controls for each deck
spinny like the rest of the skins ([SpinnyN] show_spinny).
However, now the play position indicator of the waveforms with the spinny
hidden are not aligned with those that have the spinny visible.

Can this be solved with the current code base?

If the answer is not, I've thought that I could add a new integer element
"" to  that would offset the playposition a
given amount of pixels. Does the waveform engine currently support to
offset the playposition?

2015-06-26 20:29 GMT+02:00 Ferran Pujol Camins 
:

> Nice, I'll start working on this as soon as I end my exams.
>
> 2015-06-26 20:11 GMT+02:00 Owen Williams :
>
>> If we're targeting the master branch I think that sounds ok.  Definitely
>> all the skins will have to support all of the UI switches, or else there
>> will have to be design work for how a skin can tell Mixxx which UI
>> switches it supports.
>>
>>
>> On Fri, 2015-06-26 at 20:00 +0200, Ferran Pujol Camins wrote:
>> > I can try to add the hide/show crossfader feature to deere and Shade
>> > too.
>> >
>> >
>> >
>> > Just to see if we have some kind of consensus. Would you be happy with
>> > a pull request that:
>> >
>> >
>> > 1 - Removes the top layout options buttons bar (where to place the
>> > latency bar and the clock is to be discussed, lets imagine for now
>> > that there's a place we all like to put these two things).
>> >
>> >
>> > 2 - Adds the hide/show crossfader feature to Shade and LateNight
>> > (Deere? it's all messed up, maybe it doesn't make sense to add this
>> > without knowing if the layout it has right now is definitive)
>> >
>> >
>> > 3 - Adds to the view menu the missing layout options (show/hide
>> > crossfader, EQ, mixer, library, spinnies and 2/4 decks) and maybe find
>> > a more logical order and grouping for it.
>> >
>> >
>> > The next logical step would be to add hide/show EQ to shade (and
>> > Deere?)
>> >
>> >
>> > 2015-06-26 19:18 GMT+02:00 Owen Williams :
>> > The top row of selectors is not ideal, I agree.  But adding
>> > skin-specific options to app-wide menus gets painful quickly.
>> > If you add
>> > "hide crossfader" to the menu you'll also have to add support
>> > for hidden
>> > crossfader to Deere and Shade as well. Otherwise people using
>> > those
>> > skins will file bugs saying they tried to hide the crossfader
>> > and it's
>> > not working.  So unless you are committed to adding show/hide
>> > options
>> > for eqs, crossfader, and whatever else to all three skins,
>> > your PR has
>> > no chance of being accepted.
>> >
>> > owen
>> >
>> > On Fri, 2015-06-26 at 19:05 +0200, Ferran Pujol Camins wrote:
>> > > Agree. The "performance-critical" layout options are already
>> > grouped
>> > > together on the lower side and we don't to touch them.
>> > > We are talking about removing only those buttons that appear
>> > on the
>> > > upper side of the skin. They are likely to be setup once and
>> > not be
>> > > changed again during a performance, so they waste a little
>> > amount of
>> > > space and are a visuall clutter from my point of view.
>> > >
>> > >
>> > > 2015-06-26 18:44 GMT+02:00 Mel Grubb :
>> > > I think there are some buttons that should be
>> > > available directly on the UI because they represent
>> > things
>> > > that are needed during a performance. Toggling
>> > samplers on and
>> > > off is one example. I want to drop down the samplers
>> > only when
>> > > needed, but then I want them out of my way. For
>> > consistency, I
>> > > think all visibility toggles should all be available
>> > on the
>> > >     View menu, but only the critical "Live" ones should
>> > be taking
>> > > up space on the UI.
>> &

Re: [Mixxx-devel] Latenight widgetgroup borders

[Ferran Pujol Camins]

Nice, I'll start working on this as soon as I end my exams.

2015-06-26 20:11 GMT+02:00 Owen Williams :

> If we're targeting the master branch I think that sounds ok.  Definitely
> all the skins will have to support all of the UI switches, or else there
> will have to be design work for how a skin can tell Mixxx which UI
> switches it supports.
>
>
> On Fri, 2015-06-26 at 20:00 +0200, Ferran Pujol Camins wrote:
> > I can try to add the hide/show crossfader feature to deere and Shade
> > too.
> >
> >
> >
> > Just to see if we have some kind of consensus. Would you be happy with
> > a pull request that:
> >
> >
> > 1 - Removes the top layout options buttons bar (where to place the
> > latency bar and the clock is to be discussed, lets imagine for now
> > that there's a place we all like to put these two things).
> >
> >
> > 2 - Adds the hide/show crossfader feature to Shade and LateNight
> > (Deere? it's all messed up, maybe it doesn't make sense to add this
> > without knowing if the layout it has right now is definitive)
> >
> >
> > 3 - Adds to the view menu the missing layout options (show/hide
> > crossfader, EQ, mixer, library, spinnies and 2/4 decks) and maybe find
> > a more logical order and grouping for it.
> >
> >
> > The next logical step would be to add hide/show EQ to shade (and
> > Deere?)
> >
> >
> > 2015-06-26 19:18 GMT+02:00 Owen Williams :
> > The top row of selectors is not ideal, I agree.  But adding
> > skin-specific options to app-wide menus gets painful quickly.
> > If you add
> > "hide crossfader" to the menu you'll also have to add support
> > for hidden
> > crossfader to Deere and Shade as well. Otherwise people using
> > those
> > skins will file bugs saying they tried to hide the crossfader
> > and it's
> >     not working.  So unless you are committed to adding show/hide
> > options
> > for eqs, crossfader, and whatever else to all three skins,
> > your PR has
> > no chance of being accepted.
> >
> > owen
> >
> > On Fri, 2015-06-26 at 19:05 +0200, Ferran Pujol Camins wrote:
> > > Agree. The "performance-critical" layout options are already
> > grouped
> > > together on the lower side and we don't to touch them.
> > > We are talking about removing only those buttons that appear
> > on the
> > > upper side of the skin. They are likely to be setup once and
> > not be
> > > changed again during a performance, so they waste a little
> > amount of
> > > space and are a visuall clutter from my point of view.
> > >
> > >
> > > 2015-06-26 18:44 GMT+02:00 Mel Grubb :
> > > I think there are some buttons that should be
> > > available directly on the UI because they represent
> > things
> > > that are needed during a performance. Toggling
> > samplers on and
> > > off is one example. I want to drop down the samplers
> > only when
> > > needed, but then I want them out of my way. For
> > consistency, I
> > > think all visibility toggles should all be available
> > on the
> > > View menu, but only the critical "Live" ones should
> > be taking
> > > up space on the UI.
> > >
> > > > Date: Fri, 26 Jun 2015 11:31:22 -0500
> > > > From: b...@gmx.com
> > > > To: ferranpujolcam...@gmail.com
> > > > CC: mixxx-devel@lists.sourceforge.net
> > > > Subject: Re: [Mixxx-devel] Latenight widgetgroup
> > borders
> > > >
> > > > There already is the View menu. I am in favor of
> > getting rid
> > > of all the
> > > > on-skin buttons and keeping all those options in
> > the View
> > > menu.
> > > >
> > > > On 06/26/2015 10:52 AM, Ferran Pujol Camins wrote:
> > > > > Excuse my stubbornness but:
> > >

Re: [Mixxx-devel] Latenight widgetgroup borders

[Ferran Pujol Camins]

I can try to add the hide/show crossfader feature to deere and Shade too.

Just to see if we have some kind of consensus. Would you be happy with a
pull request that:

1 - Removes the top layout options buttons bar (where to place the latency
bar and the clock is to be discussed, lets imagine for now that there's a
place we all like to put these two things).

2 - Adds the hide/show crossfader feature to Shade and LateNight (Deere?
it's all messed up, maybe it doesn't make sense to add this without knowing
if the layout it has right now is definitive)

3 - Adds to the view menu the missing layout options (show/hide crossfader,
EQ, mixer, library, spinnies and 2/4 decks) and maybe find a more logical
order and grouping for it.

The next logical step would be to add hide/show EQ to shade (and Deere?)

2015-06-26 19:18 GMT+02:00 Owen Williams :

> The top row of selectors is not ideal, I agree.  But adding
> skin-specific options to app-wide menus gets painful quickly. If you add
> "hide crossfader" to the menu you'll also have to add support for hidden
> crossfader to Deere and Shade as well. Otherwise people using those
> skins will file bugs saying they tried to hide the crossfader and it's
> not working.  So unless you are committed to adding show/hide options
> for eqs, crossfader, and whatever else to all three skins, your PR has
> no chance of being accepted.
>
> owen
>
> On Fri, 2015-06-26 at 19:05 +0200, Ferran Pujol Camins wrote:
> > Agree. The "performance-critical" layout options are already grouped
> > together on the lower side and we don't to touch them.
> > We are talking about removing only those buttons that appear on the
> > upper side of the skin. They are likely to be setup once and not be
> > changed again during a performance, so they waste a little amount of
> > space and are a visuall clutter from my point of view.
> >
> >
> > 2015-06-26 18:44 GMT+02:00 Mel Grubb :
> > I think there are some buttons that should be
> > available directly on the UI because they represent things
> > that are needed during a performance. Toggling samplers on and
> > off is one example. I want to drop down the samplers only when
> > needed, but then I want them out of my way. For consistency, I
> > think all visibility toggles should all be available on the
> > View menu, but only the critical "Live" ones should be taking
> > up space on the UI.
> >
> > > Date: Fri, 26 Jun 2015 11:31:22 -0500
> > > From: b...@gmx.com
> > > To: ferranpujolcam...@gmail.com
> > > CC: mixxx-devel@lists.sourceforge.net
> > > Subject: Re: [Mixxx-devel] Latenight widgetgroup borders
> >     >
> > > There already is the View menu. I am in favor of getting rid
> > of all the
> > > on-skin buttons and keeping all those options in the View
> > menu.
> > >
> > > On 06/26/2015 10:52 AM, Ferran Pujol Camins wrote:
> > > > Excuse my stubbornness but:
> > > > I've already managed to correct the border issue, thank
> > you. I'm now
> > > > trying to implement Mel's idea.
> > > > My first naive solution is a new button at the left side
> > that toggles
> > > > the visibility of the others. This has the problem that
> > the number and
> > > > size of buttons is still limited by the width of the mixer
> > section.
> > > >
> > > > A drop-down menu would be better. Can the current skin
> > engine support
> > > > overlapping or "floating" widgetgroups?
> > > >
> > > > Another alternative is to add a new "Layout" menu to the
> > window menu
> > > > bar. Wouldn't you feel comfortable with it? Do you really
> > need to have
> > > > these buttons right on the skin?
> > > >
> > > > 2015-06-25 18:36 GMT+02:00 Be  > <mailto:b...@gmx.com>>:
> > > >
> > > > On 06/25/2015 10:59 AM, Mel Grubb wrote:
> > > > > Perhaps another choice might be a single "visibility"
> > button on the UI
> > > > > (Maybe an eyeball icon?) that drops down a checklist (or
> > multiple, one
> > > > > for each deck)