[Mixxx-devel] Mixxx 2.2.2 released

[Daniel Schürmann]

Hi,

Mixxx 2.2.2 has been released and is available on the download page:
https://www.mixxx.org/download/

This release includes many stability and usability fixes. Please note that
we had to disable writing of file tags for .ogg files with the current
TagLib version 1.11.1 that would otherwise corrupt your precious files.
Upgrading from version 2.2.1 is strongly recommended.

The Changelog with a detailed list of changes can be found here:
https://github.com/mixxxdj/mixxx/blob/2.2/CHANGELOG

I want to thank all contributors who have made this release possible, by
spending a huge amount of their spare time working on Mixxx for free.

If you are interested to help as well, or have you favorite feature
realized, say hello at https://mixxx.zulipchat.com/

Best 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] Mixxx 2.1.8 released!

[Daniel Schürmann]

For users who have had trouble with version 2.2, we have been continuing to
support version 2.1 with minor updates like this. We still recommend
version 2.1 for users on MacOS, Windows XP, or Ubuntu Trusty. Go get it:
https://mixxx.org/download/#previous 
___
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] Mac users: please help testing 2.1.8 RC

[Daniel Schürmann]

Hi Mixxx users on Mac,

We are fighting a hard to catch bug with dropping tracks from finders. We
have prepared a 2.1.8 release candidate with more debug info:
http://downloads.mixxx.org/builds/2.1/release/mixxx-2.1.8-2.1-release-macintel64-latest.dmg
please test "drag and drop" from various sources. Please test tracks that
are in the library and tracks which are not by e.g. duplicate an existing
track on the hd first.
If something fails please quit Mixxx and send the mixxx.log to me.
https://www.mixxx.org/wiki/doku.php/finding_the_mixxx.log_file

If you discover other issues, please report as well.

Thank you for you help.

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] Mixxx-devel Digest, Vol 149, Issue 2

[Daniel Schürmann]

Hi Darren,

We have found the issue. We are working on a release. If you like, you can
use the release candidate
http://downloads.mixxx.org/builds/2.1/release/mixxx-2.1.8-2.1-git6823-release-x64.exe

Kind regards,

Daniel

Darren Oliver via Mixxx-devel  schrieb
am Mo., 25. März 2019, 13:30:

> I am currently using 2.1.16 and I still have the same ISSUE OF NO TRACK
> INFO?
>
> On Monday, March 25, 2019, 7:16:20 AM CDT, <
> mixxx-devel-requ...@lists.sourceforge.net> wrote:
>
>
> Send Mixxx-devel mailing list submissions to
> mixxx-devel@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
> or, via email, send a message with subject or body 'help' to
> mixxx-devel-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
> mixxx-devel-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mixxx-devel digest..."
>
>
> Today's Topics:
>
>   1. erratic going offline and no now playing info (Darren Oliver)
>
>
> --
>
> Message: 1
> Date: Mon, 25 Mar 2019 12:15:40 + (UTC)
> From: Darren Oliver 
> To: mixxx-devel@lists.sourceforge.net
> Subject: [Mixxx-devel] erratic going offline and no now playing info
> Message-ID: <226570771.10871613.1553516140...@mail.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
>
> Now i have been with you Guy's for four years and I have for 4 years have
> the issue with the player going off line with no warning also while using
> the 1.0 version my now playing track info would work after upgrading to the
> 2.0 version it has stopped working and my LISTENERS COMPLAIN ABOUT BOTH
> ISSUES WHEN WILL I GET A ANSWER FOR BOOTH OF THESE ISSUES ??waiting
> PATIENTLY.Darren Oliver/ Skook Bros. Radio
> -- next part --
> An HTML attachment was scrubbed...
> -- next part --
> A non-text attachment was scrubbed...
> Name: Screenshot (9).png
> Type: image/png
> Size: 237171 bytes
> Desc: not available
>
> --
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> Get Mixxx, the #1 Free MP3 DJ software Today
> http://mixxx.org
>
> Mixxx-devel mailing list
> Mixxx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
>
> --
>
> End of Mixxx-devel Digest, Vol 149, Issue 2
> ***
> ___
> 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] erratic going offline and no now playing info

[Daniel Schürmann]

Hi Darren,

I guess that is caused by a faulty track.
Can you recall which track the Auto DJ was trying to load when the crash
happens? I think it is still listed as #1 under the pop-up.

Does it also crash when you load this track manually?

Please post the mixxx.log from the crashing run. By luck it is still there
with a number prefix.

https://www.mixxx.org/wiki/doku.php/finding_the_mixxx.log_file

Kind regards,

Daniel


Darren Oliver via Mixxx-devel  schrieb
am Mo., 25. März 2019, 13:16:

> Now i have been with you Guy's for four years and I have for 4 years have
> the issue with the player going off line with no warning also while using
> the 1.0 version my now playing track info would work after upgrading to the
> 2.0 version it has stopped working and my LISTENERS COMPLAIN ABOUT BOTH
> ISSUES WHEN WILL I GET A ANSWER FOR BOOTH OF THESE ISSUES ??
> waiting PATIENTLY.
> Darren Oliver/ Skook Bros. Radio
> ___
> 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] GIT etiquette

[Daniel Schürmann]

Hi Javi,

you can call you branch as you like.

In general you should branch from the HEAD of the lowest effected branch 
if unsure. This way we can finally decide just before merge in which 
branch the bug should go.

If it is obvious that it will go to 2.3, you can branch from master.

The only etiquette rule we have, is not to rebase if a review is in 
progress.


Thank you for picking up a bug.

Kind regards,

Daniel


Am 22.09.2018 um 13:12 schrieb javier.vilarr...@gmail.com:

Hi.

Just a fast question.

Any etiquette rule on how to name GIT branches?

And from where to branch? I mean, the bug I want to work on has been
assigned to milestone 2.3.0. Do I branch from master or do I branch
from somewhere else?

Thanks in advance :)

Javi



___
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] Mixxx 2.1.2 released!

[Daniel Schürmann]

Hi Developers,

the original release-2.1.2 tag and tar ball link are
accidentally pointing the master branch.

This is fixed now. If you have already fetched from upstream,
please call:

git tag -d release-2.1.2
git fetch upstream

to fix this is your local repo as well.
I am sorry for this.

Kind regards,

Daniel

Am 19.08.2018 um 13:42 schrieb Daniel Schürmann:

Hi Developers,

I am happy to announce Mixxx 2.1.2.

Here is a quick summary of what is new in Mixxx 2.1.2:

* Allow maximum deck speed of 4x normal
* Don't always quantize hotcues, a 2.1.1 regression lp1777429
* Fix artifacts using more than 32 samplers lp1779559
* store No EQ and Filter persistently lp1780479
* Pad unreadable samples with silence on cache miss lp1777480
* Fixing painting of preview coloumn for Qt5 builds lp1776555
* LateNight: Fix play button right click lp1781829
* LateNight: Added missing sort up/down buttons
* Fix sampler play button tooltips lp1779468
* Shade: remove superfluid margins and padding in sampler.xml lp1773588
* Deere: Fix background-color code
* ITunes: Don't stop import in case of duplicated Playlists lp1783493

If you encounter any problems, please report at
https://bugs.launchpad.net/mixxx/+filebug

We are also working towards Mixxx 2.2.0 which will include new features 
and QT 5.
We will publish beta builds here soon: 
http://downloads.mixxx.org/builds/2.2/


You can already test Mixxx 2.2.0-alpha-pre found at:
http://downloads.mixxx.org/builds/master/release/
But please note, it is an untested alpha, not suitable to use live 
without thorough own testing.


Kind regards,

Daniel


--
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] Mixxx 2.1.2 released!

[Daniel Schürmann]

Hi Developers,

I am happy to announce Mixxx 2.1.2.

Here is a quick summary of what is new in Mixxx 2.1.2:

* Allow maximum deck speed of 4x normal
* Don't always quantize hotcues, a 2.1.1 regression lp1777429
* Fix artifacts using more than 32 samplers lp1779559
* store No EQ and Filter persistently lp1780479
* Pad unreadable samples with silence on cache miss lp1777480
* Fixing painting of preview coloumn for Qt5 builds lp1776555
* LateNight: Fix play button right click lp1781829
* LateNight: Added missing sort up/down buttons
* Fix sampler play button tooltips lp1779468
* Shade: remove superfluid margins and padding in sampler.xml lp1773588
* Deere: Fix background-color code
* ITunes: Don't stop import in case of duplicated Playlists lp1783493

If you encounter any problems, please report at
https://bugs.launchpad.net/mixxx/+filebug

We are also working towards Mixxx 2.2.0 which will include new features 
and QT 5.
We will publish beta builds here soon: 
http://downloads.mixxx.org/builds/2.2/


You can already test Mixxx 2.2.0-alpha-pre found at:
http://downloads.mixxx.org/builds/master/release/
But please note, it is an untested alpha, not suitable to use live 
without thorough own testing.


Kind regards,

Daniel

--
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] GSoC registration is open.

[Daniel Schürmann]

Hi,

If you are interested in a paid internship during your university holidays
this summer, you can now apply for Google Summer of Code 2018 and Mixxx at
g.co/gsoc.

Be sure to read our advises and ideas in our wiki: https://
www.mixxx.org/wiki/doku.php/gsoc2018ideas and discuss them with us at h
ttps://mixxx.zulipchat.com before you send you final project proposal.

For tips on writing an excellent proposal read the short Student Guide
 written by
Mentors, Org Administrators and former students.

Applications close Tuesday, March 27 at 16:00 UTC.  All final proposals
must be submitted before the deadline to be considered by the mentor
organizations.

If you are not a student, but you like to help us mentoring an exiting
student project, you are welcome to contact me directly.

Kind regards,

Daniel.
--
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] GSoC 2018

[Daniel Schürmann]

Hi

we where accepted for this years GSoC 2018

The Google Summer of Code, is an international program, funding students 
to work on FOSS projects. The program is open to university students 
aged 18 or over.


If you are interested to participate, read this:
https://www.mixxx.org/wiki/doku.php/gsocadvice

If you know a talented students wasting his semester break by any kind 
of rubber band work, forward this mail to him.


Kind regards,

Daniel


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

[Daniel Schürmann]

You can unsubscribe yourselves here:
https://sourceforge.net/projects/mixxx/lists/mixxx-devel/unsubscribe
I have just done it for you.


Am 18.01.2018 um 20:42 schrieb Lets talk about the music - talk show:
HEY remove me from your forum! I am not interested in getting your 
notifications, using your board or none of it. I thought this was 
taken care of all ready.



thanks,

Shels

On Thu, Jan 18, 2018 at 11:32 AM, Daniel Schürmann <dasch...@mixxx.org 
<mailto:dasch...@mixxx.org>> wrote:


Hi,

we are planning to participate GSoC 2018.
(Not sure if we will be accepted, though.)

So it is time to collect ideas for Student projects.

The project should be in ideal case attractive for the student,
mattering for Mixxx, independent from other features, commit-able
in steps, not too trivial and not to advanced.

Who has an idea?

Thank you.

Daniel


--
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
<mailto:Mixxx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<https://lists.sourceforge.net/lists/listinfo/mixxx-devel>




--
Website: LetsTalkAbouttheMusic.com 
<http://l.facebook.com/l.php?u=http%3A%2F%2FLetsTalkAbouttheMusic.com%2F=uAQEJWwBhAQEu-XaMg85hi9XVxBfH7iDzrKfzHqjsSrkhrA=AZNJHQQXFViG32P8bl-2A3b4CNj94bBjUisLf-p26X6yxhxIiGQd6jbOIAz9Z-ozz6CBksmeFjkgNpDERiqXiuBg43WuwJdMKdI1WhLkiZqwpIP1zB5QwM1TB6p_LD1-22NwuUgczmbuMzpOiAvSL1wm3iZj_uQDIwEBZz_ynRlGHlkcft0ro7-h0vnOS_7RH1iw0wA8ZQaQ8YW5PclaHJ7x=1>

Fb: LTATMRadio.com <http://ltatmradio.com/>
FB Group: LTATM Radio
Twitter: @LTATM_Radio
Spreaker.com 
<http://www.spreaker.com/user/ltatmradio>>letstalkaboutthemusic

Fundraiser: patreon.com/LTATMRADIO <https://www.patreon.com/LTATMRADIO>



--
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] GSoC 2018

[Daniel Schürmann]

Hi,

we are planning to participate GSoC 2018.
(Not sure if we will be accepted, though.)

So it is time to collect ideas for Student projects.

The project should be in ideal case attractive for the student, 
mattering for Mixxx, independent from other features, commit-able in 
steps, not too trivial and not to advanced.


Who has an idea?

Thank you.

Daniel

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

[Daniel Schürmann]

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" <dasch...@mixxx.org 
<mailto:dasch...@mixxx.org>> 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
<mailto:Mixxx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<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] building playlists in mixxx 2.1 alfa

[Daniel Schürmann]

Hi Ron,

do you use keyboard navigation?

It looks like there is a bug,that might be related to the new checkboxes 
in the crate menu.

Testing this, I have found two issues:
https://bugs.launchpad.net/mixxx/+bug/1740193
And:
https://bugs.launchpad.net/mixxx/+bug/1740196

Thank you,

Daniel




Am 26.12.2017 um 22:04 schrieb ron camron via Mixxx-devel:

Test driving mixxx 201 alfa for 64 bit windows.  Build released on the
22nd December.  I'm running mixxx using jaws and nvda screen readers.
I have noticed that i can now run mixxx 64 bit edition on my pc.  I
don't even need the qt accessible directories.  There were a couple of
other accessibility improvements as well.  Whether intention or a
happy accident, i'm definitely ready to see 2.0.1 released.  I have
noticed one snag though.  Forgive me if someone has already mentioned
this.  I do try to keep on top of all the messages but miss one or
two.  I can no longer add songs to playlist using the mixxx file
browser or "computer" as its now called.  I can neither create
playlists or add songs to existing playlists.  have anyone else
noticed this?

--
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] 2.1-beta1 and 2.2-alpha-pre are there.

[Daniel Schürmann]

Hi,

I am proud to announce 2.1-beta1 and 2.2-alpha-pre.

Thank you very much to all who helped to make it real. Especially to those
who have worked through the nights lately to finish the beta with an
impressive feature set by the announced deadline.

Details can be found here:
https://github.com/mixxxdj/mixxx/blob/master/CHANGELOG

2.1-beta1 lives in the 2.1 branch https://github.com/mixxxdj/mixxx/tree/2.1
while 2.2-alpha-pre lives in the master branch.

Now we have feature an string freeze for the 2.1 branch. This mean we can
start translating and updating the manual.

Bug fix PRs should be target to the 2.1 branch while new features should be
go to master. I will regular merge 2.1 to master, to avoid criss cross
merges.

Existing bug-fix PRs against master don't need to be re-targeted, I will
merge them to 2.1 manually.

I wish you an your family festive holidays and Mary Christmas.

Kind regards,

Daniel
--
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] Master Volume and Recordings

[Daniel Schürmann]

Hi

this is a known problem, and I am pretty sure that every new MIxxx user 
will stumble over it sooner or later.

So we should take such report seriously.

I still like the idea to open the OS Mixer from Mixxx as a band aid for 
this issue:

https://bugs.launchpad.net/mixxx/+bug/1440675
https://github.com/mixxxdj/mixxx/pull/547

A more integrated solution is using PortMixer:
https://bugs.launchpad.net/mixxx/+bug/1440443

What else is a solution that meets the user expectations?

Kind regards,

Daniel



Am 26.11.2017 um 16:01 schrieb Josep Maria Antolin:

Hello Daniel.

So, If i understand you correctly, you connected the line output of 
your soundcard to a power amplifier. I.e. A plain and simple amplifier 
without any volume control on it.


In such scenario, you need to adjust the volume level on your soundcard.
The Xone-K2, as I see, does not have a volume knob on it, but I am 
quite sure that you can control the volume either from the generic 
Windows Mixer, or maybe the Xone drivers include a control panel where 
you have access to a volume level.


The volume controls on Mixxx are really intended just as gain 
adjustement, in situations where you need small gain changes (more in 
line of correcting the target gain, and to prevent digital clipping), 
and not as a way to control the output volume, or at least no more 
than several dBs.
Else, you get the results that you describe, a negative effect over 
the digital signal.


Nowadays, mixing software use different mechanisms to normalize audio. 
In case of Mixxx, it uses ReplayGain.
This means that gain controls are not as much important as they used 
to be, and basically the DJ only needs to make small adjustments over 
the channel gains and rarely on the master gain to compensate for the 
different volume levels of the tracks being played.



I briefly looked into the Mixxx manual, and I couldn't find a place 
where it specifically talks about not overusing the master Gain 
control. I was sure there was a place that said that, but maybe I 
simply didn't look into the correct chapter.


There were some talks about incorporating a soundcard volume knob into 
Mixxx window, but the problem was that each operating system does it 
differently, and even different versions could implement it 
differently, so it seemed like opening a can of worms for something 
that could be better served by teaching users to use the system mixer.


So, overall, I don't think your problem could be considered a bug, but 
an incorrect usage of the options.


If you have any suggestion on how to make this more obvious to other 
users, or do you see any problem on doing what I've just described, 
just tell us.




2017-11-26 14:49 GMT+01:00 Daniel Poelzleithner >:


Hi,

this weekend I djed on a friends birthday Party. Due broken
Hardware I had to hookup directly to a amplifier without any line
control after my hardware (Xone-K2) and the amplifier was unregulated.
I had to pull down the mater gain a lot so it was no too loud.

Now the problem with this is, that it makes mixxx unusable. You
basically loose the possibility to use headphone for listening to
master channel or anything in between because the levels become
very different.

On the evening I thought mixxx is broken in this aspect, I'm not
so sure now but at least then it's missing a second level meter.
Anyway, recordings done when the master know is used to limit the
loudness need massive afterwork to get to a decent loudness.

We either need a second master knob that sits just before the
signal is sent to the line out and after it is recorded and shown
after the master UV meter, or the master gain knob should only
regulate the volume after the master UV meter and recording and
you should adjust the gain on the channels instead on master.

Does somebody use the master know for anything else then reducing
the volume ? In which case I think it would be more useful.


kind regards
 Daniel


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





--
_ _ /~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-\
o o | Josep Mª [JAZ]                 |
 º  | Messenger: jaze...@hotmail.com  |
`-´ | Gtalk: jose...@gmail.com        |
\-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~/

Re: [Mixxx-devel] infrastructure modernization

[Daniel Schürmann]

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

Re: [Mixxx-devel] infrastructure modernization

[Daniel Schürmann]

Hi Be,

It's just as unreasonable to expect new contributors to sign up for 7 
different accounts (GitHub, IRC, phpBB, Freenode, mailing list, 
Launchpad, wiki) as it is to expect long time developers to pay 
attention to all of them. It would be easier if there were less things 
to pay attention to.


Yes sure. Sean is working on it. But It is reasonable to distinguish 
between user support and bug tracking like we do with forums and 
Launchpad. User support can help each others, contributors can jump in 
for unsupported use cases or bugs, that should be then tracked in a 
different domain.


Looking dated is important. Newcomers are telling us in no uncertain 
terms that they don't want to use Launchpad and by and large they 
aren't. What features Launchpad has are irrelevant if people don't use 
them.


Yes, right. But I am in doubt that this is a impossible hurdle.
Remember, the user asks for free support.

Can you elaborate on "has more bug states than just open and close"? 
What else is needed? GitHub and GitLab both have project-defined tags 
that can be used for further organization. GitLab allows projects to 
define priorities for custom tags.


* New
Not looked at yet, unconfirmed
* Incomplete
Cannot be verified, the reporter needs to give more info.
Will be closed automatically
* Opinion
Doesn't fit with the project, but can be discussed.
* Invalid
Not a bug. May be a support request or spam.
* Won't Fix
Doesn't fit with the project plans, sorry.
* Confirmed
Verified by someone other than the reporter.
* Triaged
Verified by the bug supervisor.
We use it for complete analysed bug that cannot be solved for a reason.
* In Progress
The assigned person is working on it.
* Fix Committed
Fixed, but not available until next release.
Available in the alpha
* Fix Released
The fix was released.
Available in the released version

This gives an explicit info about the bug state during it's live time.
We may use Label/Tags for it but than we loose the original tagging 
feature, we use for group bugs under a topic. Or we mix both state and 
loose a lot of clarity. If we than add additional tags for blueprints, 
we use a single feature for tree purposes, which is at least a 
regression compared to Launchpad.



Blueprints are nice but not necessary. Again, tags can be used for the 
same purpose.


Tags are not the same, they are somehow volatile. They need explanations 
to understand the purpose. In Launchpad the meaning of the field is hard 
coupled with a workflow.


I don't know what you mean. GitLab has a nice dashboard view for its 
issue tracker where you can filter by milestone and tag. You can 
drag-and-drop between tags in this view to keep issues organized. I 
think GitHub now has a similar capability too.


The GitLab dashboard is only for registerd users with access rights.
I do not have discovered it for GitHub
If you compare the Homepages, you will see the difference:
https://github.com/mixxxdj
https://gitlab.com/inkscape/
https://launchpad.net/mixxx
Launchpad is more user focussed and giving the best overview.

One of my biggest grievances with Launchpad is how the "Wishlist" marker 
is mutually exclusive with a priority designation. To me it feels like a 
slap in the face for a feature that's important to me to be designated 
with the lowest priority level. IMO there is little practical difference 
between a bug and the lack of a feature. Something that ought to get 
done is something that ought to get done. Whether it's implementing a 
useful feature or whether it's a bug doesn't matter for how important it 
is.


I can't confirm his. Launchpad has no priority field, it is am 
Importance field. We simply cannot give bugs priorities, because we 
cannot force anyone to work on critical bugs first. Every contributor 
has its own priority list and there is no higher authority which can 
change it.


I look at the Wishlist marker as an exception from Importance, since it 
is no malfunction, which is important to fix.


We can only express the opinion of the team how Important this bug is.
The same goes for milestones. We can define milestones as a term of:
"The milestone is reached when all the assigned bugs are done"
We can express which bug will be likely merge do which version, but we 
cannot stop anyone from working on other things.


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.

The popularity of GitHub does give it an advantage, but I do not think 
it is important enough that we can't leave GitHub. 

Re: [Mixxx-devel] infrastructure modernization

[Daniel Schürmann]

Hi Be,

It is not fair to blame the infra structure, for the leak of time the 
maintainers have to manage the different informations.


Launchpad looks somehow outdated, but the important features are there.
Especially, it shows possible duplicates when filing a bug, has more bug 
states than just open and close, has blueprints as a second way to group 
bugs in addition to milestones, the blueprints.
If we assumed Launchpad is well managed (I am working on that now that I 
have permission) it gives a well structured overview for users, what the 
state of the project is. GitHub is more developers focused and does not 
offer this clarity.


I am strictly against closing bugs, that are older then a certain 
deadline, because that feels like a hit in the face, for the people 
which may have investigated a significant time to file the bug. This 
happens to me in other projects and I took my consequences.


The current fragmented infrastructure, has some drawbacks, but it has  a 
very big advantage. You can join discussions how your time allows.


@Be: I am really happy, that you are active on all channels, thank you 
very much!
Unfortunately, I  cannot do this because of leak of time. So I have 
decided not to join IRC and look to forums only when the time allows.


By the way, I have loosed long finished post more than once, because of 
leak of internet connection.
Pressing "Submit" without a stable connection and you post is gone.  So 
that is really a field that could use an update.


Email works very good here. I can manage my own priority list and can 
reach everyone in just a second.


I fully understand Be's concerns, and I agree that GitLab looks very 
mature.

So we are currently in this cycle:

* We want a integrated project management structure.
* We cannot leave GitHub because of the GitHub community
* We cannot move to Gitbub issues because they do not fit our 
requirements and we loose the history.


:-/

Kind regards,

Daniel





Am 18.11.2017 um 07:00 schrieb Be:

On 11/17/2017 02:42 PM, Sean M. Pappalardo - D.J. Pegasus wrote:

For the record, GitLab looks really interesting and exciting to me as
well. If we were a new project, we could go there in a heartbeat. But we
have to consider all of the not-fun practical matters and repercussions
of migration of a large and storied existing project.

On 11/17/2017 11:59 AM, Be wrote:

IMO our biggest issue as a project is a lack of labor.


Which is precisely why migrating at all would be problematic. We can
ill-afford the labor to do it.


I feel that the Mixxx project is in crisis and hanging by a thread. 
Let's stop making excuses for not taking action and start doing 
everything we can to make this project sustainable. We cannot afford 
to continue discouraging people from contributing by clinging to 
outdated, fragmented infrastructure.





IMO having to host our own server for project management is practically
a non-starter.


What are you referring to? In the case of improving Launchpad, our work
would be submitted upstream, to go live on Launchpad.net. We won't have
to move or change anything, just make the existing platform better.
Seems like the best return on effort invested to me.


Not one person has asked for improving Launchpad. That would take an 
enormous effort which I doubt would even solve the current issues. 
Launchpad is an outdated technology with an outdated design, let's let 
it die. Trying to rescue it would be an uphill battle.


On the other hand, we can join the momentum of GitLab, which has a 
very active company and community rapidly improving the server 
software. If there's something about GitLab that doesn't exactly fit 
what we want, we can file issues that actually have a chance of 
getting taking care of. We could also take care of them ourselves by 
sending a merge request to GitLab and not have to deal with hosting it 
ourselves.





A lot, if not most, of the stuff on our Launchpad bug tracker is old
noise with incomplete information.


Please do not make sweeping assertions like this without data.

In reality, 2774 (or 73.5%) of the bugs in the system are either
confirmed (adequate information,) being worked on, or already fixed. A
history of resolved bugs is very valuable in the case of regressions,
similar but new occurrences, and when users search for a common problem
they think is a bug.


Getting good data on this would require spending quite a lot of effort 
to clean up the mess on Launchpad. For a start we have 361 "New" bugs. 
We have lots of "In Progress" bugs that have had no activity in years.


I am skeptical of the importance of keeping old, resolved bugs easily 
accessible. The only times I remember referring to resolved bugs were 
to mark new reports as duplicates because we haven't had a release in 
2 years so people keep reporting the same critical bugs. If needed, we 
could still manually copy and paste Launchpad URLs on the new issue 
tracker on the rare occasion that would be helpful.

Re: [Mixxx-devel] launchpad bugtracker

[Daniel Schürmann]

Sure. The only problem is that we would have no way to communicate back to the 
user (since the bug filer would be a bot account) without having to create a 
separate E-mail thread. That would be quite a step backwards, especially since 
it's not hard (anymore) to create an LP account. (Plus if we make it too easy 
to file, we'll get low-quality bug reports.)


Yes, we could add the email address to the form, but publishing it on 
Launchpad is probably an unwanted side effect.


And Hey, If the user cannot effort the time to sign in to Launchpad, why 
should we effort time to fix the bug he is suffering. :-P




Am 17.11.2017 um 17:18 schrieb Sean M. Pappalardo - D.J. Pegasus:


On 11/17/2017 06:37 AM, Daniel Schürmann wrote:

Here it is hard to rule GitHub. Nearly every developer has a GitHub
account, and it is just click to clone Mixxx and starting to
contribute.

GitLab does offer login with a GitHub account, FWIW.


For Launchpad bug, suffers the same. Registering a second account is
anoying, and stops user from filing bugs.

On that note, I'm working on consolidating logins as much as possible.
https://bugs.launchpad.net/mixxx/+bug/1732715
My plan is to get down to two: Launchpad and GitHub. (Because neither of
those allow authentication from another provider.)


On the other Hand Launchpad has our history, and no other tool offers
the same rich bug states, that we have adopted in our process.

To wit, we started using LP for bug tracking even before we moved the
code there.


We have hundreds cross linkes, between GitHub, Forum, Wiki, and
Launchpad. Losing this had to be well considered compared to some
missing convenient features.

I totally agree. Never mind the work it would take to do a migration,
work that would be better spent on Mixxx itself, IMO.

So the question is: how much more productive would we be if bug and
blueprint tracking was integrated with code hosting? Put another way,
how much is the current separation impairing productivity?

(Keep in mind that Launchpad supports Git now, so it would be possible
to move code hosting back there, solving this particular concern.)


Filing Bug inside Mixxx would be the most convenient solution.

Sure. The only problem is that we would have no way to communicate back
to the user (since the bug filer would be a bot account) without having
to create a separate E-mail thread. That would be quite a step
backwards, especially since it's not hard (anymore) to create an LP
account. (Plus if we make it too easy to file, we'll get low-quality bug
reports.)

We already have the "submit feedback" Google form which seems to be
working well as it has hundreds of responses. (I need to check on how to
publish them.) And indeed some are not useful.


Launchpad offers to communicate via email. Maybe there is a solution
to send Emails from Mixxx to Launchpad?

Even better, it has a full Web API: https://help.launchpad.net/API/
(Which could be used for migration too.)

Sincerely,
Sean M. Pappalardo
"D.J. Pegasus"
Mixxx Developer - Controller Specialist



--
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] launchpad bugtracker

[Daniel Schürmann]

GitLab looks great. Unfortunately the last feature does not count.
What counts is getting things done.

Here it is hard to rule GitHub. Nearly every developer has a GitHub
account, and it is just click to clone Mixxx and starting to contribute.

If we ever leave GitHub, we will suffer the same issue, other non GitHub
hosted Apps have: maintaining an unofficial GitHub clone.

For Launchpad bug, suffers the same. Registering a second account is
anoying, and stops user from filing bugs.

On the other Hand Launchpad has our history, and no other tool offers the
same rich bug states, that we have adopted in our process.

Unlike moving distributed git repros around, bug tracking is a single
server solution were we will loose data migrating to other services.
We have hundreds cross linkes, between GitHub, Forum, Wiki, and Launchpad.
Losing this had to be well considered compared to some missing convenient
features.

For Bug, being on GitHub is IMHO not that important, because only the
minority of users have an GitHub account.

Filing Bug inside Mixxx would be the most convenient solution.

Launchpad offers to communicate via email. Maybe there is a solution to
send Emails from Mixxx to Launchpad?
Or Launchpad questions? Or to the forums ...

What do you think?

Am 17.11.2017 11:54 vorm. schrieb "Daniel Poelzleithner" :

> On 11/17/17 11:38, Be wrote:
>
>> What projects have you used GitLab for? What do you like about it
>> compared to GitHub?
>>
>
> I used it in my previous and current company for internal projects. I was
> even the administrator in the previous one doing the upgrades etc.
> Mostly small internal projects that all got tested through CI. Mostly
> coookbooks for chef and smaller daemons.
>
> I like that it's open source and their development goes into the right
> direction ^^
>
> To be honest, I don't care that much. I think the most important part is,
> that it feels integrated and is easy for a newcomer to fork and create a
> pull request. In the best case, a fork automatically gets CI testing so the
> dev knows before creating a PR that the patch works.
>
> The only drawback I see is the missing social network effect you get
> through github.
>
>
> kind regards
>   poelzi
>
> 
> --
> 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] Mixxx manual info

[Daniel Schürmann]

Ok, in that case 2018-01-31 is a good date for manual string freeze.


Am 16.11.2017 11:13 nachm. schrieb "Sean M. Pappalardo - D.J. Pegasus" <
spappala...@mixxx.org>:



On 11/16/2017 01:26 PM, Daniel Schürmann wrote:
> I am afraid 2018-01-31 is to short for a polished English Doku and then
> wait for translations. So we need to find a mode to do things in parallel.

That's not really possible. Translators depend on the English manual
being complete and stable, so we have to do that first.

On 11/16/2017 11:38 AM, ronso wrote:
> I'd like to help improving the manual, though I'm not very patient nor
> super-skilled in DTP.
> I'll have a look at how all the formatting is done, also I'll ask a
> fellow graphic designer for feedback.

Note that the manual is created with Restructured Text so formatting can
be changed easily (using CSS) later. What matters right now is the
actual content: text, screen shots and diagrams.

Here are instructions to build and edit the manual:
https://github.com/mixxxdj/manual/blob/manual/README.md

Sincerely,
Sean M. Pappalardo
"D.J. Pegasus"
Mixxx Developer - Controller Specialist



--
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] Mixxx release schedule / We need help!

[Daniel Schürmann]

I am afraid 2018-01-31 is to short for a polished English Doku and then
wait for translations. So we need to find a mode to do things in parallel.
How can we allow to polish the English until 2018-03-31 without loosing 
translations in other languages?
I think for non English speaking users unpolished translated doku is 
better than untranslated polished English chapters.


Maybe we can add a English translation for the English doku and use it 
for polishing?
Or we freeze the English doku master branch at an early point for 
translations and do English polishing in a branch.




Am 16.11.2017 um 21:38 schrieb Be:
I have a big PR in progress for reorganizing the early chapters of the 
manual:

https://github.com/mixxxdj/manual/pull/60
Feedback on that would be helpful.

I think we should set a deadline for the manual between the beta and 
final release to allow more time to get the English version together 
while leaving enough time for translators. How about January 31 2018?


On 11/16/2017 01:38 PM, ronso wrote:

Hi.

Yesterday I had a look at the manual after quite a while and found it 
very hard to read on screen.

These issues jump out immediately:

- serif font is fine for printing, but sucks on screens
- lines are way too long, respectivly:
- format is to wide to have it next to or on top of mixxx window (on 
the same screen)

- some page-breaks unnecessarily cut short chapters

I'd like to help improving the manual, though I'm not very patient nor 
super-skilled in DTP.
I'll have a look at how all the formatting is done, also I'll ask a 
fellow graphic designer for feedback.


Maybe someone else already noticed this and has suggestions in the 
pipeline?


Find my further suggestions at https://github.com/mixxxdj/manual/issues

Cheers
r_o


On 16.11.2017 20:00, Radu Suciu wrote:
I have some time after next week to do some work on the manual, is 
there a list of things that need to be updated/written?


On Thu, Nov 16, 2017 at 8:23 AM, Daniel Schürmann <dasch...@mixxx.org 
<mailto:dasch...@mixxx.org>> wrote:


    Hi Mixxx developers,

    I am glad to announce a release schedule for Mixxx. We have
    decided to switch to a deadline based, 6 month release cycle.

    Releases:
    2018-03-31 Mixxx 2.1
    2018-09-30 Mixxx 2.2
    and so on.

    To reach the Mixxx 2.1 date, we have decided to release a 2.1 beta
    and 2.2 alpha at

    ->  2017-12-22 <-

    This means we have 5 weeks left to  finish started PRs left to
    accept feature / skin and string pull requests for 2.1.
    Later feature PRs are still welcome, but go to 2.2 alpha.

    For the release 2.1 we need to do
    * A lot of testing
    * bug-fixing
    * Mapping updates
    * Translation
    * Manual
    * Release PR

    To make Mixxx 2.1 a great success, we need help especially on the
    non software related tasks like testing, improving manual and
    translations. So please ask your DJ colleges, if they have some
    fun and spare time to adopt a task and push Mixxx forward. Thank 
you!


    Kind regards,

    Daniel


-- 


    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
    <mailto:Mixxx-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/mixxx-devel
    <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



-- 


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.

Re: [Mixxx-devel] Mixxx release schedule / We need help!

[Daniel Schürmann]

Hi Radu,

Thank you :-)
I think the looping feature deserves an own new chapter.

It would also a great help to verify the current manual with the current 
Mixxx version and it's changes and file GitHub issues for all missing 
features.





Am 16.11.2017 um 20:00 schrieb Radu Suciu:
I have some time after next week to do some work on the manual, is there 
a list of things that need to be updated/written?


On Thu, Nov 16, 2017 at 8:23 AM, Daniel Schürmann <dasch...@mixxx.org 
<mailto:dasch...@mixxx.org>> wrote:


Hi Mixxx developers,

I am glad to announce a release schedule for Mixxx. We have decided
to switch to a deadline based, 6 month release cycle.

Releases:
2018-03-31 Mixxx 2.1
2018-09-30 Mixxx 2.2
and so on.

To reach the Mixxx 2.1 date, we have decided to release a 2.1 beta
and 2.2 alpha at

->  2017-12-22 <-

This means we have 5 weeks left to  finish started PRs left to
accept feature / skin and string pull requests for 2.1.
Later feature PRs are still welcome, but go to 2.2 alpha.

For the release 2.1 we need to do
* A lot of testing
* bug-fixing
* Mapping updates
* Translation
* Manual
* Release PR

To make Mixxx 2.1 a great success, we need help especially on the
non software related tasks like testing, improving manual and
translations. So please ask your DJ colleges, if they have some fun
and spare time to adopt a task and push Mixxx forward. Thank you!

Kind regards,

Daniel


--
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
<mailto:Mixxx-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mixxx-devel
<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] Mixxx release schedule / We need help!

[Daniel Schürmann]

Hi Mixxx developers,

I am glad to announce a release schedule for Mixxx. We have decided to
switch to a deadline based, 6 month release cycle.

Releases:
2018-03-31 Mixxx 2.1
2018-09-30 Mixxx 2.2
and so on.

To reach the Mixxx 2.1 date, we have decided to release a 2.1 beta and 2.2
alpha at

->  2017-12-22 <-

This means we have 5 weeks left to  finish started PRs left to accept
feature / skin and string pull requests for 2.1.
Later feature PRs are still welcome, but go to 2.2 alpha.

For the release 2.1 we need to do
* A lot of testing
* bug-fixing
* Mapping updates
* Translation
* Manual
* Release PR

To make Mixxx 2.1 a great success, we need help especially on the non
software related tasks like testing, improving manual and translations. So
please ask your DJ colleges, if they have some fun and spare time to adopt
a task and push Mixxx forward. Thank you!

Kind regards,

Daniel
--
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] USB sound card table update

[Daniel Schürmann]

Yes, the onboard soundcard of my desktop device.
And yes, at least with ALSA they are treated just as an generic 8 channel
soundcard.

I assume that there can be crosstalk issues, but that is the same issue if
you use a splitter cable.

@Thorsten: can you verify that his for windows?

Am 21.09.2017 12:36 vorm. schrieb "Be" <b...@gmx.com>:

On 09/20/2017 05:25 PM, Daniel Schürmann wrote:

> Hi Thorsten,
>
> Thank you for your input. If you like, you could you add a paragraph that
> explains how to use a Surround sound card for Mixxx?
>
> With Linux + ALSA this is no deal, my onboard soundcard has  4 x 3,5 mm
> output jacks, and the Mixxx hardware preferences are listing 8 channels. So
> there is nothing special here.  How does it look in Windows?
> Is there anything special to setup?
>

Are you referring to the onboard sound card on a desktop computer? Yeah,
the sometimes have more jacks. Whether they can typically play independent
output channels I don't know. I suppose it's worth mentioning, but I've
never seen a laptop with more than a mic input and headphone output jack.



--
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] USB sound card table update

[Daniel Schürmann]

Hi Thorsten,

Thank you for your input. If you like, you could you add a paragraph 
that explains how to use a Surround sound card for Mixxx?


With Linux + ALSA this is no deal, my onboard soundcard has  4 x 3,5 mm 
output jacks, and the Mixxx hardware preferences are listing 8 channels. 
So there is nothing special here.  How does it look in Windows?

Is there anything special to setup?

Interestingly, I have never tried this for Mixxx, because I use my 
laptop when DJing. This has a single combined microphone/headphone jack.


Kind regards,

Daniel





Am 20.09.2017 um 21:03 schrieb Be:

On 09/20/2017 10:06 AM, Thorsten Munsch wrote:

Hey guys,

at first I wanted to suggest the user to use his only his onboard 
interface, because since over a decade? all the chips support 
surround sound. There should be a hint how the user sets the onboard 
interface into multichannel mode via it's drivers control panel and 
then how to configure Mixxx to use each channel for master, cue, and 
so on.


Huh? Do you mean multichannel HDMI output? I've never come across an 
onboard sound card with more than 2 analog outputs.


But the problem are laptops I recognized while typing. They only have 
one line out jack and a mic in. > If it would be possible to 
configure the
mic in as a second stereo output it would be no deal (newer onboard 
chips are able for i/o switching i read).


AFAIK not that many onboard sound cards support switching the behavior 
of jacks and if it is supported, it may not be easy to figure out how 
to activate it. Also, having two separate jacks on a laptop seems to 
be rare today. My 6 year old laptop has separate mic input and 
headphone output jacks, but most new laptops combine the mic input and 
headphone output into one jack now.


-- 


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] USB sound card table update

[Daniel Schürmann]

> To be clear, onboard sound cards and USB class compliant sound cards
(which includes every sound card listed on the wiki) should both work with
WDM-KS?

I am pretty sure. But I cannot prove it.

If you have a single Asio soundcard (one with a real Asio driver, not
asio4all) you should use Asio, because it bypassed all windows software
layers for direct access to the hardware, offering the best latency.

If we assume that only a minority of users have such a device, we can
consider to change the default API.





Am 15.09.2017 12:25 vorm. schrieb "Be" <b...@gmx.com>:

To be clear, onboard sound cards and USB class compliant sound cards (which
includes every sound card listed on the wiki) should both work with WDM-KS?
Are you sure all onboard sound card drivers work with WDM-KS? So we should
we edit the manual to recommend using WDM-KS in this situation? Should we
change the default on Windows to WDM-KS? What advantage does ASIO offer
over WDM-KS?


On 09/14/2017 03:29 PM, Daniel Schürmann wrote:

> No, most Soundcards have a WDM driver and some have also an ASIO driver.
> It looks like all listed USB soundcards works with the gneric Windows USB
> sound driver.
>
> This might be the usually story:
> * A user byes an USB soundcard with an ASIO driver from CD
> * He installs the ASIO driver, and configures his new device with ASIO and
> Mixxx
> * Now he cannot use the onborad sound :-(
> * he install the ASIO4All driver
> * The ASIO4All driver graps the onbord Soundcard and the USB soundcard via
> WDM
> * result Sound is crackling.
> * after messing around the user might be able to configure ASIO4All for
> its onboard sound only and the extra ASIO driver for his external soundcard
> * result is crackling, because of the long latency and the still short
> buffer in Mixxx
> * hours later, the Mixxx buffer is back at default 23 ms and the ASIO
> solution works.
>
>
> Behringer makes the situation worse by shipping ASIO4ALL to pretend to be
> an ASIO device
> Denon recommend to de-install all other ASIO drivers because of these
> problems
>
> The better story:
> * A user byes an USB soundcard with an ASIO driver from CD
> * He installs the ASIO driver, and configures his new device with ASIO and
> Mixxx
> * Now he cannot use the onborad sound :-(
> * Switch Mixxx back to WDM
> * confgure both soundcards
> * tweak the buffer
> * have fun
>
> Maybe we should detect ASIO4All and warn the user ;-)
>
>
>
> Am 14.09.2017 um 19:44 schrieb Be:
>
>> Wouldn't that normally be the case when combining an external sound card
>> and onboard sound card on Windows?
>>
>> On 09/14/2017 08:54 AM, Daniel Schürmann wrote:
>>
>>> Ok, I have read a bit more. The only reason that justifies asio4all is
>>> to combine a Asio card with no WDM driver and a WDM card with no Asio
>>> driver. Using asio4all without any other Asio device is just an unnecessary
>>> software between Mixxx and the soundcard.
>>> Using two WDM soundcards via asio4all may crackle.
>>>
>>> Am 14.09.2017 3:30 nachm. schrieb "Daniel Schürmann" <dasch...@mixxx.org
>>> <mailto:dasch...@mixxx.org>>:
>>>
>>> Ah, ok I understand. Asio4all makes the things worse. We already
>>> recommend to not use it at all. I think we already have a paragraph
>>> for it so we can remove the crackling issue from the asio4all
>>> unrelated paragraphs. And give an advise "If you think you need
>>> asio4all, use WDM"
>>>
>>>
>>> Am 14.09.2017 12:03 nachm. schrieb "Be" <b...@gmx.com
>>> <mailto:b...@gmx.com>>:
>>>
>>> We still have the issue with ASIO on Windows only supporting one
>>> sound card at a time. ASIO4ALL can present an aggregate device,
>>> but in this case, if I understand correctly, Mixxx's clock sync
>>> code is irrelevant. Users have reported crackling using ASIO4ALL
>>> this way ( https://mixxx.org/forums/viewtopic.php?p=30983#p30983
>>> <https://mixxx.org/forums/viewtopic.php?p=30983#p30983> ).
>>>
>>>
>>> On 09/14/2017 03:29 AM, Daniel Schürmann wrote:
>>>
>>> Hi Be,
>>>
>>> Thank you for your latest changes.
>>> Here some comments:
>>>
>>>
>>> and you cannot hear the arrangement of different sounds
>>> in space.
>>>
>>>
>>> and you lose the stereo effect, the arrangements of ...
>>>
>>> 

Re: [Mixxx-devel] USB sound card table update

[Daniel Schürmann]

No, most Soundcards have a WDM driver and some have also an ASIO driver.
It looks like all listed USB soundcards works with the gneric Windows 
USB sound driver.


This might be the usually story:
* A user byes an USB soundcard with an ASIO driver from CD
* He installs the ASIO driver, and configures his new device with ASIO 
and Mixxx

* Now he cannot use the onborad sound :-(
* he install the ASIO4All driver
* The ASIO4All driver graps the onbord Soundcard and the USB soundcard 
via WDM

* result Sound is crackling.
* after messing around the user might be able to configure ASIO4All for 
its onboard sound only and the extra ASIO driver for his external soundcard
* result is crackling, because of the long latency and the still short 
buffer in Mixxx
* hours later, the Mixxx buffer is back at default 23 ms and the ASIO 
solution works.



Behringer makes the situation worse by shipping ASIO4ALL to pretend to 
be an ASIO device
Denon recommend to de-install all other ASIO drivers because of these 
problems


The better story:
* A user byes an USB soundcard with an ASIO driver from CD
* He installs the ASIO driver, and configures his new device with ASIO 
and Mixxx

* Now he cannot use the onborad sound :-(
* Switch Mixxx back to WDM
* confgure both soundcards
* tweak the buffer
* have fun

Maybe we should detect ASIO4All and warn the user ;-)



Am 14.09.2017 um 19:44 schrieb Be:
Wouldn't that normally be the case when combining an external sound 
card and onboard sound card on Windows?


On 09/14/2017 08:54 AM, Daniel Schürmann wrote:
Ok, I have read a bit more. The only reason that justifies asio4all 
is to combine a Asio card with no WDM driver and a WDM card with no 
Asio driver. Using asio4all without any other Asio device is just an 
unnecessary software between Mixxx and the soundcard.

Using two WDM soundcards via asio4all may crackle.

Am 14.09.2017 3:30 nachm. schrieb "Daniel Schürmann" 
<dasch...@mixxx.org <mailto:dasch...@mixxx.org>>:


Ah, ok I understand. Asio4all makes the things worse. We already
recommend to not use it at all. I think we already have a paragraph
for it so we can remove the crackling issue from the asio4all
unrelated paragraphs. And give an advise "If you think you need
asio4all, use WDM"


Am 14.09.2017 12:03 nachm. schrieb "Be" <b...@gmx.com
<mailto:b...@gmx.com>>:

We still have the issue with ASIO on Windows only supporting one
sound card at a time. ASIO4ALL can present an aggregate device,
but in this case, if I understand correctly, Mixxx's clock sync
code is irrelevant. Users have reported crackling using ASIO4ALL
this way ( https://mixxx.org/forums/viewtopic.php?p=30983#p30983
<https://mixxx.org/forums/viewtopic.php?p=30983#p30983> ).


On 09/14/2017 03:29 AM, Daniel Schürmann wrote:

Hi Be,

Thank you for your latest changes.
Here some comments:


and you cannot hear the arrangement of different sounds
in space.


and you lose the stereo effect, the arrangements of ...

However, this increases latency and there may be
crackling on one sound card.


Also, using multiple sound cards increases latency and
there may be crackling on one sound card, so


It was a lot of work to remove the crackling in this case,
so it throws a bad light on Mixxx if we still pretend this.
Can we just remove the second part until we have the
evidence that the cracking is still there?

The only remaining issue is that Mixxx removed or duplicates
stereo samples to catch up. You loose bit perfect but this
cannot be heared. The same is done for example if you push
the rate slider a minimal step.


Am 11.09.2017 1:32 vorm. schrieb "Be" <b...@gmx.com
<mailto:b...@gmx.com> <mailto:b...@gmx.com
<mailto:b...@gmx.com>>>:

 I have revised the table of USB sound cards on the wiki
to have less
 technical mumbo jumbo and more user friendly
explanations of the
 pros and cons of different devices. I have also removed
some
 discontinued and unpopular devices. I hope this is more
useful now
 for users considering what hardware to get.

https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_sound_cards
<https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_sound_cards>
<https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_sound_cards
<https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_sound_cards>>

--
 

Re: [Mixxx-devel] USB sound card table update

[Daniel Schürmann]

Ok, I have read a bit more. The only reason that justifies asio4all is to
combine a Asio card with no WDM driver and a WDM card with no Asio driver.
Using asio4all without any other Asio device is just an unnecessary
software between Mixxx and the soundcard.
Using two WDM soundcards via asio4all may crackle.

Am 14.09.2017 3:30 nachm. schrieb "Daniel Schürmann" <dasch...@mixxx.org>:

Ah, ok I understand. Asio4all makes the things worse. We already recommend
to not use it at all. I think we already have a paragraph for it so we can
remove the crackling issue from the asio4all unrelated paragraphs. And give
an advise "If you think you need asio4all, use WDM"


Am 14.09.2017 12:03 nachm. schrieb "Be" <b...@gmx.com>:

We still have the issue with ASIO on Windows only supporting one sound card
at a time. ASIO4ALL can present an aggregate device, but in this case, if I
understand correctly, Mixxx's clock sync code is irrelevant. Users have
reported crackling using ASIO4ALL this way ( https://mixxx.org/forums/viewt
opic.php?p=30983#p30983 ).


On 09/14/2017 03:29 AM, Daniel Schürmann wrote:

> Hi Be,
>
> Thank you for your latest changes.
> Here some comments:
>
>
> and you cannot hear the arrangement of different sounds in space.
>>
>
> and you lose the stereo effect, the arrangements of ...
>
> However, this increases latency and there may be crackling on one sound
>> card.
>>
>
> Also, using multiple sound cards increases latency and there may be
>> crackling on one sound card, so
>>
>
> It was a lot of work to remove the crackling in this case, so it throws a
> bad light on Mixxx if we still pretend this. Can we just remove the second
> part until we have the evidence that the cracking is still there?
>
> The only remaining issue is that Mixxx removed or duplicates stereo
> samples to catch up. You loose bit perfect but this cannot be heared. The
> same is done for example if you push the rate slider a minimal step.
>
>
> Am 11.09.2017 1:32 vorm. schrieb "Be" <b...@gmx.com <mailto:b...@gmx.com
> >>:
>
> I have revised the table of USB sound cards on the wiki to have less
> technical mumbo jumbo and more user friendly explanations of the
> pros and cons of different devices. I have also removed some
> discontinued and unpopular devices. I hope this is more useful now
> for users considering what hardware to get.
>
> https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_sound_cards
> <https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_
> sound_cards>
>
> 
> --
> 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
> <mailto:Mixxx-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
> <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] USB sound card table update

[Daniel Schürmann]

Ah, ok I understand. Asio4all makes the things worse. We already recommend
to not use it at all. I think we already have a paragraph for it so we can
remove the crackling issue from the asio4all unrelated paragraphs. And give
an advise "If you think you need asio4all, use WDM"

Am 14.09.2017 12:03 nachm. schrieb "Be" <b...@gmx.com>:

We still have the issue with ASIO on Windows only supporting one sound card
at a time. ASIO4ALL can present an aggregate device, but in this case, if I
understand correctly, Mixxx's clock sync code is irrelevant. Users have
reported crackling using ASIO4ALL this way ( https://mixxx.org/forums/viewt
opic.php?p=30983#p30983 ).


On 09/14/2017 03:29 AM, Daniel Schürmann wrote:

> Hi Be,
>
> Thank you for your latest changes.
> Here some comments:
>
>
> and you cannot hear the arrangement of different sounds in space.
>>
>
> and you lose the stereo effect, the arrangements of ...
>
> However, this increases latency and there may be crackling on one sound
>> card.
>>
>
> Also, using multiple sound cards increases latency and there may be
>> crackling on one sound card, so
>>
>
> It was a lot of work to remove the crackling in this case, so it throws a
> bad light on Mixxx if we still pretend this. Can we just remove the second
> part until we have the evidence that the cracking is still there?
>
> The only remaining issue is that Mixxx removed or duplicates stereo
> samples to catch up. You loose bit perfect but this cannot be heared. The
> same is done for example if you push the rate slider a minimal step.
>
>
> Am 11.09.2017 1:32 vorm. schrieb "Be" <b...@gmx.com <mailto:b...@gmx.com
> >>:
>
> I have revised the table of USB sound cards on the wiki to have less
> technical mumbo jumbo and more user friendly explanations of the
> pros and cons of different devices. I have also removed some
> discontinued and unpopular devices. I hope this is more useful now
> for users considering what hardware to get.
>
> https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_sound_cards
> <https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_
> sound_cards>
>
> 
> --
> 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
> <mailto:Mixxx-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
> <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] USB sound card table update

[Daniel Schürmann]

Hi Be,

Thank you for your latest changes.
Here some comments:


> and you cannot hear the arrangement of different sounds in space.

and you lose the stereo effect, the arrangements of ...

> However, this increases latency and there may be crackling on one sound
card.

> Also, using multiple sound cards increases latency and there may be
crackling on one sound card, so

It was a lot of work to remove the crackling in this case, so it throws a
bad light on Mixxx if we still pretend this. Can we just remove the second
part until we have the evidence that the cracking is still there?

The only remaining issue is that Mixxx removed or duplicates stereo samples
to catch up. You loose bit perfect but this cannot be heared. The same is
done for example if you push the rate slider a minimal step.


Am 11.09.2017 1:32 vorm. schrieb "Be" :

> I have revised the table of USB sound cards on the wiki to have less
> technical mumbo jumbo and more user friendly explanations of the pros and
> cons of different devices. I have also removed some discontinued and
> unpopular devices. I hope this is more useful now for users considering
> what hardware to get.
>
> https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_sound_cards
>
> 
> --
> 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] Library redesign future and development planning

[Daniel Schürmann]

> How does the multi-broadcasting branch fit into this? I have not tested
it. Looking at the discussion on the PR, it seems there are just a few
relatively small UX design issues to figure out before it is ready to
merge. Is that correct? If that is the case, I think it could go in the
next release.

Yes, the multi-broadcasting branch can be considered a ready for a beta
phase. Here is a chicken egg problem as well. We are not able to test a
variety of connections and use cases before merge, to be sure it does not
break anyone's setup. But without a merge, no one will test.

I think Stéphane has found another tester yet. So IMHO we schould merge
this after successfully finishing this test.

Am 11.09.2017 2:06 nachm. schrieb "Be" :

> Hi Anast,
>
> First, thanks again for your work on nested crates and for starting this
> discussion.
>
> Although the library redesign branch is (mostly?) feature complete, it is
> a *massive* change that has not been extensively tested yet. I am concerned
> that targeting it for the next release would push the release back by
> months. Can we identify the remaining issues with the library redesign
> branch? If we could come up with a procedure/checklist for manual testing
> to identify issues that would be helpful. Then we may get a more realistic
> idea of just how much work would be required.
>
> I propose to focus development on finishing the open PRs polishing the
> effects, skins, and Windows upgrading, then finally cutting a beta release,
> then shifting our focus to the library redesign. I was hoping the work on
> those open PRs would be done early during GSoC, but alas, here we are in
> September with PRs that have been sitting awaiting review since May or
> earlier. My postfader effects branch has been complete for over two months
> without any review at all.
>
> I am frustrated with this situation. I don't think it's fair that you and
> Joan have to wait so long for your work to finally get released, but I do
> want to have a release at all. We had a plan for cutting a beta release in
> late January, then that just didn't happen without any discussion of what
> was going on. IMO the long term solution is to have more people testing and
> reviewing, but every time I ask for that, or process improvements to make
> it easier to get more people involved with testing, it seems to go nowhere.
> :/ I hope that putting out the next release, which finally has all the
> common features of controllers implemented, will bring a surge of developer
> interest, but to get there, we need to have a release. It seems like a
> chicken-and-egg problem. I don't know what else to do at this point other
> than wait for things to keep slowly plodding along at the pace they have
> been.
>
> Going back to the library redesign, we also have the issue of the general
> design of the library GUI. Currently the second library feature pane is
> just disabled to postpone finishing the design. If we were to actually
> release this single-pane version, there should be a bit more polishing to
> remove awkwardness from when it was designed for two features. If we
> postpone merging the branch for after the next release, I would like to
> make the following release with a fully developed two-pane solution as
> originally intended for Joan's GSoC project. I think we have a good idea
> for what direction to move forward with the design (independently selecting
> each feature), but it will take a lot of work to implement.
>
> How does the multi-broadcasting branch fit into this? I have not tested
> it. Looking at the discussion on the PR, it seems there are just a few
> relatively small UX design issues to figure out before it is ready to
> merge. Is that correct? If that is the case, I think it could go in the
> next release.
>
> On 09/11/2017 05:01 AM, Anast Gramm wrote:
>
>> Hello,
>>
>> The new library redesign should be -imho- a part of the next mixxx
>> release.
>> The problem is that currently there are some problems with the code in
>> that branch,
>> I think the library could preform faster that it does and also the lack
>> of poslish
>> in some library features (like autoDJ) is setting things back.
>>
>> I've built a nested crates system on top of that branch, and in order
>> to get it merged the library redisign needs to get the love it needs.
>>
>> We should start by mergin my nested crates branch with the library
>> redesign one
>> in the upstream and then we can all work from there to get it done.
>>
>> I will be avaliable to work on those things after September. It would be
>> nice to have more people working at it since it's kinda big.
>>
>> Here is the redisign PR: https://github.com/mixxxdj/mixxx/pull/1117
>> And the nested crates one: https://github.com/mixxxdj/mixxx/pull/1304
>>
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! 

Re: [Mixxx-devel] USB sound card table update

[Daniel Schürmann]

Hi Be,

I think your latest changes are not that good. In my experiences Mixxx
works nice without any notable crackling with two soundcards and we schould
note that in the general USB paragraph along with the disadvantages and not
hidden in a special soundcards section.

Remember that not every user plays flac files on a pro PA. We have also
users who play YouTube rips at their living room stereo, and for those an
USB thumb type soundcard for preview just suits.

By the way, what are your two soundcard issues? Do we have a bug for it?

Kind regards,

Daniel.



Am 11.09.2017 8:57 vorm. schrieb "Be" <b...@gmx.com>:

I have added a note about that in the table for the Behringer UFO202. I
also noted that there may be crackling on one sound card. Although the
clock synchronization code helps, in my experience it is not perfect.


On 09/11/2017 01:20 AM, Daniel Schürmann wrote:

> Hi Be,
>
> thank you. Could you please add a sentence, about why using two soundcard
> is not recommended?
>
> Something like this:
> "
> In case if two sound cards, Mixxx needs to sync them using some extra Cpu.
> The latency resulting latency is in general a way bigger than the minimum
> usable latency of the slowest type paired"
>
> Thank you.
>
> Kind regards,
>
> Daniel
>
>
> Am 11.09.2017 1:32 vorm. schrieb "Be" <b...@gmx.com <mailto:b...@gmx.com
> >>:
>
> I have revised the table of USB sound cards on the wiki to have less
> technical mumbo jumbo and more user friendly explanations of the
> pros and cons of different devices. I have also removed some
> discontinued and unpopular devices. I hope this is more useful now
> for users considering what hardware to get.
>
> https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_sound_cards
> <https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_
> sound_cards>
>
> 
> --
> 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
> <mailto:Mixxx-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
> <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] USB sound card table update

[Daniel Schürmann]

Hi Be,

thank you. Could you please add a sentence, about why using two soundcard
is not recommended?

Something like this:
"
In case if two sound cards, Mixxx needs to sync them using some extra Cpu.
The latency resulting latency is in general a way bigger than the minimum
usable latency of the slowest type paired"

Thank you.

Kind regards,

Daniel


Am 11.09.2017 1:32 vorm. schrieb "Be" :

> I have revised the table of USB sound cards on the wiki to have less
> technical mumbo jumbo and more user friendly explanations of the pros and
> cons of different devices. I have also removed some discontinued and
> unpopular devices. I hope this is more useful now for users considering
> what hardware to get.
>
> https://mixxx.org/wiki/doku.php/hardware_compatibility#usb_sound_cards
>
> 
> --
> 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] WIP: deduplication & git annex support

[Daniel Schürmann]

Hi Daniel

Welcome to Mixxx!

It sounds as an interesting approach to use git for organizing your music
tracks.
If we bring this to Mixxx somehow it would be definetly a big improvement.

If you wish to discuss details of your code, that can be done the best as
GitHub pull requests.

https://www.mixxx.org/wiki/doku.php/bugfix_workflow
Is also a good start to read.

In general, I also suffers from duplicates in my library. It would be grate
if we could also add a quality analysis, that can identify retranscoded
tracks like flac fake tracks made from MP3 or something. But that is
probably an other story.

I am looking forward to work with you.

Kind regards, Daniel

Am 15.08.2017 3:49 vorm. schrieb "Daniel Poelzleithner" :

> Hi,
>
> I'm new to mixxx and just loving it, very well made tool :)
>
> Don't know if you guys know git annex, but this is my tool for managing
> my audio library. It ensures safty and allows you to distribute your
> library onto many drives/computers/etc while it gives you consistent
> view. However, this also means not every file is always available.
>
> My usecase is this: Usually I have a flac and a good quality
> opus/ogg/whatever version - they are in the same folder. On my laptop I
> only carry a subset of non flac files. A "git annex get [file|folder]"
> would try to get a copy of the version requested. It can be from online
> sources, external drive or whatever script you write.
>
> I plan on git annex support that it would for example do a git annex
> get when a file is loaded and libraries has git annex support enabled.
> Also before metadata writeback a git annex unlock is required, for
> example to remove write protection and backup.
> Also git annex supports metadata tags I would like to import/etc...
>
> Therefore I'm fighting duplicates in my library which drives me nuts ;)
>
> So, I thought about how to get rid of them in the correct way and came
> to the conclusion that most parts are already there and some minor
> redesign should be enough.
> Instead of a track is represented by location, it makes more sense to
> have a track represented by a list of locations in different quality
> and availability. Mixxx should just load the best available version
> when a track is loaded.
>
> I added a new analyzer pass and calculate the acoustid fingerprint and
> hash. I'm not cutting the fingerprint after 2 minutes as I'm not
> interested in online lookup but only minimizing false positives.
>
> Next step is to commit them to the database and start some refactoring
> on the track object, etc.
>
>
> Additionally I nearly finished a branch with a new widget, CrateList
> which shows a list of Crates a selected library track or player track
> is in. I"m using crates more like tags and want a quick and fast view
> on which other crates the song is in. It's optional and right to the
> coverwidget on LateNight/Deere. Still some code missing before being
> useable ;)
>
> While working on both branches, I had the feeling that some refactoring
> would make a lot of my efforts much easier and maybe the codebase
> cleaner. I only know some parts therefore a wild guess. The django ORM
> has the concept of manager which you can access by instance->manager-
> >...
> This manager is responsible for saving the object to database,
> providing data lookup interface etc. When it's easy expandable, new
> features would just provide the manager with enough informations and
> hooks for handeling standard or non standard data.
> It would be easy from everywhere a TrackPointer as available to do some
> lookup or datahandling.
>
> The fingerprint is one example: It's to large to just be added metadata
> to a track, while to small for the filecache. It fits well into a blob
> column but it should not be loaded if not required.
>
> Anyway, the overall design is quite nice and qt makes it nice to work
> with. Used it only from python before.
>
> kind regards
>  Daniel
>
> 
> --
> 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] [Feature Proposal] Ctlra Controller Hotplug Support

[Daniel Schürmann]

Hi Harry,

thank you for pointing me to ctlra_info_get_name.
That is a good help to locate the event on the controller.

However, I think we have the chance here to also represent the intended
use of a control in machine readable way and be also OSC compatible. For 
example I have two gain buttons on my controller, these two buttons can 
be found on any DJ controller, the same is true for example for the 
play/pause button.


It would be just natural to define some kind of application profiles for 
a controller, that a controller manufacturer may implement.
This can be linked into the OSC namespace. Just to be compatible with 
OSC. OSC can benefit in the same way from our application profiles. And 
when we one day have a device connected over network using OSC it can be 
quite well wrapped and presented in Ctlra. There is no other 
relationship between OSC and Ctlra and OSC just the shared OSC address.


For example we can define

"Deck X Gain profile":

A control that is intended to control the gain of a deck.
Value x means lowest gain value y means highest gain and value z 
(centre) means 0 dB.

OSC Address: /CTLRA/DEVICE/DECK1/GAIN

Thats all. This is IMHO quite natural and does not effect directly the API.

For now it requires "only" an other string for each event.
ctlra_info_get_osc_address(). Which can default to
/CTLRA/DEVICE/TYPE/ID if there is no profile defined.


This solves also the LED connections:

"Deck X Play/Pause profile":

A control that is intended to toggle between play and pause of a deck.
Value x means pressed value y means released. It may feature also an 
indicator light that can be controlled independently.


OSC Address: /CTLRA/DEVICE/DECK1/PLAY_PAUSE
OSC Address: /CTLRA/DEVICE/DECK1/PLAY_PAUSE_LED

All this is optional, but if a controller implements Application 
Profiles, it is instantly usable with a basic function in all Ctlra 
enabled devices. We are back in the good old midi days, where you can 
plug in a keyboard and it just works.


The OSC Addresses are only needed once to setup the initial mapping for 
a direct Ctlra application and are used as OSC as communication address 
in case of a OSC gateway.


I see that OSC is increasingly supported by various DAW application.
So Ctlra will immediately benefit from it. There is no need to explain 
the DAW and Controller manufactures: "You do not need OSC, use Ctlra".


We can ask them, to consider the "Ctlra Application Profiles" on top of 
the OSC support, to benefit from great source of instantly usable 
controllers. This will IMHO help a lot to make Ctlra popular, and wash 
away the impression that Ctlra is just a new concurrent standard.


Kind regards,

Daniel











Am 09.07.2017 um 14:57 schrieb Harry van Haaren:
On Sun, Jul 9, 2017 at 1:23 PM, Daniel Schürmann <dasch...@mixxx.org 
<mailto:dasch...@mixxx.org>> wrote:


Hi Harry,

 > At no point to I think Ctlra will *require* also using TCC. It
just so happens that they complement each other well for my use-cases.

That seams to be a good approach. If the architecture allows to put
Ctlra drivers into runtime loaded object files, it does not matter
which compiler is used and if it turns out that TCC is the best for
our needs on a platform, fine.

> That proposal looks really good. It basically means,  from a Ctlra POV, 
that Ctlra is plain old C code, and exposes
generic events.

No, not generic events. The Ctlra using apllications should receive
a specific event.


By "generic event", what I mean is a specific event type, with a 
specific event ID. These two combined identify one specific control item 
on a physical controller device. For example, a specific button (eg 
Play) sends a button event when pressed / released, using this struct 
for metadata: 
https://github.com/openAVproductions/openAV-Ctlra/blob/master/ctlra/event.h#L63


Note that the name of the control is *not* included here for performance 
reasons. Passing strings around just isn't a good idea for performance. 
Ctlra provides functions to lookup the name of each event based on 
type/ID. I have "generic" applications (don't care about which HW 
controller is used) that provide fully labelled UIs showing all control 
names - so your use-case is covered here. (If there is an issue, we can 
resolve it at the Ctlra API layer, but AFAIK the API caters for the 
application's requirements).


If you turn the gain Knob on a controller, the application should be
able to now that this is the Knob labeled with "Gain" grouped for
Deck A.


See above paragraph - names of events are provided, based on the labels 
physically printed on the hardware.


This might be done by a generic event + a link into a manifest file,
which may also include a photo of the controller. This metada of
each event should be optimized to be translated into a OSC add

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

[Daniel Schürmann]

Hi Harry,

> At no point to I think Ctlra will *require* also using TCC. It just 
so happens that they complement each other well for my use-cases.


That seams to be a good approach. If the architecture allows to put 
Ctlra drivers into runtime loaded object files, it does not matter which 
compiler is used and if it turns out that TCC is the best for our needs 
on a platform, fine.


> That proposal looks really good. It basically means, from a Ctlra 
POV, that Ctlra is plain old C code, and exposes generic events.


No, not generic events. The Ctlra using apllications should receive a 
specific event. If you turn the gain Knob on a controller, the 
application should be able to now that this is the Knob labeled with 
"Gain" grouped for Deck A. This might be done by a generic event + a 
link into a manifest file, which may also include a photo of the 
controller. This metada of each event should be optimized to be 
translated into a OSC address, this should be a mandatory part of Crtra. 
So we need a document like this:

https://github.com/fabb/SynOSCopy/wiki

> The application can interpret those in whatever way it wants - OSC, 
JS/Mixxx, or however OpenAV stuff will end up doing this. It keeps Ctlra 
just generic events, and allows the application to solve the mapping 
problem in its own way. That sounds logical and a good abstraction, 
which is exactly what Ctlra aims for.


Yes, that is right. Today in case of midi, the user has to figure out 
which midi key is doing what.  With a Ctlra enabled controller this 
issue should be gone. The mapping solution can for example show the 
photo of the controller, and highlight the place of action.
But even without the photo, the user knows exactly how to enable a knob 
LED, using the OSC name-space as address.


> In order to progress this idea, I'll post code up ASAP, which makes 
the generic Ctlra events available in a callback as part of the 
CtlraController class. After that, the Mixxx/JS components must be 
designed / worked on to fully enable Ctlra in Mixxx.


Thank you :-)

I think for the OCS Plug and Play stuff we just need to rethink the API 
a bit.

I would like to do something like this
https://github.com/mixxxdj/mixxx/blob/lv2_support2/src/effects/lv2/lv2manifest.cpp
in Ctlra as well.
(Sorry, I am not completely though the API so this might be wrong)
We need a kind of generic data point enumerator expression for every 
event, which is able to discover all controller features.
Every data point should have a function for examine like 
ctlra_dev_get_osc_namespace() and ctlra_dev_get_picture_location()


Will this work? Does this fit to the ctlra goals?

Kind regards,

Daniel



Am 09.07.2017 um 13:18 schrieb Harry van Haaren:
On Sun, Jul 9, 2017 at 11:21 AM, Daniel Schürmann <dasch...@mixxx.org 
<mailto:dasch...@mixxx.org>> wrote:


Hi Harry, Hi Be,

here some comments:

IMHO arguing about If C or JS is easier will not lead us ahead in
this discussion.


Good point - apologies for the rat-hole.

> As noted above, we can take TCC off the table for Mixxx's use
case. Personally I still love it - and it has radically changed
how I think about programming in C - but perhaps its just not a
good fit for Mixxx. I can work with that.

I am afraid a mandatory TCC based Ctlra solution will prevent it
from being successful.


At no point to I think Ctlra will *require* also using TCC. It just so 
happens that they complement each other well for my use-cases.


Only a solution that works nice Windows as well as on non X86
based architectures will be accepted as a new standard.


TCC supports a variety of targets; and despite no official releases, 
the git repo is pretty active: http://repo.or.cz/w/tinycc.git


For me, the key is here to be modular. Similar to LV2 each driver
Ctlra driver can be shipped with a source file and a meta-data
file which should contain a recipe to turn the source file into a
*.so or a dll. In a future advanced step, the hosts Ctlra library
code should be responsible to read the recipe and do what it
should be done to turn it into a binary.


I'm not sure what the benefit is here - i see a pretty complex 
workflow, but no ultimate gain that TCC doesn't already provide. But I 
said I'd drop the TCC idea and discuss other options.


> Lets find a better solution for novice / casual users who don't
want to compile anything.

The compile step itself is not the issue. If we look for example
to OpenGL Shading Language, where we also have a compiler step no
one noticed.


Good point.

>> Even if we have a ctlra controller in Mixxx, we need to adapt
the signals to Mixxx Control Objects using xml or js files.

> Why XML or JS? I see many more options, and just because we have
existing infrastructure for a similar case doesn't mean its always
the correct solution.

Jus

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

[Daniel Schürmann]

Hi Harry, Hi Be,

here some comments:

IMHO arguing about If C or JS is easier will not lead us ahead in this 
discussion. Both are easy and hard in different aspects. It is all an 
issue about "Know your tools".  The embedded developers in the 
controller companies will be most likely C-Natives. So for now I think a 
C driver in a C library is not that bad, because it does not introduce a 
second programming language.
From the security aspect, we have the same issue for LV2 effects they 
can crash Mixxx. This can be solved by fixing them or move them to a 
quarantine process.  But this decision can IMHO not be done inside Ctlra.


> As noted above, we can take TCC off the table for Mixxx's use case. 
Personally I still love it - and it has radically changed how I think 
about programming in C - but perhaps its just not a good fit for Mixxx. 
I can work with that.


I am afraid a mandatory TCC based Ctlra solution will prevent it from 
being successful. Only a solution that works nice Windows as well as on 
non X86 based architectures will be accepted as a new standard.
For me, the key is here to be modular. Similar to LV2 each driver Ctlra 
driver can be shipped with a source file and a meta-data file which 
should contain a recipe to turn the source file into a *.so or a dll. In 
a future advanced step, the hosts Ctlra library code should be 
responsible to read the recipe and do what it should be done to turn it 
into a binary.


> Lets find a better solution for novice / casual users who don't want 
to compile anything.


The compile step itself is not the issue. If we look for example to 
OpenGL Shading Language, where we also have a compiler step no one noticed.


>> Even if we have a ctlra controller in Mixxx, we need to adapt the 
signals to Mixxx Control Objects using xml or js files.


> Why XML or JS? I see many more options, and just because we have 
existing infrastructure for a similar case doesn't mean its always the 
correct solution.


Just because Mixxx is using it right now. It is IMHO not in the responds 
of Ctlra to convert controller events into application commands.



> I'm still not convinced it is possible for any point-and-click system 
to fully map most controllers *in a maintainable way*.  ...


This is should be out of scope of Ctlra.

IDEA:

Thinking of all of this again, I think this Ctlra project is a great 
chance to fix some issues, existing standards have.


* Midi: Midi is that successfully, because it is defined up to the 
Application layer for a Midi-Keyboard. Reusing this for other types of 
controllers works, but pushes it down to the Presentation Layer.
* OSC: OSC fails to define the Application layer. It is promoted to be a 
Midi successor, but it even has no standard way to even transport good 
old midi messages. There are approaches to fix this in some OSC 
namespaces, but this is somehow stucked.


It would be grate If we could get back to the state of original Midi 
Plug-And-Play behaviour for Midi-Keyboard for all type of controllers 
using Ctlra. If we do this along with a OSC namespace for Ctlra, this 
will be a great benefit and probably a very successfully.


On a Midi-Keyborad you know exactly which phsical key is pressed an how 
just looking to the midi Message.
This can be done for Ctlra as well, I we define a message like "Gain 
Knob Deck A 56 %" So a new controller will be instantly usable for Mixxx 
with a basic default mapping. This is probably not sufficient, but 
putting a new function on "Gain Knob Deck A" can be done by existing 
mapping solutions.


I have these Architectures in mind:

OpenAV setup:

HID-Controller
 V
Ctlra Driver
 V
Cltra Lib
 V
C Mapping
 V
OpenAV App


Mixxx setup:

HID-Controller
 V
Ctlra Driver
 V
Cltra Lib
 V
Controller Proxy
 V
XML / *js mapping
 V
Mixxx engine



Gnereic OSC setup:

HID-Controller
 V
Ctlra Driver
 V
Cltra Lib
 V
OSC Wrapper (process)
 V
   UDP/TCP
 V
OSC to OSC mapper
 V
UDP/TCP
 V
OSC enabled DAW




What do you think?

Kind regards,


Daniel









Am 09.07.2017 um 06:52 schrieb Be:

Hi Harry,
I read the paper for the presentation at LAC 2017 that you linked on IRC:
http://musinf.univ-st-etienne.fr/lac2017/pdfs/01_C_E_137795.pdf

Going along with what I mentioned in my previous post, I do not think 
Ctlra should be aware of the "userdata". IMO that should be left to 
the application and its scripting environment.


On 07/08/2017 08:36 PM, Be wrote:

On 07/08/2017 06:51 PM, Harry van Haaren wrote:

3. The programming language. It is a lot easier to find someone who
knows JavaScript, or at least kinda knows JavaScript enough to get
by for a small project, than it is to find someone who knows C. For
people with minimal or no prior programming experience, higher 
level

languages are much easier to learn.


Surely anybody somewhat proficient in JS can 

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

[Daniel Schürmann]

Hi Be, Hi Harry,

I share Be's concerns about TinyCC compiler. On one hand it is available 
in the Ubuntu repos, on the other hand it is "not recommended for

production use" in the explaining text.

But that is not a big problem. For me it makes no difference if we 
dynamic ling a device.so file generated from TinyCC or GCC.
GCC is available by default and calling it from ctlra or manual should 
not a big issue. We most likely cannot rely on TinyCC for Windows anyway.


I think we have to distinguish between two areas of device depended code.
1. The driver part, which presents the controller in a generic way like 
it already happens with midi controllers
2. The application mapping, to adapt application features to controller 
features.


If I get it right, ctlra aims to cover only 1. Even if we have a ctlra 
controller in Mixxx, we need to adapt the signals to Mixxx Control 
Objects using xml or js files.


From this point of view, it would be kind of odd to have an other 
scripting engine in action just for 1. If this is also the QT js engine 
this would be great for Mixxx, but not for all other Ctlra using 
applications not Qt based.


From this point of view a pure C implementation works probably best.

The other point of view is the knowledge out there among audio artists.
Here are two stats sources:

https://octoverse.github.com/
https://www.tiobe.com/tiobe-index/

> 1. Is it possible for a controller mapping to crash the application?
> That should not happen under any circumstance.

If we go for C drivers, yes. This could be handled by putting Ctlra into 
a quarantine process, but this consumes the c performance gain and would 
put whole Ctlra into question compared to OSC.


> 2. If a user wanted to replace a precompiled mapping that came with
> Mixxx with one they made or got online, what would that process go 
like? Would the user need to install TCC? Would we have to include TCC 
in Mixxx?


Mixxx should already have access to a C compiler, if we decide to go the 
C way. The other option would be to share pre-compiled *.so files.

But they are not cross platform and can contain a trojan.

> 3. The programming language. It is a lot easier to find someone who
> knows JavaScript, or at least kinda knows JavaScript enough to get by
> for a small project, than it is to find someone who knows C. For people
> with minimal or no prior programming experience, higher level languages
> are much easier to learn.

This is not a biggest issue for me, because even if you know Javascript 
or likewise C, you cannot instantly start over to hack up your driver.
You need a lot of reading and probably reverse engineering, which is 
probably harder than adopt a sample script of a partly unknown language.


IMHO the success of Ctlra depends to a high degree to the numberer of 
supported popular controllers. If we manage to push this number up, all 
the technical issues are secondary. If we fail, Ctlra is just another 
controller interface to support. https://xkcd.com/927/


Kind regards,

Daniel










Am 08.07.2017 um 22:00 schrieb Be:
Thanks for taking up this project! Reading your proposal on the wiki 
page, the way you intend to integrate into Mixx's ControllerManager and 
Controller classes makes more sense now.


The big question I am wondering about is the process of creating the 
mappings from Ctlra events to Mixxx's state. Your idea to use TCC is 
interesting and I think it's no problem for a proof-of-concept, but I am 
doubtful it would be a good way to integrate Ctrla support into 
applications for several reasons:
1. Is it possible for a controller mapping to crash the application? 
That should not happen under any circumstance.
2. If a user wanted to replace a precompiled mapping that came with 
Mixxx with one they made or got online, what would that process go like? 
Would the user need to install TCC? Would we have to include TCC in Mixxx?
3. The programming language. It is a lot easier to find someone who 
knows JavaScript, or at least kinda knows JavaScript enough to get by 
for a small project, than it is to find someone who knows C. For people 
with minimal or no prior programming experience, higher level languages 
are much easier to learn.
4. Mixxx, and other applications, already have systems for supporting 
MIDI controllers. Like Mixxx, some of these applications already have 
their own scripting environments. Maintaining code and documentation for 
separate ways for mappings to interact with the application would be a 
burden for the application developers. For controller mapping 
developers, their experience would be totally different depending on 
whether they were mapping a MIDI controller or a Ctlra supported 
controller. This would be a barrier to sharing knowledge and code 
between people mapping MIDI controllers and Ctlra supported controllers.
5. TCC is unmaintained. The last release was 4 years ago. If we found 
issues with it, it would probably be upon us to fix them. I for one 

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

[Daniel Schürmann]

Hi Harry,

I have looked a bit closer to the concepts of Ctlra, and it has a strong
issue: "The device specific files are written in c."

In terms of am everage use, a library is updated by the various Linux
distros in a two years cycle. I am in doubt that the manufacturer a will
ship a Ctlra build along with there hardware. So it takes about two years
after a brand new controller reaches the Ctlra shipped with distros.
Looking at pre-installed default mappings Mixxx suffers the same issue.

There is only a minority of users a talented musician, spending a
reasonable amount of money for a new controller and a talented C programmer
at the same time. It is a high hurdle to set up an build environment,
reengineer the controller, build a library and make it work.

If the user actually manages this, it is another hurdle to bring the device
specific into a rock solid maintainable state and merge it upstream. And
even if the user manages all these, the upstream maintainer cannot verify
the proposed  code, because he most likely did not own the new shiny
controller as well. Mixxx has the same issue regarding pre-installed
default mappings.

 fortunately Mixxx has a point and click GUI to map even unknown
controllers. It provides an outstanding scripting engine that is relative
easy for simple tasks but has the full power of a
Touring-complete language. Integrating a brand new hid mapping still
requires bit smashing, but at least it can be done with a simple text
editor, nothing more.

Did you get the point?

How to solve this?

Not sure if it works, but how about benefit from all the work already done
in Mixxx? Instead of making Ctlra a new controller type in Mixxx we can put
it between the Mixxx engine an the Mixxx controller mapping.
This way all openAV apps can benefit from the existing mappings in Mixxx
and from the sounds scripting language to solve hard issues. Mixxx can
benefit from modern controller support contributed directly to openAV.

What do you think?

Kind regards,

Daniel



Am 07.07.2017 1:07 vorm. schrieb "Daniel Schürmann" <dasch...@mixxx.org>:

> Hi Harry,
>
> welcome to Mixxx.
>
> That is awesome.  :-)
> A BIG thank you to make this real!
>
> I have just skimmed over the linked resources and it looks like this
> closes exactly the gap between Mixxx and HID controllers.
>
> Currently Mix has HID controller support, but it requires scripting, and a
> lot of bit mashing to make a controller work.
> Unlike MIDI controllers, you cannot learn them via point and click GUI.
>
> You need a lot of knowledge of the interns of the controller.
> It is a great idea to put this knowledge in a single library and share
> these info between all Linux Audio Projects.
>
> Are you going to contribute to Mixxx an work towards an Ctlra interface?
>
> Here are some links:
>
> Our HID API js is described here:
> https://www.mixxx.org/wiki/doku.php/hid_device_api
>
> Which is used for example here:
> https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0f
> fac4b2afd7359afa8a/res/controllers/Nintendo-Wiimote.js
>
> Here is a good introduction how we work in the Mixxx project:
> https://www.mixxx.org/wiki/doku.php/bugfix_workflow
>
> If I understand the Ctlra concept correct, it can finally replace all our
> controller APIs on a long run. On a short run, it can be used parallel to
> portmidi, right?
>
> The portmidi implementation can be found here:
> https://github.com/mixxxdj/mixxx/tree/master/src/controllers/midi
> https://github.com/mixxxdj/mixxx/blob/2cf29ba14da099a9d19f43
> 5a71b2ee95b9f4815e/build/depends.py#L28
>
> Can we roughly name the steps to do? :
> * crate src/controllers/ctlra
> * copy all files over
> * adopt them for ctlra
>
> Of cause there will be a lot more things to consider.
>
> Do you see a chance to port this to Mac and Windows as well?
>
> Kind regards,
>
> Daniel
>
>
>
>
>
>
>
>
>
>
>
> Am 06.07.2017 um 23:57 schrieb Harry van Haaren:
>
>> Hi All,
>>
>> First of all - this is my first post to the Mixxx-devel list, so a brief
>> intro is in order;
>> I'm Harry van Haaren, developer of the OpenAV audio software, bit of a
>> music/tech/linux head :)
>>
>> I've recently been working on improving controller support in Linux audio
>> land, in particular
>> what I call "modern USB HID" controller devices (think DJ controllers
>> like Akai/NI/Abletons range).
>> I've developed the Ctlra library as OpenAV, which provides access to
>> these hardware devices
>> on Linux. The library allows hotplug and various other "advanced"
>> features like accessing
>> screens on devices.
>>
>> I'd like to integrate Ctlra into Mixxx - to provide access to hard

Re: [Mixxx-devel] [Feature Proposal] Ctlra Controller Hotplug Support

[Daniel Schürmann]

Hi Harry,

welcome to Mixxx.

That is awesome.  :-)
A BIG thank you to make this real!

I have just skimmed over the linked resources and it looks like this 
closes exactly the gap between Mixxx and HID controllers.


Currently Mix has HID controller support, but it requires scripting, and 
a lot of bit mashing to make a controller work.

Unlike MIDI controllers, you cannot learn them via point and click GUI.

You need a lot of knowledge of the interns of the controller.
It is a great idea to put this knowledge in a single library and share 
these info between all Linux Audio Projects.


Are you going to contribute to Mixxx an work towards an Ctlra interface?

Here are some links:

Our HID API js is described here:
https://www.mixxx.org/wiki/doku.php/hid_device_api

Which is used for example here:
https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/res/controllers/Nintendo-Wiimote.js

Here is a good introduction how we work in the Mixxx project:
https://www.mixxx.org/wiki/doku.php/bugfix_workflow

If I understand the Ctlra concept correct, it can finally replace all 
our controller APIs on a long run. On a short run, it can be used 
parallel to portmidi, right?


The portmidi implementation can be found here:
https://github.com/mixxxdj/mixxx/tree/master/src/controllers/midi
https://github.com/mixxxdj/mixxx/blob/2cf29ba14da099a9d19f435a71b2ee95b9f4815e/build/depends.py#L28

Can we roughly name the steps to do? :
* crate src/controllers/ctlra
* copy all files over
* adopt them for ctlra

Of cause there will be a lot more things to consider.

Do you see a chance to port this to Mac and Windows as well?

Kind regards,

Daniel











Am 06.07.2017 um 23:57 schrieb Harry van Haaren:

Hi All,

First of all - this is my first post to the Mixxx-devel list, so a brief 
intro is in order;
I'm Harry van Haaren, developer of the OpenAV audio software, bit of a 
music/tech/linux head :)


I've recently been working on improving controller support in Linux 
audio land, in particular
what I call "modern USB HID" controller devices (think DJ controllers 
like Akai/NI/Abletons range).
I've developed the Ctlra library as OpenAV, which provides access to 
these hardware devices
on Linux. The library allows hotplug and various other "advanced" 
features like accessing

screens on devices.

I'd like to integrate Ctlra into Mixxx - to provide access to hardware 
currently not available
to Linux users, and also to provide hotplug support to those 
controllers. I've created a blueprint
on Launchpad[1], and written an introduction on Ctlra and how I propose 
to integrate it in Mixxx[2].
Finally, there is a documentation page on what Ctlra itself achieves 
here[3], and the source is here[4].


If you have an interest in hotplug of controllers, controller support or 
hardware on Linux,
do have a read of the wiki page and others, and I'd appreciate your 
input on the ideas!


Thanks for all your efforts on Mixxx so far, onwards and upwards!
-Harry of OpenAV

[1] https://blueprints.launchpad.net/mixxx/+spec/ctlra-controller-support
[2] https://www.mixxx.org/wiki/doku.php/ctlra_support
[3] http://openavproductions.com/doc/ctlra.html
[4] https://github.com/openAVproductions/openAV-ctlra

--

http://www.openavproductions.com


--
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] Nested crates status

[Daniel Schürmann]

Hi Waylon,

we already have a in memory cache off all tracks. I am in doubt if moving
to he filters to memory as well will gain any performance, since sqlite
itself has also a memory cache.

Can you do a scribble, that shows what looks worse and what look good in
you eyes?

Did you had a look into Joan's library redesign branch?
https://github.com/mixxxdj/mixxx/pull/1117

Is it good or worse?

Thank you for your help.

Kind regards,

Daniel

Am 05.07.2017 5:20 vorm. schrieb "Waylon Robertson" <
wrobertson1...@gmail.com>:

Hello All, Gramanas:
How is the nested crates feature coming?

I'm a dj, living live on the edge, .. that is, im using the master in
a live enviroment, plus a couple of branches pulled in, (WriteTags and
Ratings).

Thank you for the crate filter, excellent work. Looking forward to
nested crates and smart crates. One problem though, is the ui lock
time while searching/changing crates. Will it get worse, using smart
crates, or exactly the same as current?

Thank you to those who redone the database code. Searching and moving
about is now a lot faster, but still could be improved. What about a
in-memory cache of the database, ala memcache?

Waylon


--
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] sync button and LONGPRESSLATCHING for master sync

[Daniel Schürmann]

Thank you for the tutorial Links.

It looks  like Serato targets the issue a bit different. It has "smart 
sync", that falls off as soon you touch anything from the deck. That is 
pretty much the same than our one time sync feature. I like our approach 
more, because you have both sync modes available at the same time. 
Unfortunately there is not explained how smart  sync works with non 
const beat grids.


But anyway I think we have a conclusion here that a preference option, 
to enable sync with a short click is a good idea. Right?





Am 28.06.2017 um 22:23 schrieb Be:

On 06/28/2017 09:38 AM, Owen Williams wrote:

There are lots of situations where DJs just want a one-shot sync without
locking two tracks together.  This is especially true if they are going
to do any scratching tricks like backspins or vinyl break stops.


I don't use vinyl or jog wheels, so I'm not sure how Mixxx behaves 
with sync in these situations. I thought Mixxx only manipulates the 
deck being scratched regardless of whether it has master sync on, in 
which case I don't understand how it would make a difference whether 
pressing the sync button turns on master sync or does a one time sync.



And,
most DJ applications and hardware still operate on the "tap once to
sync" and don't support an advanced master mode like we have. So I
think new users would get confused if suddenly the decks are "tied"
together just because they synced tempo.


Serato and Traktor have functionality like Mixxx's master sync to keep 
manipulate the tempo of multiple decks together except it is toggled 
with a preference option and does not require holding the sync button 
to activate.


Traktor sync tutorial: https://www.youtube.com/watch?v=VZ7TQ1Z1BUo
Serato sync tutorial: https://www.youtube.com/watch?v=oD9J7azlhrQ



I think if you or any other user prefers master sync as a toggle button,
it's fine to map the sync buttons on one's own controller to toggle
master sync.  But the default really should be to tap for momentary,
hold for lock.  The lights on the buttons should reinforce this.  The
sync button should stay lit when master is on, whereas it'll be off when
sync is off.
Were any usability tests done when developing the master sync 
workflow? I wouldn't be surprised if there are still lots of Mixxx 
users who aren't aware that master sync exists. Even though it is 
explained in the manual and in the tooltip, why would a user think to 
look at the tooltip or hold the button down if they click the button 
and it seems to do what it is labeled for?




This is a great example, btw, where "controller preferences" would
really help. A simple checkbox for "sync always enables master" would be
super convenient.


I am not sure I agree. This issue applies to skins as much as it does 
to controller mappings. I think controller preferences should be for 
changing options specific to that device. This is a general issue that 
applies to any controller with a sync button, which is just about 
every DJ controller, so I think it should be handled by Mixxx.




On Tue, 2017-06-27 at 20:39 -0500, Be wrote:

In a recent pull request ( https://github.com/mixxxdj/mixxx/pull/1244 )
I modified the SyncButton object in the Components controller mapping
library to behave like the sync buttons in skins. Short presses only 
use
the beatsync Control for one-time sync and long presses use 
sync_enabled
for master sync. Previously I had it so it just used sync_enabled 
like a

normal toggle button. The more I use the new way that mimics the skins,
the less I like it. I always want to use master sync when I press the
button, but sometimes I forget to hold down the button. That is not
something I want to have to think about while mixing. Forgetting to 
hold

down the button has messed up some mixes because I expected decks to
stay synced as I changed the tempo of one of them, but only one of them
changed tempo.

Is there a use case for using master sync sometimes but not all the
time? Perhaps it would be better to make a new preference option that
determines whether the sync button is a toggle button for master 
sync or

a push button for the old one-time sync. What do you think?

-- 


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

Re: [Mixxx-devel] sync button and LONGPRESSLATCHING for master sync

[Daniel Schürmann]

The use case is, if you have non const beat grid in the master deck. In
this case the follower deck tries to follow this, which can sound funny. So
in this case you want just adopt the tempo one time to start the transition
and after that you have not think any longer about it.

I think it depends on the type of  tracks an DJ style what works best.

Historical we come form a one time sync before master sync was implemented.
So it was natural to keep this behaviour on a normal click.

A preferences option works for me.
We schould keep the current behavior as default, because I get used to it
and it fits my type of music well.

Kind regards,

Daniel.


Am 28.06.2017 3:40 vorm. schrieb "Be" :

In a recent pull request ( https://github.com/mixxxdj/mixxx/pull/1244 ) I
modified the SyncButton object in the Components controller mapping library
to behave like the sync buttons in skins. Short presses only use the
beatsync Control for one-time sync and long presses use sync_enabled for
master sync. Previously I had it so it just used sync_enabled like a normal
toggle button. The more I use the new way that mimics the skins, the less I
like it. I always want to use master sync when I press the button, but
sometimes I forget to hold down the button. That is not something I want to
have to think about while mixing. Forgetting to hold down the button has
messed up some mixes because I expected decks to stay synced as I changed
the tempo of one of them, but only one of them changed tempo.

Is there a use case for using master sync sometimes but not all the time?
Perhaps it would be better to make a new preference option that determines
whether the sync button is a toggle button for master sync or a push button
for the old one-time sync. What do you think?


--
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] LateNight and Shade skins in Mixxx 2.1

[Daniel Schürmann]

> It seems we have an emerging consensus to remove Shade and update
LateNight. Are we in agreement on this?

Not yet. Here are my Netbook Test results:

Mixxx load time:
* Shade 7 s
* Tango 59 s
* Deere 2.1 32 s

Deere 2.1 issues:
* To big for maximized, view. Window decoration and task bar at too big
(Linux Mint)
* Everything is looking quite oversized and foreign. Important infos like
waveform overview is quite small.
* Mixer region is squashed (overlapping knobs) if skin setting is open.
* The same happens in the looping region and header bar.
* Library cover art consumes too much space from the tree view.
* Title font is to big, always elided.
* No knob for adjusting key.
* No way to start broadcasting from the skin.
* Insufficient broadcast status.
* Star rating consumes space of the artist name.
* Four decks, no library.

Tango:
* Decks are scaling well, bottom bar looks oversized.
* Shut down time is also quite long, including the famous "app does not
react" message.
 * Crash with GL waveform, strange.

Conclusion:
Keep Shade.
Deere does not work good. Tango works by design, but 59 s start up time is
a no go. For now I will continue to use Shade on this device.

I think it would be best to optimize Shade even more for small screens
using the well working Tango layout.

LateNight:
I am curious to hear Owens opinion.
For now I think we can drop Shade if we have a yellowish alternative.



Am 28.05.2017 7:08 nachm. schrieb "Be" <b...@gmx.com>:

> On 05/28/2017 12:04 PM, Be wrote:
>
>> On 05/28/2017 11:36 AM, Daniel Schürmann wrote:
>>
>>> @Stephan: thank you for stepping in here.
>>>
>>> Is a card wall only skin really sufficient for a radio station, or is it
>>> only one device, along with a dual CD player and such?
>>> Looking at dedicated broadcasting apps, the often feature a card wall
>>> with a common volume slider + two dedicated decks we with individual
>>> volume sliders.
>>> Should we consider this his ad well?
>>>
>>
>> Yes, the current sampler grids are just a quick hack to approximate a
>> more versatile sampler deck feature. With the Hercules P32 mapping I
>> have made these work more like decks by making the controller script
>> assign the samplers to the corresponding sides of the crossfader. It
>> would be great to group samplers into a virtual "deck" with all the
>> normal deck controls like volume faders and EQs. This would also make it
>> more practical to manage putting effects on samplers. We should look
>> into Traktor's sampler deck and remix deck features for inspiration. I
>> think we can come up with a single unified sampler/remix deck feature
>> that could work equally well for live remixing and radio DJs.
>>
>>
> I think a sampler/remix deck feature would be a good GSoC project for next
> year, unless a contributor steps up to implement it before then.
>
> 
> --
> 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] LateNight and Shade skins in Mixxx 2.1

[Daniel Schürmann]

@Stephan: thank you for stepping in here.

Is a card wall only skin really sufficient for a radio station, or is it
only one device, along with a dual CD player and such?
Looking at dedicated broadcasting apps, the often feature a card wall with
a common volume slider + two dedicated decks we with individual volume
sliders.
Should we consider this his ad well?

@be: why not add a dedicated "Deere Card Wall"? This can be re-use all
files from the Deere folder, just coming with its own skin.xml. For such a
radio use case, all additional configuration features are just clutter.
Instead we can focus on different config options, we discover usefull for
radio DJ as required when using it.

The extra window card wall extending current​ Deere is also a good idea an
should not be hard to implement following RJs idea in the liked bug.

Of cause it is not that flexible as we now it from certain development
tools, but it exactly solves the use case to drive a disk screen setup. I
prefer that way, as a short term solution, instead of waiting ages for a
widged docking skin.


Am 28.05.2017 6:00 nachm. schrieb "Be" <b...@gmx.com>:

I do not see anything different from a "cart wall player" and a grid of
samplers other than the name. Cart wall software displays more information
at a glance on the samplers like user defined color coding. Those features
do not yet exist in Mixxx. It would be nice to add them and not just for
radio users. I don't think this will require separate skins for radio DJs.


On 05/27/2017 06:20 PM, Stéphane Lepin wrote:

> Hi everyone,
> I think a dedicated "carts-only" skin, with only samplers and library
> access, could be an interesting addition for radio people, as this
> category of users would not be immediately interested by the DJing decks
> while looking for a cartwall software. I quickly tweaked LateNight to
> add more sampler decks, so I will try to make a draft cartwall-only skin.
>

This is already possible with Deere by dragging the decks/library splitter
all the way to the top. We could add an option to the skin settings menu to
make it more obvious and add the same option to Tango.

Looking at Deere this way, I think the vertical order of the parts of the
skin might be a little odd for radio DJs: samplers, mic/aux inputs, then
library. Would it be better to put the mic/aux inputs above the samplers?
Maybe effects should go below both mics/aux and samplers?



> Idea: add a dedicated window for the cartwall/sampler decks. This would
> especially be useful for home radio studios, where radio DJs with
> dual-monitor setups could use Mixxx's DJ decks (with or without AutoDJ)
> on one screen and put a large cartwall window on another screen.
>

It would be nice if we could have parts of the skin in a separate window,
but the skin system has no way to do this. It would be pretty tricky to
make this work well with the existing system. Refer to the discussion on
https://bugs.launchpad.net/mixxx/+bug/1152575


> Kind regards,
> Stéphane Lepin
>
> 2017-05-27 22:35 GMT+02:00 Daniel Schürmann <dasch...@mixxx.org
> <mailto:dasch...@mixxx.org>>:
>
>
> Hi,
>
> I have found a good reference for a card wall player I had in mind:
> https://www.youtube.com/watch?v=1JBaUZo51mg
> <https://www.youtube.com/watch?v=1JBaUZo51mg>
>
> I think it would be far more straight forward to start from the
> scratch instead of putting this into Deere and Tango. On the other
> hand It will also work as a view setting for one of them: "Radio mode"
> Finally it is only the way to get to it. Switch skin vs. Switch view
> option. Remember that we had a lot more skins in Mixxx 1.1, one for
> every resolution.
>
>
> > I don't think "instantly usable by default" is necessary, as long as
> it is easy and obvious how to configure the skin settings for a radio DJ
> use case.
>
> Yes, that is the point. A new user should be instantly be aware that
> Mixxx has a radio mode, that's all.
>
> > I suggest trying Tango and the updated Deere skins on your netbook
> before deciding to put in the work to update Shade. If there are some
> modifications we can make to those skins to work better for netbooks, that
> would be a lot less work than updating Shade.
>
> Yes of cause, I will do this, this is already planed.
>
> >> How about to save the yellowish​ into Deere?
> >> This way we can argue, that we have merged Deere and LateNight?
>
> > Definitely not. The reason I started working on Deere was because I
> like its color scheme.
>
> Why not, you could keep the blue color schema and add a yellow one.
> The colour is just a matter of taste and it was considered as
> beautiful when it w

Re: [Mixxx-devel] LateNight and Shade skins in Mixxx 2.1

[Daniel Schürmann]

Hi,

I have found a good reference for a card wall player I had in mind:
https://www.youtube.com/watch?v=1JBaUZo51mg

I think it would be far more straight forward to start from the scratch 
instead of putting this into Deere and Tango. On the other hand It will 
also work as a view setting for one of them: "Radio mode"
Finally it is only the way to get to it. Switch skin vs. Switch view 
option. Remember that we had a lot more skins in Mixxx 1.1, one for 
every resolution.



> I don't think "instantly usable by default" is necessary, as long as 
it is easy and obvious how to configure the skin settings for a radio DJ 
use case.


Yes, that is the point. A new user should be instantly be aware that 
Mixxx has a radio mode, that's all.


> I suggest trying Tango and the updated Deere skins on your netbook 
before deciding to put in the work to update Shade. If there are some 
modifications we can make to those skins to work better for netbooks, 
that would be a lot less work than updating Shade.


Yes of cause, I will do this, this is already planed.

>> How about to save the yellowish​ into Deere?
>> This way we can argue, that we have merged Deere and LateNight?

> Definitely not. The reason I started working on Deere was because I 
like its color scheme.


Why not, you could keep the blue color schema and add a yellow one.
The colour is just a matter of taste and it was considered as beautiful 
when it was introduced. Sometimes a color can also be an eye-catching 
and characteristic design, even it is out of fashion.



>> Also, there's another debate that is ignored but should not, and has 
to do with loading times. It is known that Deere takes nearly double the 
time than Latenight to load. On a fast machine this is just a minor 
thing (if you're not relaunching the application many times to test 
something), but on older machines speed can be a decision to choose one 
over another.
>> I don't know if it is fully consequence of using SVG vs PNG, or 
other reasons apply.


> That is an issue. I'm not sure why there is such a big difference in 
load times. If rendering SVGs is the issue, we could cache the rendered 
SVGs in the user settings folder the first time a skin is loaded for 
faster startup times after that. That way the vectors can be scaled 
appropriately for the screen resolution and have faster startups.


The SVG rendering is one mayor time eater. The other are the plenty skin 
options, because all of them are instantiated in the device memory.


Pre rendering the SVGs will help, but it will bypass the graphic card 
rendering and scaling in Mac OS. Keeping a low end skin is IMHO more 
straight forward here and solves both issues.





Am 27.05.2017 um 18:29 schrieb Be:



On 05/27/2017 11:00 AM, Josep Maria Antolin wrote:
 > Also, there's another debate that is ignored but should not, and has to
 > do with loading times. It is known that Deere takes nearly double the
 > time than Latenight to load. On a fast machine this is just a minor
 > thing (if you're not relaunching the application many times to test
 > something), but on older machines speed can be a decision to choose one
 > over another.
 > I don't know if it is fully consequence of using SVG vs PNG, or other
 > reasons apply.

That is an issue. I'm not sure why there is such a big difference in 
load times. If rendering SVGs is the issue, we could cache the rendered 
SVGs in the user settings folder the first time a skin is loaded for 
faster startup times after that. That way the vectors can be scaled 
appropriately for the screen resolution and have faster startups.


On 05/27/2017 11:00 AM, Josep Maria Antolin wrote:


I am not too good at graphics, and haven't looked much about making
skins, so I'm not be best candidate to maintain the skin, althought
seeing that the other option is removing the skin, I guess I will have
to take some time and work the todo list that you mentioned above.
I guess we could remove some of the yellow parts too, or at least make
them color schemes.



I'm not too good at graphics either, but most of what you need is 
already there. It's mostly a matter of rearranging the UI with the skin 
XML. There are a few new icons that will need to be made. Even if you 
aren't great at graphics you can make a first draft for those icons 
while working on the skin XML. Then someone who has more graphic design 
skill can tweak the icons.


Speaking of which, if anyone wants to improve the new beatloop and 
reloop icons in Deere 2.1, please contribute.


--
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] LateNight and Shade skins in Mixxx 2.1

[Daniel Schürmann]

Deere and Tango both support all 4 mic & aux inputs supported by Mixxx.
Fader start is not a skin issue. I think a big wall clock would probably be
better served by an actual wall clock rather than a computer screen. Deere
and Tango both have on-air indicators, but they could be more prominent if
that's desired.


It is good to have two full featured skins that features two design tastes.
By default, they schould be instantly usable for the main Mixxx use case:
live DJing
and the school allow access to almost all features. Allow to configure them
for other use-cases is also a good idea, as long there is no drawback for
the main use-case. So we are on the right track here.

With add additional skins, we do not need to focus on full featured live
DJing. We have the chance to "promote" alternative use-cases without all
considerations required for a default skin. This is IMHO true for "Radio",
"Jukebox", "Touch", "Legacy Netbook" and "Design". Loading such skins from
online is a two big thesshold for evaluating users.


If we want to desig n for radio DJs, we should do usability tests with
radio DJs. Watching real people interact with the design is much more
useful than asking people on the Internet for feedback. Usability tests are
quite easy to do: https://www.youtube.com/watch?v=VTW1yYUqBm8


I fully agree. I hope Stéphane, finds time during his GSoC to do some
usability tests with his colleagues (real radio DJs).


What's a Card Wall Player?


Maybe one else in this list can explain it. AFAIK, it is a button grid with
buttons to start samples. The buttons have different colours and blink
schemas to indicate the state and type. In a GUI these infos can be plain
text as well.

> If there are improvements that would help radio users, I'd rather modify
Tango and Deere than fork them or make a new skin.

I welcome a Card Wall Player in Tango and Deere. But this does not replace
a dedicated radio skin which is instantly usable by default.


>
> A good skin maintainer for a radio skin, is most likely not a good
> maintainer for a DJ skin. But a good skin with a consistent design is
> maintained the best by a single developer/design artist.
>
>
I disagree. A good skin is best designed by a team collaborating and
reviewing each others' work.


This is true for usability, but not for design. From my experience a good
design is usually a monolith. The team can select between Design A and B,
but a mix between both looks usually odd.
I have also the odd experience, that a good design sells better than a good
usability.


>

All skins should support all features, otherwise some users will have to
choose between features and their preferred aesthetics. Users should not be
tied to a skin because their controller mapping doesn't work well with
other skins.


I disagree. If we have a let's say radio skin with an outstanding design.
It is just a pity for the average user he cannot choose that.

I think Deere and Tango both demonstrate that if a GUI is well designed it
can satisfy many use cases without the maintenance burden of a skin for
each use case.


Good work so far! But not a reason to reject other already working skins.

We need peer review, input from people using Mixxx in different ways, and
empirical observations from usability tests to create good designs.


I agree if you mean usability, an not design in terms of beauty.

Like good code, good designs generally don't come from just one person
pursuing their idea.


Finally we need here a conclusion what should happen with Shade and Late
night. I a willing to put some love to Shade, since I actually use it
successfully on my Netbook.

LateNight can be IMHO dropped, since it does not provide a special use
case. How about to save the yellowish​ into Deere?
This way we can argue, that we have merged Deere and LateNight?

By the way: in terms of beauty, I am still sad about dropping 1.1 Deere.
This was quite polished am unique.
--
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] 2.1 blocker bug: Offset in waveforms after 2.1 upgrade

[Daniel Schürmann]

Hi,

We need a decision on this bug:
https://bugs.launchpad.net/mixxx/+bug/1666275

Due to fixed decoding issues there can be waveform offsets if you upgrade
from 2.0 2.1 which makes you beat grid and cue points off beat. In 2.0 the
user can already have this off beat situation after seek jumping over a
place with a decoding issue.

If we invalidate all beat-grids during migration, the user has nothing and
will hate us. If we silently do nothing he will mix a wrong beat and will
hate us as well.
Al users which are already at 2.1. might have already dealed with this
situation.

A full featured solution will be a auto detection of this situation with a
warning and optional user actions. This is an expensive and complex task,
unlikely to be happened.

What would be a good solution avoiding bad surprises after update.

Any ideas?

Thank you for your help,

Daniel
--
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] Final GsoC Application

[Daniel Schürmann]

Anast,

here some thoughts:

What will happen if a user tries to remove a track from a top crates, 
which is also member of a lower level child crate?
Will both be removed?

Can the user distinguish a track in a top crate from on that is 
recursively gapped form a child crate?

We have discussed to use crates like tags.
Do you like the idea ?
Will there be something like a "crate membership" coloumn / search / 
sorting? How is a multi membership handled there?


Kind regards,

Daniel


Am 31.03.2017 um 22:49 schrieb Be:
> This looks better. Could you update your proposed timeline to reflect
> the changes?
>
> On 03/31/2017 02:21 PM, Anast Gramm wrote:
>> On Fri, Mar 31, 2017 at 06:59:48PM +0300, Anast Gramm wrote:
>>> Hello, I wrote a more detailed plan for those two features you metioned for 
>>> the project
>>> scope. I will send it soon after some polishing.
>> here it is (also in pdf below)
>>
>> 1 Nested Crates
>> ===
>>
>>   A preview for the nested crates is included. Tree like view. (If you don't 
>> listen
>>   to the Jazz/Trance sub-genre of Dub, you should!! :D )
>>
>>   The following is derived by the comments on launchpad and my thoughts
>>   on them.
>>
>>
>> 1.1 Overview
>> 
>>
>> 1.1.1 What can a crate contain?
>> ---
>>
>>   A crate can contain the following:
>>   - Another crate (smart or not)
>>   - Songs
>>
>>
>> 1.1.2 Can a song be in multiple crates?
>> ---
>>
>>   Yes.
>>
>>
>> 1.1.3 What happens when I click on a crate
>> --
>>
>>   Recursively lists all the songs that exist in the crate or the
>>   subcrates that it contains. DISTINCT! (eliminates duplicate songs)
>>
>>   ["mixxx's unique selling point!"]
>>
>>
>> ["mixxx's unique selling point!"]
>> https://bugs.launchpad.net/mixxx/+bug/671632/comments/37
>>
>>
>> 1.1.4 What happens when I drag a crate into another one
>> 
>>
>>   If the crate you drag is a parent crate to the one you drop it then
>>   nothing happens. (or an error!)
>>
>>   Else the drag crate and everything that it contains become members of
>>   the drop crate. (like moving files in a file system)
>>
>>
>> 1.1.5 How do I insert a song to a multilevel crate
>> --
>>
>>   You place the song to the crate you want it to become a member of. If
>>   you have multiple levels, the above still holds. If a crate/song
>>   belongs to a child, it belongs to the parent as well.
>>
>>
>> 1.1.6 How many levels will be supported?
>> 
>>
>>   As many as the user wants.
>>
>>
>> 1.1.7 What if I want two crates with different parents have the same name?
>> --
>>
>>   Every crate will contain information about it's parent, so the
>>   following can work:
>>
>>   Crate1/sameSubcrateName
>>
>>   Crate2/sameSubcrateName
>>
>>
>> 1.2 Implementation
>> ~~
>>
>>   Here are some first thoughts on the way the above will get
>>   implemented.
>>
>>
>> 1.2.1 Modifications
>> ---
>>
>>   In order for crates to be able to hold both other crates and songs
>>   some modifications need to be made in the database schema.
>>
>>   A new table with columns:
>>PARENT_ID  CHILD_ID
>>   -
>>......
>>
>>   Here the CRATE_ID will be linked with other CRATE_ID's depending on
>>   the parent/child state of those.
>>
>>   While populating this table checks will occur so that a crate can't be
>>   it's own parent, or a child can't have his parent as a child etc.
>>
>>   The whole crate side of the database might need a revamp for this to
>>   work efficiently and be expandable at the same time. I will look at it
>>   in depth in time.
>>
>>
>> 2 Search filter for Crates
>> ==
>>
>>   Due to the nested crate's complexity I will work on search filters
>>   first, while keeping in mind the future adjustments it might need in
>>   order to work well with nested crates.
>>
>>
>> 2.1 Overview
>> 
>>
>> 2.1.1 What is the search filter for crates
>> --
>>
>>   Typing "crate:" in the search bar, will act like a filter listing
>>   whatever any song within a crate named whatever comes after "crate:"
>>   (fuzzy style). Like "artist:"
>>
>>
>> 2.1.2 What about nested crates
>> --
>>
>>   Say you have a top level crate named (creatively) Crate1 with
>>   subcrates and songs nested under it. Typing crate:Crate1 in the search
>>   will list every song this crate contains and every subcrate's song as
>>   well.
>>
>>
>> 2.1.3 What about the same name subcrates we talked before
>> -
>>
>>   Typing crate:sameSubcrateName will get you both the crates with the

Re: [Mixxx-devel] Final GsoC Application

[Daniel Schürmann]

Hi Anast,

only the pdf you send to http://summerofcode.withgoogle.com/
will be taken into account for the evaluation.

You are free to send it to us before, and take the chance to get some 
hints to improve it before the deadline.

Kind regards,

Daniel


Am 31.03.2017 um 17:59 schrieb Anast Gramm:
> Hello, I wrote a more detailed plan for those two features you metioned for 
> the project
> scope. I will send it soon after some polishing.
>
> Google asks for a pdf in the final application.
>
> Should I write a new document with the ones I send before combined
> and submit it as a pdf there? It's not that clear, so I am asking what would
> you prefere.
>

--
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] Final GsoC Application

[Daniel Schürmann]

Hi Anast,

you Application looks good so far but it requires some more details.

I think you should target your project on top of our new library GUI 
design which will be merged once Mixxx 2.1 is released.
https://github.com/mixxxdj/mixxx/pull/1117

A GUI Mock-up/picture showing the planed feature would be nice.

You should also have a close look on:
https://github.com/mixxxdj/mixxx/pull/726

What is good, what can be improved?

There are some different natures of smart crates discussed.
https://bugs.launchpad.net/mixxx/+bug/661460
What will you implement exactly.
What can the user finally do with it and what not.

Kind regards,

Daniel










Am 29.03.2017 um 20:40 schrieb Anast Gramm:
> Name: Grammenos Anastasis
> Nationality: Greece
> School: Aristotle University of Thessaloniki
> Department: Computer Science
> Link: [http://www.csd.auth.gr/en/]
> Semester: 8th
>
> 1 Intro
> ===
>
>   Hello, as you may know from my previous email in this list, I'd like
>   to participate at GsoC 2017. This is my final application.
>
>
> 2 Mixxx development
> ===
>
>   So far I managed to set a running developer environment for the
>   project using emacs, gdb dubugger and rtags. I have also downloaded
>   and set up eclipse and QtCreator in case I need them.
>
>   I am able to run tests, and currently working on a bug.
>   [https://bugs.launchpad.net/mixxx/+bug/1663444]
>
>   I'll issue a pull request when I have time, since now I am working
>   most of the day in a temp job. (It ends soon)
>
>
> 3 Goals
> ===
>
>   I'd like to improve mixxx's crate functionalities. For that I plan to
>   improve the database behind it to be able to support hierarchical
>   organisation and search filters. And also set the ground for future
>   expansion. I will also try to implement some kind of smartcrates e.g.
>   crate Oldies will have all songs released < 1980, and keep it synced
>   with the users library.
>
>
> 4 Timeline
> ==
>
> 4.1 May 4 - 30
> ~~
>
>   For the first period, I'll be actively working on bugs and reading the
>   code to get a broader understanding of the project's structure. I'll
>   probably ask questions, so please bear with me. I'll focus on the
>   database and the crate functionality for obvious reasons.
>
>
> 4.2 May 30 - June 30
> 
>
>   As a goal for the first evaluation, I want to have a working schema of
>   the database to support the aforementioned crate expansions, and
>   already start working on the hierarchy stuff.
>
>
> 4.3 June 30 - July 24
> ~
>
>   2 months in and the first nested crates will be available for testing
>   in my branch. Work on the search filters will be near the end, mainly
>   with UI stuff remaining. (like a new create search bar)
>
>
> 4.4 July 28 - August 21
> ~~~
>
>   Everything will be ready to get merged in MASTER, while smart crates
>   will be my main focus. If everything goes well, I'll be faster than
>   this plan and have more done by the end of the summer.
>
>
> 5 Outro
> ===
>
>   Feel free to ask me anything about anything, I usually am on IRC
>   (nick: gramanas) or via this mail. I hope we get to work together!
>
> --
>
> Grammenos Anastasis
>

--
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] test builds for PRs

[Daniel Schürmann]

Hi Baltazar,

that sounds great.
Thank you very much, for offering your time.

If you need help, just ask on this list.

Kind regards,

Daniel




2017-03-27 16:22 GMT+02:00 Baltazar Ortiz :

> I've been hoping to get into Mixxx development, and I remember noticing
> the lack of a developer guide when I sat down to try to figure things out
> once. My courseload this semester has turned out to be a bit heavier than
> anticipated, but no one else has had time put something together by the
> time I have time to try to learn the Mixxx source better (hopefully this
> summer?) I can attempt to write things up as I go through the code myself.
>
> I'd imagine anything I come up with would need some reviewing by more
> experienced developers in case I miss details, but I figured it might help
> save you all the more arduous part of the work.
>
> Baltazar
>
> > On Mar 27, 2017, at 01:39, Tuukka Pasanen 
> wrote:
> >
> > Hello,
> >
> > Yes piling of PR is problem and getting them through is sometimes little
> > bit slow. Should we have something like kernel-next which have things
> > that are not in master but coming to it and people can test it and
> > report bugs against it. It would not so conservative what gets in and if
> > something doesn't go forward it's just removed.
> >
> > Mixxx could really do tagging which some projects does. So PR's could be
> > tagged as nealy finnish and need for testers.
> >
> > Just few thoughs... but let's face this it's positive problem there is
> > more and more people interested in contributing to Mixxx.
> >
> > One this Mixxx should start using is: https://github.com/coala/coala (as
> > python is already needed for scons) to lint every language with same
> > interface so all stupid linting and code formatting issues could be
> > fixed before PR state.
> >
> >
> > 25.03.2017, 20:43, Be kirjoitti:
> >> We do need to define a release process, but I think there is a bigger
> >> issue here that contributes to disorganization around releases. I've
> >> been thinking that the biggest issue Mixxx faces is a shortage of labor.
> >> Testing and reviewing pull requests is a lot of work, hence why I
> >> started this thread to try to get more people involved in that.
> >>
> >> Right now we have a lot of responsibility falling on very few people, so
> >> if one or two of them have less time to work on Mixxx it holds up
> >> everything. This is not a good situation, and I think the only fair way
> >> out of it is to get more people involved. I think we should consider
> >> what we can do to attract and retain more developers for Mixxx.
> >> Obviously, making the software better is a good start. Hopefully the new
> >> features and polishing in 2.1 will bring in more interest. Evidently
> >> though, putting code out in the open is not enough. I think we should
> >> consider the obstacles to contributing and how we can reduce them.
> >>
> >> I think the biggest issue is the lack of developer documentation.
> >> Comments in source code are helpful, but we also should have high level
> >> overviews of how the different parts of Mixxx fit together. Mixxx has a
> >> lot of code. It's difficult to start working on it, even to fix a small
> >> bug, without a considerable investment of time to understand what
> >> different parts of the code are doing and why it is organized that way.
> >> Requiring all new contributors to struggle through this themselves is
> >> inefficient. This information should be written out and easily
> >> accessible. We have http://mixxx.org/wiki/doku.php/developer_guide but
> >> it only covers a little bit of the core infrastructure. I think it would
> >> be a worthwhile investment of time after the 2.1 release to work on the
> >> Developer Guide.
> > Developer guide would be marvelous but does someone have time to write
> > it? Or do we not to have time to write it?
> >> Having the project scattered across a different service and account
> >> system for each part of it is another annoying barrier. We have GitHub,
> >> Launchpad, our wiki, our forum, a Freenode IRC channel, and this
> >> SourceForge mailing list (which injects spam into every post...). That's
> >> a lot to sign up for and a lot to keep track of. I could understand how
> >> it would be bewildering for someone new to Mixxx to figure out where to
> >> go for information or how to contribute. However, I think this is a
> >> relatively minor issue though and the cost of switching services would
> >> be high.
> > Let's drop launchpad altogether or at least for bugs. Translate them to
> > Github.
> >>> On 03/25/2017 08:12 AM, Josep Maria Antolin wrote:
> >>> I haven't commented on this yet, although I am involved in it too, as I
> >>> have several PRs pending approval.
> >>>
> >>>
> >>> ​My PRs are:
> >>> #1195 Restructuring related to recording dialog settings and encoders
> >>> #1171 Three fixes related to waveform generation, splitted from the
> >>> 

[Mixxx-devel] Light-weight debug with symbols on windows

[Daniel Schürmann]

Hi

I have discovered a way to debug Mixxx using the installed mixxx.pdb 
file without the need to install Visual Studio.

x64dbg

The updated description is on the wiki 
http://www.mixxx.org/wiki/doku.php/creating_backtraces#windows

Please verify.
Thank you!

Kind regards,

Daniel


--
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 proposal review

[Daniel Schürmann]

Hi Nimit,

thank you for your first GSoC project draft.

The proposed effects seams to be a nice addition for Mixxx's radio use
case.

Do you or one of your friends have any experiences with broadcasting?

I am in doubt if we are able to understand and adopt the signal theory
implemented in the effects.
If we can just copy them, it might be doable.
Please find out, under which license this can work.

One important Effect for the DJ use-case is a auto de-ring EQ,
https://bugs.launchpad.net/mixxx/+bug/1427779
It the proposed AEC effect able to find and kill resonance frequencies?

The other issue, is that Mixxx is currently not well prepared to have Mic
effects.
One part of the project could be to make them first class.
What is missing?

Kind regards,

Daniel














2017-03-23 13:56 GMT+01:00 Tuukka Pasanen :

> Hello,
>
> First chill. Everyone here doesn't have infinite time to get on things
> like this.
>
> But about proposal I don't think you can do that much in one summer. Four
> effects ain't going to happen in three months. You should add at least one
> to make sure you understand Mixxx inner things forehand (Which is huge
> beast if you fix the bugs as you are going to do). Doing it's not the
> hardest part it's getting them in to git. Or you can choose which one (or
> two) you want to do and then you have better changes to get through and
> give little bit examples you really understand maths and things behind them.
>
> I don't mean to be rough and good luck.
>
> Sincerely,
>
> Tuukka
>
> 23.03.2017, 14:46, Nimit Bhardwaj kirjoitti:
>
> Please rate it, I want to  know did I make the proposal correct, as I
> first time write the proposal I don't know much if its write
>
> On Wed, Mar 22, 2017 at 11:07 PM, Nimit Bhardwaj 
> wrote:
>
>> Please rate my proposal for GSoC this year, I am going to code for the
>> microphone effects please see it and give me suggestions that things which
>> can i add or remove.
>>
>> I hope that this is good proposal, and mind my english im not expert of
>> english ;-)
>>
>
>
>
> --
> 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 Todayhttp://mixxx.org
>
>
> Mixxx-devel mailing 
> listMixxx-devel@lists.sourceforge.nethttps://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] test builds for PRs

[Daniel Schürmann]

Hi Markus,

I am also quite unhappy, that we missed a suitable release date as we 
have original planed "short after 2.0". Later in September, we had also 
a very stable alpha version that was suitable for merge.

Now we are in a middle of a giant feature creep, polishing skins and 
controller interface. It would feel bad to release Mixxx with this halve 
finished. The involved contributors are very productive and hard 
working, so I think we are ready for release soon.

My tasks are already done and pending as PR

Mandatory:
HiDPI Skin Scaling https://github.com/mixxxdj/mixxx/pull/1204
Hint rounding https://github.com/mixxxdj/mixxx/pull/1223

Optional:
LV2 support: https://github.com/mixxxdj/mixxx/tree/lv2_support2
Optional network clock reference https://github.com/mixxxdj/mixxx/pull/894
Auto dj crates improvements https://github.com/mixxxdj/mixxx/pull/1214
Show native separators in user visible strings (GUI) 
https://github.com/mixxxdj/mixxx/pull/1215

If I find time, I would also look at the DB rename detection.
I am afraid it is broken, because I have a lot of missing tracks in my 
library.

What else is mandatory for the release?


Kind regards,

Daniel










Maybe they can give an


Am 23.03.2017 um 21:34 schrieb Markus Klösges:
>> We have accumulated a rather large backlog of pull requests that are
> awaiting review and testing.
>
> IMHO it would also be nice to have some more info on release schedules
> or plans, what could be merged and what is laying around for next alpha.
> What to focus on, where help is wanted. Maybe GitHub tags could be used
> for marking 'please test', 'next alpha', ...? In combination with some
> more communication about planned releases, that could probably help
> focusing the work.
> What do you think?
>
> Am 23. März 2017 16:56:03 MEZ schrieb Be :
>
> We have accumulated a rather large backlog of pull requests that are
> awaiting review and testing. I wrote a new wiki page and put it on the
> front page of the wiki to help users get involved with testing:
> http://mixxx.org/wiki/doku.php/testing
>
> To get more testers, it would be helpful to make the builds Travis makes
> available for download. AppVeyor already does this and keeps the builds
> on the AppVeyor site. Could we host those on Travis or have the Travis
> VMs send the builds to our build server for hosting?
>
> 
>
> 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] Fwd: Trying to test Bug #1663444 (quantization missbehavior)

[Daniel Schürmann]

Hi Anast,

are you able to single step though the code using emancs?
Once you have a visual gdb debugger, you could probably identify why you
test is not failing.


I use Eclipse, we have some hints in our Wiki to make it work nice:
www.mixxx.org/wiki/doku.php/eclipse
There is also an emacs+ plugin for eclipse, which enables some emacs stuff.

Qt Creator or KDevelop seams also a reasonable choice.
http://www.mixxx.org/wiki/doku.php/developer_tools#using_ides

---

The Mixxx Engine is processed via a real time task, driven by the sound
card crystal.
It is processed in regular intervals, depending on the buffer size set in
the hardware preferences.

During the unittest, we have no real soundcard, so you need to call the
engine manually, to process
the changed control objects.


Kind regards,

Daniel






2017-03-23 12:26 GMT+01:00 Anast Gramm <anastasis.gra...@gmail.com>:

> On Thu, Mar 23, 2017 at 09:37:24AM +0100, Daniel Schürmann wrote:
> > Hi Anast,
> >
> > I am not sure, but probably you need an additional
> > ProcessBuffer();
> > after you set play.
>
> I'll try it when I get the chance. I still don't get what ProcessBuffer()
> actually does, even after reading the code! Something about a cycle of the
> engine
> as Be said of IRC
>
> > Are you able to debug though the Mixxx source?
> > Which IDE do you use on which OS?
>
> I have Arch Linux, and I am using emacs as an editor with packages
> to make up for the smart IDE behavior. Sadly I've not been able to
> configure
> autocomplete yet, because I have a problem with clang compilation (whose
> output
> is fed in rtags to generate the completion source)
>
> Besides those things I have read a bit of the engine code that is around
> the bug
> I am trying to fix, and although I don't have a solid understanding of how
> things work, I have a general idea.
>
> > By the way: If you like to discuss source code, it is straight forward to
> > issue a GitHub pull request.
> > You can just write into the description that this is experimental.
> > GitHub has some nice facilities to discuss code.
>
> Ok, I'll do that! I thought that was the mailing list's purpose.
>
> ---
>
> Grammenos Anastasis
>
--
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] Fwd: Trying to test Bug #1663444 (quantization missbehavior)

[Daniel Schürmann]

Hi Anast,

I am not sure, but probably you need an additional
ProcessBuffer();
after you set play.

Are you able to debug though the Mixxx source?
Which IDE do you use on which OS?

By the way: If you like to discuss source code, it is straight forward to
issue a GitHub pull request.
You can just write into the description that this is experimental.
GitHub has some nice facilities to discuss code.


Kind regards,

Daniel



2017-03-21 22:08 GMT+01:00 Anast Gramm :

> Hello,
>
> The bug [1].
>
> Quantization should align the song that has it,
> with the other deck. This should happen only if the other deck
> is playing something. In case the other deck doesn't play
> you dont want to quantize because tracks skips when being unpaused.
>
> The bug is pretty eazy to reproduce in Mixxx, as it says in the bug report.
>
> I want to write a test case to demostrate the problem so I can later
> work on fixing it. Here is the code I got so far:
>
> TEST_F(EngineSyncTest, MyTestQuantize) {
>
>   // DECK 1:
>   auto pFileBpm1 = std::make_unique(m_sGroup1, "file_bpm");
>   // set position to .2
>   ControlObject::getControl(ConfigKey(m_sGroup1,
> "playposition"))->set(0.2);
>   pFileBpm1->set(100.0);
>   BeatsPointer pBeats1 = BeatFactory::makeBeatGrid(*m_pTrack1, 100, 0.0);
>   m_pTrack1->setBeats(pBeats1);
>
>   // DECK 2:
>   auto pFileBpm2 = std::make_unique(m_sGroup2, "file_bpm");
>   // set position to .3
>   ControlObject::getControl(ConfigKey(m_sGroup2,
> "playposition"))->set(0.3);
>   pFileBpm2->set(100.0);
>   BeatsPointer pBeats2 = BeatFactory::makeBeatGrid(*m_pTrack2, 100, 0.0);
>   m_pTrack2->setBeats(pBeats2);
>
>   // turn quantize off for Deck 1
>   ControlObject::getControl(ConfigKey(m_sGroup1, "quantize"))->set(0.0);
>
>   // Press play on Deck 1
>   ControlObject::getControl(ConfigKey(m_sGroup1, "play"))->set(1.0);
>
>   // The playposition should be 0.2
>   EXPECT_FLOAT_EQ(0.2, ControlObject::getControl(ConfigKey(m_sGroup1,
> "playposition"))->get());
>
>   // Stop playback on Deck 1
>   ControlObject::getControl(ConfigKey(m_sGroup1, "play"))->set(0.0);
>   // Turn quantize on
>   ControlObject::getControl(ConfigKey(m_sGroup1, "quantize"))->set(1.0);
>
>   ProcessBuffer();
>
>   // Start playback on Deck 1
>   ControlObject::getControl(ConfigKey(m_sGroup1, "play"))->set(1.0);
>   // The playposition should still be 0.2
>   EXPECT_FLOAT_EQ(0.2, ControlObject::getControl(ConfigKey(m_sGroup1,
> "playposition"))->get());
> }
>
> When I run it, it passes.. It shouldn't.
> I tired a few changes here and there but I am kinda stuck now.
>
> I am not sure I am using the right COs tho...
>
> --
> [1]: https://bugs.launchpad.net/mixxx/+bug/1663444?comments=all
> ---
>
> Grammenos Anastasis
>
> 
> --
> 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] registering MIDI input callbacks from JavaScript

[Daniel Schürmann]

Hi Be,

Thank you for the design draft.
It looks very solid and should be already very useful.

I am just wondering how this interacts with the mapping GUI.
Use case: A non programing experienced user wants to reassign the deck gain
knob to the aux volume.
He can probably do it easy in one direction. JS -> XML how can he revert
it, or swap two JS mapped functions?
A solution my also include "learning jog wheels".


An other issue is that we final loose the single point of entry for
tracking the mappings.
Today a user can lookup the xml file to track the midi signals. It does not
require a physical controller nor
a running Mixxx only GitHub access.
Maybe we can add an auto generated xml file or other self-documentation to
issue this uses case.

Kind regards,

Daniel









2017-03-16 8:18 GMT+01:00 Be :

> Hi,
> I have started planning how to implement a way to register MIDI input
> callbacks from JavaScript so we can write mappings entirely in
> JavaScript without the hassles of the XML format. I'm not sure when I'll
> get around to implementing this, but it won't be in 2.1.
>
> http://mixxx.org/wiki/doku.php/registering_midi_input_
> handlers_from_javascript
>
> Please reply with your thoughts and questions.
>
> 
> --
> 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] Fixing quantize bug

[Daniel Schürmann]

Hi Anast,

The "quantize" control is evaluated here when play is executed:
https://github.com/mixxxdj/mixxx/blob/10cff8cd651627244fd1a2dc9777615cea0370fa/src/engine/enginebuffer.cpp#L655

It could also be interesting why out tests did not catch the issue:
https://github.com/mixxxdj/mixxx/blob/3bb3d6da933643f28796768227e4214d2bb869d3/src/test/enginesynctest.cpp
Maybe you are able to write a test to verify the bug.

If you need more info, just ask.

Kind regards,

Daniel



2017-03-20 13:01 GMT+01:00 Anast Gramm :

> Hello, I want to fix this bug [1].
>
> I tested it and i believe it's a bug with quantize as mentioned in
> comments.
>
> I think there needs to be a check that if the other track is playing, and
> only then, it should trigger the quantize uppon pressing play.
>
> If I have 2 tracks loaded but both are paused, there is no need for
> quantizing
> when I press play, and it only causes this sound glitch.
>
> Could you provide some help to get me started?
>
> [1]: https://bugs.launchpad.net/mixxx/+bug/1663444?comments=all
>
> 
> --
> 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] GsoC application - Grammenos Anastasis

[Daniel Schürmann]

Hi Anast,

thank you for introducing yourself.

Your project ideas really sounds quite challenging.
What will work, is to prepare parts the back-end for this as part of the
cue point project.

We have a pending pull request for introducing LV2 effects to Mixxx.
This suffers the issue that we cannot show the GUI of the LV2 effects if
there is one.
Maybe an alternative could be to extend the LV2 solution in a way that it
allows to interface third party sequence
that have a LV2 interface. I have no clue if this can work, but it is worth
to investigate.

For your final application, you need a detailed description of your project
along with a time table and goals for the evaluations.

You should also prove to have a working Mixxx development environment by
fixing an easy bug form Launchpad or something else.

If you have questions, just ask on this list or at the related bug reports.

Kind regards,

Daniel









2017-03-18 17:02 GMT+01:00 Anast Gramm :

> A pdf is attached with the following if you don't like ascii!
>
> 1 GsoC application for Mixxx
> 
>
>   Hello, my name is Anastasis Grammenos. I am a 22 years old student at
>   [Csd AuTh], in my 3d year. (Actually is the 4th year but due to
>   personal reasons I was not enrolled in classes for 8 months, so I
>   missed 2 semesters).
>
>   I grew up and live in Thessaloniki/Greece.
>
>
> [Csd AuTh] http://www.csd.auth.gr/en/
>
> 1.1 Musical background
> ~~
>
>   I play the guitar and I know my way around a piano. Also in the past 2
>   years I've been jamming with electronic music and I am really into
>   analog gear. As far as DJing goes, I don't really know how to do it,
>   since usually when I pick the music it sets people off! But I still
>   like doing in for my self from time to time.
>
>
> 1.2 Programming background
> ~~
>
>   I've done work in C, C++, python and a bit of Java (although I hate
>   it), mainly for school projects and my own satisfaction. I really like
>   the "low level" approach C/C++ offers and I think it's a great
>   language to base a project on.
>
>   I know my way around a database, since I work in a photography shop,
>   where we have one made by a coworker and from time to time we need to
>   run strange queries and fix some mistakes other users might do.
>   Currently we are working on a replacement of the old DB with a new one
>   with PostgreSQL, witch is way more advanced that the one we have right
>   now.
>
>   I am a full time Arch Linux user in both my laptop and desktop, with
>   the exception of photoshop and other adobe programs I use for
>   photography reasons.
>
>   That said I do not consider my self a linux power user, I just try to
>   become one. (there are still a lot of manpages to read)
>
>   I have moderate experience with git, but since I never used it in a
>   big project I don't know all the rebase stuff, reverting changes etc.
>
>
> 1.3 Mixxx specific requirements
> ~~~
>
> 1.3.1 Scons
> ---
>
>   I downloaded scons, and i've been playing with it, building my old C
>   code. Since it's basically a python script, I don't think it will be
>   hard to get to know it.
>
>   Also I looked at your SConstruct. WOW, that's cool!!! I didn't even
>   think there was such an amazing tool a week ago.
>
>
> 1.3.2 Git
> -
>
>   As mentioned above I have knowledge of git but only the basic stuff.
>   Sadly I deleted some old repos with C and C++ but here is my github if
>   you'd like to have a look at it. (I use it mainly to keep track of my
>   config files) [https://github.com/gramanas]
>
>
> 1.3.3 Qt
> 
>
>   I've seen some tutorials about it, but I can't say I know it. I am of
>   course willing to learn everything since I believe it's a great tool
>   to have in my toolbox. Since it's based on C++ I don't think it will
>   take a lot of time to get acquainted with it.
>
>
> 1.3.4 Portaudio
> ---
>
>   Well, I know nothing about it! It has something to do with audio i
>   think :) I will look at it tho in the coming weeks.
>
>
> 1.4 My ideas about Mixxx
> 
>
>   The following are things I am interested to tackle for the summer
>
>
> 1.4.1 Link controls
> ---
>
>   Basically this feature request: [link controls (control two knobs with
>   one mouse)]
>
>
> [link controls (control two knobs with one mouse)]
> https://bugs.launchpad.net/mixxx/+bug/329776
>
>
> 1.4.2 Crates
> 
>
>   This is the feature you proposed on the wiki. I love the idea of
>   tagging stuff, and I believe crates can make mixxx stand out if
>   implemented correctly.
>
>   As I see it, there needs to be a database of user defined tags =
>   crates. This part already exists.
>
>   What *NEEDS* to happen is smart crates: automatically add music
>   depending on user defined stuff in a selected crate when scanning the
>   library 

Re: [Mixxx-devel] Help needed for the effects and GSoC

[Daniel Schürmann]

Hi NImit,

Mixxx currently already has a break (spin up/down) effect accessible 
form controller mappings. It would be nice, if we allow this to be used 
from GUI only setups as well.

New effects are always welcome.

Mixxx allows already to make use of the beat timing. It would be nice to 
enable this for some effects in away the user can easily control it.

Unfortunately all the proposed effect topics are IMHO hard to turn into
a good GSoC project.

It would be better to propose a project derived form one of our proposed 
projects.

Did you already find this page: 
http://www.mixxx.org/wiki/doku.php/gsocadvice
This should be a good start to read.
For further questions please ask.

Kind regards,

Daniel







Am 10.03.2017 um 05:26 schrieb NImit Bhardwaj:
> Hello all, I want to participate in GSoC this year and I want to add the
> some Beat Synchronized effects, I was interested in the adding effects
> as it feels me awesome and moreover it requires some knowledge of math,
> physics and algorithms which I like most and I read about the Brake
> effect in the https://bugs.launchpad.net/mixxx/+bug/692928 and I am
> thinking of it now, I also read the
> https://www.mixxx.org/wiki/doku.php/effects_framework where I came to
> know how to play with the code of the effects and in my humble opinion I
> want the mentors to add some tutorial for adding an effect like say
> already added effect which is easy to understand like was given in the
> skin development guide, for GSoC I want to ask what can I give my ideas
> for the different Beat Sync effects I got by researching on internet,
> and I hope that I would be useful for the organization. And one more
> thing I want to know, how do I write the proposal, means what things I
> include.
>
>
> Thank you So much and waiting for the replies.
>
>
> --
> Announcing the Oxford Dictionaries API! The API offers world-renowned
> dictionary content that is easy and intuitive to access. Sign up for an
> account today to start using our lexical data to power your apps and
> projects. Get started today and enter our developer competition.
> http://sdm.link/oxford
> ___
> 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
>

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
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] For GSoC2017

[Daniel Schürmann]

Hi Nimit,

we have not yet proposals for this years GSoC project.

But if we get accepted, it we will most likely pick broadcasting related 
projects. Any project ideas are welcome.

The best you can do for now is to become an active contributor and help 
to finish our 2.1 release. There is also some work left at your pending 
pull request.

Kind regards,

Daniel



Am 14.02.2017 um 18:18 schrieb NImit Bhardwaj:
> I have a query about the GSoC2017 and I want to introduce first, I am
> Nimit Bhardwaj, and I want to apply for the GSoC2017 this year to Mixxx,
> I want to get some tips so that I could be selected in GSoC this year, I
> read about the guidelines, in the GSoC section of the developer site and
> I also made some of 4-5 contributions by fixing the bugs, I want to know
> can I be selected in GSoC and which project should I work on.
>
> I would be thankful for this
>
> Yours truly
> Nimit Bhardwaj
>
> --
> 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] Jenkins builds have returned

[Daniel Schürmann]

The Shade Logo is there, an Mixxx behaves normally.

I have just tested again and there is actually no Logo with Deere and
LatNight.
Loading the Deere skins takes ages ~35s. Loading Shade takes ~11s and
LateNight ~18s


2017-01-20 9:09 GMT+01:00 Sébastien Blaisot <mi...@blaisot.org>:

>
> Do you see the Mixxx logo on the splash screen ?
>
>
> sb
>
> Le 20/01/2017 à 08:30, Daniel Schürmann a écrit :
>
> Great News, Thank you.
>
> I can confirm that Mixxx still runs on my WinXP Virtual Box.
> Anything special I should test?
>
>
> 2017-01-20 5:55 GMT+01:00 Be <b...@gmx.com>:
>
>> \o/
>> Thanks to all who contributed!
>>
>> Should this be announced on the forum or should we wait for a bit more
>> testing to work out the most obvious issues?
>>
>> On 01/19/2017 09:53 PM, RJ Ryan wrote:
>> > Behold, the first green build in forever:
>> > https://builds.renegadetech.mixxx.org/job/master-release/
>> >
>> > Please try out the Windows packages for git6123:
>> > http://downloads.mixxx.org/builds/master/release/
>> > this new build configuration will be what we're going to release 2.1
>> > from so let's iron out all the kinks.
>> >
>> > Could somebody verify whether it is affected by the
>> > metadata-not-sending-with-Shoutcast-servers bug? If so, we need to
>> patch
>> > it in the same way we did the macos build.
>> >
>> > Windows XP and Vista should be supported, so please test it if you still
>> > have a VM or old computer sitting around (M4A is only supported in Vista
>> > SP3 (?) onwards).
>> >
>> >
>> > 
>> --
>> > 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 Todayhttp://mixxx.org
>
>
> Mixxx-devel mailing 
> listMixxx-devel@lists.sourceforge.nethttps://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] Jenkins builds have returned

[Daniel Schürmann]

Great News, Thank you.

I can confirm that Mixxx still runs on my WinXP Virtual Box.
Anything special I should test?


2017-01-20 5:55 GMT+01:00 Be :

> \o/
> Thanks to all who contributed!
>
> Should this be announced on the forum or should we wait for a bit more
> testing to work out the most obvious issues?
>
> On 01/19/2017 09:53 PM, RJ Ryan wrote:
> > Behold, the first green build in forever:
> > https://builds.renegadetech.mixxx.org/job/master-release/
> >
> > Please try out the Windows packages for git6123:
> > http://downloads.mixxx.org/builds/master/release/
> > this new build configuration will be what we're going to release 2.1
> > from so let's iron out all the kinks.
> >
> > Could somebody verify whether it is affected by the
> > metadata-not-sending-with-Shoutcast-servers bug? If so, we need to patch
> > it in the same way we did the macos build.
> >
> > Windows XP and Vista should be supported, so please test it if you still
> > have a VM or old computer sitting around (M4A is only supported in Vista
> > SP3 (?) onwards).
> >
> >
> > 
> --
> > 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

[Daniel Schürmann]

One important use case for me, which is not covered is a "Loudness" EQ, the
thing, found on most living room amplifiers.  This is very useful if you
play silent music at dinner time.


For me a perfect EQ would be a steep two band ISO for Mixing + a Loudness
effect on the Mid knob.

2017-01-18 13:51 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org>:

> Yes, we should not follow Traktor to model N Type of hardware mixers. We
> may let us inspire from the solutions out there and build a well suited set
> of Mixxx EQs, that covers the most important use cases for Mixxx.
>
> Providing a generic EQ builder sounds cool but it is ambiguous, since we
> are facing a lot of degrees of freedom.  In case of Biquad EQ types, such a
> generic EQ will always be a chain of Filters. So your request is basically
> the same what Be has suggested with chaining other effects.
>
> We could add a n-Pole parameter to our isolator EQs, but I am In doubt if
> we actually need to be that flexible. It will finally increase the number
> of possible EQs even more.
>
> From my experiences from my past work on the current solution, most users
> just do not care about the EQ details. It is also interesting, that we had
> not a single complain about a missing conventional EQ option even though it
> is the most common one on Hardware. It seams that most users are pretty
> happy with an isolator type. This matches also what I can read in forums
> discussing EQs.
>
> However, I still think we have some gaps in our EQ Zoo:
> * A XONE:92 like EQ
> * A conventional Biquad EQ  (PR is pending)
> * A 12 dB/Oct isolator ??
>
> Where the IMHO the XONE:92 is not famous because its 4 Band. It is famous,
> because it combines an 2 Band ISO with a 2 Band EQ, the best of two worlds.
> Interestingly this device is an icon, because the successors with 4-Bands
> do not offer full kill. Maybe the required hardware circuit was just too
> expensive or complicated.
>
> A sweeping Bell EQ like the play differently could be also fun. An other
> use case for  sweeping EQs is to ring out Microphones.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 2017-01-18 9:32 GMT+01:00 Ferran Pujol Camins <ferranpujolcam...@gmail.com
> >:
>
>> 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" <b...@gmx.com> 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 

Re: [Mixxx-devel] n-band EQ

[Daniel Schürmann]

Yes, we should not follow Traktor to model N Type of hardware mixers. We
may let us inspire from the solutions out there and build a well suited set
of Mixxx EQs, that covers the most important use cases for Mixxx.

Providing a generic EQ builder sounds cool but it is ambiguous, since we
are facing a lot of degrees of freedom.  In case of Biquad EQ types, such a
generic EQ will always be a chain of Filters. So your request is basically
the same what Be has suggested with chaining other effects.

We could add a n-Pole parameter to our isolator EQs, but I am In doubt if
we actually need to be that flexible. It will finally increase the number
of possible EQs even more.

>From my experiences from my past work on the current solution, most users
just do not care about the EQ details. It is also interesting, that we had
not a single complain about a missing conventional EQ option even though it
is the most common one on Hardware. It seams that most users are pretty
happy with an isolator type. This matches also what I can read in forums
discussing EQs.

However, I still think we have some gaps in our EQ Zoo:
* A XONE:92 like EQ
* A conventional Biquad EQ  (PR is pending)
* A 12 dB/Oct isolator ??

Where the IMHO the XONE:92 is not famous because its 4 Band. It is famous,
because it combines an 2 Band ISO with a 2 Band EQ, the best of two worlds.
Interestingly this device is an icon, because the successors with 4-Bands
do not offer full kill. Maybe the required hardware circuit was just too
expensive or complicated.

A sweeping Bell EQ like the play differently could be also fun. An other
use case for  sweeping EQs is to ring out Microphones.


























2017-01-18 9:32 GMT+01:00 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

Re: [Mixxx-devel] making GSoC better for Mixxx

[Daniel Schürmann]

Produce small merge-able, steps was one of our major goal for the time-line
the students have to setup for the their project.  Unfortunately there
wasn't not many early merges in the last season, because this somehow
conflicts with the desired code quality and the rule not to merge
unfinished PRs or things that introduce a architecture changes of an
experimental nature.

However, I am pretty satisfied with the outcome of last year, we have the
new library layout on the way to master and we have a new keyboard mapping
with a solid design, that is waiting for the last polish.
The same is true for the LV2 branch from an earlier year

GSoC allows us to start big changes, that are not doable (or not done) in
small PRs. For example the library layout was a pending project since 2012
and the pile of work was so high and probably to fuzzy that no one was
willing to spend his spare time on it. Similar is true for the keyboard
mapping branch or the LV2 branch.

The problem of relying on more community feedback, is that it is very slow.
It does not match with the 40 h working week of the student, who does not
want just wait. I have softened encouraged the student to ask for opinions
on mixxx-devel, sometimes it works well, sometimes not.

What can we improve?

We should once more look closely to the student steps and make them
actually merge-able.
We may encourage the students to interact even more with the community.
We should try to decouple each steps that the community has time to review
the changes without blocking the students progress.

I do not think we should artificially reduce the GSoC slots, if we have N
excelent projects and a N mentors with time and fun, we should apply for N
slots. This gives the best chance to gain a long term contributor which is
IMHO the major benefit of GSoC.



2017-01-16 22:06 GMT+01:00 RJ Ryan :

>
>
> On Mon, Jan 16, 2017 at 12:45 PM Thorsten Munsch <
> thorsten.mun...@synthor.de> wrote:
>
>> Do I understand it right? The students are behind the money they may get
>> from Google and not after the knowledge they gain solving a specific
>> project?
>>
>>
> The summer stipend of $4500 is a pittance for someone living in an urban
> part of the US or EU, but something like an average year's-salary in other
> countries. Given the economics, it's not surprising there is far more
> interest in GSoC from countries where the stipend is more valuable.
>
>
>
>> I never studied, but always wanted to. Meanwhile I am in a good position
>> w/o an exam and having not enough time/mood to contribute.
>>
>> Really sad to read that.
>>
>>
>> Cheers
>> Thorsten
>>
>> Am 16.01.2017 um 21:17 schrieb 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
>> >
>>
>> 
>> --
>> 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! 

Re: [Mixxx-devel] n-band EQ

[Daniel Schürmann]

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

Re: [Mixxx-devel] n-band EQ

[Daniel Schürmann]

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 
:

> 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
>
--
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] Need help for src/waveform/renders/waveformmark.h

[Daniel Schürmann]

The WaveformMarks are set from the Skin like that:
https://github.com/mixxxdj/mixxx/blob/8d191bf7ce2d62d24c6e0ffac4b2afd7359afa8a/res/skins/LateNight/waveform.xml#L40

The usage is explained here:
http://www.mixxx.org/wiki/doku.php/creating_skins?s[]=markrange#sectionvisual

you can start mixxx with
mixxx --developer to have a developer meu with a reload skin feature.

So you may want to play with it.

for debugging you can use qDebug() statements or gdb.
Are you able to single step though the code?



Am 17.12.2016 um 16:53 schrieb NImit Bhardwaj:
> I need help, as in I am not able to get the meaning of the class
> WaveformMark, in the src/waveform/renders/waveformmark.h, i got that it
> has something to do with the marker of the waveforms in the Mixxx, but
> moreover, I want to know that in the setup function of the class, why is
> that the item, is compared if its empty or not, i checked that it is
> converting the QDomNode object and the "Control" string to the string,
> then how it can be null, it can be possible if in the function of
> SkinContext::nodeToString in the file src/skin/skincontext.cpp, the
> child is initially Null, so a null tree was formed, which i think is the
> case with the code, as in setup function, context object calls
> selectString and selectString calls nodeToString, so i need clearity here.
>
> --
> 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] Devel and live play on master

[Daniel Schürmann]

It sound like you have merged you feature branch into your private master
branch.

Is the new master working now including your "id3ratings_to_stars
<https://github.com/WaylonR/mixxx/tree/id3ratings_to_stars>" changes?

If yes, you can correct your repository like this:

# comit your merge
git commit -a
#checkout your original id3ratings_to _stars brach
git checkout  id3ratings_to _stars
# create a backup branch of your work (just in case)
git checkout -b id3ratings_to _stars_backup
# switch back to the github pull request tracked branch
git checkout  id3ratings_to _stars
# drop the current state and replace it with you merge results from your
private master
git rest master --hard
# publish your changes in the PR
git push
# switch to your private master
git checkout master
# fetch all upstream changes
git fetch upstream
# if this fails because "upstream" is unknown add it
git remote add upstream https://github.com/mixxxdj/mixxx.git
git fetch upstream
# replace you local master by the upstream branch
git reset upstream/master --hard
# publish your master at github
git push

you should watch every step using "gitk"




2016-12-09 0:14 GMT+01:00 Waylon Robertson <wrobertson1...@gmail.com>:

> hmm.. thought it was git add remote, git pull my remote branch, think
> it ended up in master, fix conflicts, then recompile.
> at least, thats what i just did.
>
> What did i just do?
>
>
> On Fri, Dec 9, 2016 at 12:07 PM, Daniel Schürmann <dasch...@mixxx.org>
> wrote:
> > Rebasing will work like this:
> >
> > git fetch upstream
> > git checkout id3ratings_to_stars
> > git rebase upstream/master
> >
> > resolve conflict if any
> >
> >
> >
> > Am 08.12.2016 um 23:43 schrieb Waylon Robertson:
> >> its been ages since i've done any work on mixxx, i am recompiling, I
> >> am considering just making a new branch off my new master here, and
> >> redoing the code from scratch, since it has been so long... someone
> >> said that i should rebase, though.
> >>
> >> comments? and how do i get and rebase my branch, after git cloning the
> >> mixxx.git?
> >>
> >> On Fri, Dec 9, 2016 at 11:14 AM, Be <b...@gmx.com> wrote:
> >>> AFAIK no. There is a show stopper with some FLAC files in 2.0 though,
> so
> >>> I've been using master.
> >>>
> >>> On 12/08/2016 04:11 PM, Waylon Robertson wrote:
> >>>> Any gotchas/showstoppers currently existing on the bleeding edge?
> >>>>
> >>>> 
> --
> >>>> 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
> >>>>
> >>>
> >>> 
> --
> >>> 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
> >>
> >> 
> --
> >> 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 Mixi

Re: [Mixxx-devel] Devel and live play on master

[Daniel Schürmann]

Rebasing will work like this:

git fetch upstream
git checkout id3ratings_to_stars
git rebase upstream/master

resolve conflict if any



Am 08.12.2016 um 23:43 schrieb Waylon Robertson:
> its been ages since i've done any work on mixxx, i am recompiling, I
> am considering just making a new branch off my new master here, and
> redoing the code from scratch, since it has been so long... someone
> said that i should rebase, though.
>
> comments? and how do i get and rebase my branch, after git cloning the
> mixxx.git?
>
> On Fri, Dec 9, 2016 at 11:14 AM, Be  wrote:
>> AFAIK no. There is a show stopper with some FLAC files in 2.0 though, so
>> I've been using master.
>>
>> On 12/08/2016 04:11 PM, Waylon Robertson wrote:
>>> Any gotchas/showstoppers currently existing on the bleeding edge?
>>>
>>> --
>>> 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
>>>
>>
>> --
>> 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
>
> --
> 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
>

--
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] Devel and live play on master

[Daniel Schürmann]

Hi

I have used it last weekend with no issues but than means nothing. You 
should take some time to verify this for your use case at home.

Kind regards,

Daniel


Am 08.12.2016 um 23:11 schrieb Waylon Robertson:
> Any gotchas/showstoppers currently existing on the bleeding edge?
>
> --
> 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
>

--
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] wiki down

[Daniel Schürmann]

I get this error:

General Error
SQL ERROR [ mysqli ]

Access denied for user 'phpbb'@'localhost' [1698]

An sql error occurred while fetching this page. Please contact an
administrator if this problem persists.
--
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] Hey Man mixx Quetion

[Daniel Schürmann]

Hi Tuukka,

here some unsorted thoughts:

Even if Tomahawk would have a GPL 2 license, we will have the problem 
that it would be not compatible with Mixxx's licence extension for the 
Apple Mac store.

The best way to fix it would be to ask the original authors of the 
wanted source code for the permission to re-license it under the Mixxx 
license, and the terms of the Mixxx Contributor Agreement:

https://docs.google.com/forms/d/e/1FAIpQLScC9QG327sjLL0eWftmfGUasxFFLxg6LCXJ2xHDYRzFIRqyiw/viewform?formkey=dEpYN2NkVEFnWWQzbkFfM0ZYYUZ5X2c6MQ

If this is not possible we may ask for using it under the LGPL or any 
other compatible license.

If this is also not possible we may consider to distribute Mixxx 
including the Tomahawk code under the GPL 3

Apart from the license issue, a close look to the Tomahawk code is a 
very good idea. Maybe it is necessary to reimplement it for Mixxx 
anyway. Maybe we can also find out by testing or contacting the 
developers, what works good and bad in it.

If it is required to put the streaming code into a quarantine process, 
this can be put under the GPL 3.0.
In in order to play a track forward and backward, this process can write 
a temp file or something, which is than played by Mixxx under the 
original licence.

Kind regards,

Daniel








Am 04.12.2016 um 12:28 schrieb Tuukka Pasanen:
> Hello,
>
> I've been toying around idea using Tomahawk Player inputs for dealing
> with cloud and streaming solutions in Mixxx. Biggest problem they are
> GPL 3 and above licensed which can be show stopper because as I have
> understand aren't compatible with GPL v2 which is used in Mixxx. What do
> you think should this investigate further or not?
>
> Tuukka
>
>
> 25.11.2016, 17:39, RJ Ryan kirjoitti:
>> +mixxx-devel
>>
>> Hi Andrew,
>>
>> Sorry, but we don't support Spotify yet. It's on our desired feature list:
>> https://bugs.launchpad.net/mixxx/+bug/938180
>>
>> best,
>> RJ
>>
>> On Fri, Nov 25, 2016 at 2:46 AM A Moorms > > wrote:
>>
>> So I just downloaded Mixxx, I want to start making my own remixes
>> for my teams pregame and then for parties. Right now I just use
>> Spotify but I was wondering if there was a way I could take songs
>> from Spotify to this to use.
>> thank you,
>> Andrew
>>
>>
>>
>> --
>>
>>
>> ___
>> 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] Just a "bug report"

[Daniel Schürmann]

Hi Steve,

Thank you for your report.

Unfortunately it is somehow to fuzzy to reproduce and fix it.

We have known issues that the GUI is friezed during mass library actions 
(Ctrl-A). If this is not your issue, please file a Launchpad bug report 
for each of your finding, including a receipt to reproduce it. Hopefully 
we can fix it soon.

Thank you

Daniel



Am 03.12.2016 um 18:07 schrieb RJ Ryan:
> (looping in the whole team)
> Thanks Steven,
>
> For future reference, you can file bugs at
> http://bugs.launchpad.net/mixxx
>
> On Sat, Dec 3, 2016 at 12:03 AM Steve and Silvia
> > wrote:
>
> Hello,
>
> I just recently started using Mixxx 2.0 for a personal use on my Ubuntu
> and Ubuntu Studio installations.
>
> It looks great.  I imagine that the fact that it is a 2.0, there are
> things that will be worked on, but I notice that when I do certain
> things, the software freezes up.  The song continues to play, but the
> graphics stick and I am no longer able to access any function except the
> "X" to close the window.
>
> I do have an issue with the way to look for other songs than the ones I
> already have.  Could you work on the seek function for songs?  I also
> have connected removable usb keys, but they haven't been seen by
> Mixxx 2.0.
>
> Aside from that, it is one professional looking piece of DJ program.
> Thank you
>
> Steven Burwood
>
>
>
> --
> 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] Travis CI False Positives Mac Builds

[Daniel Schürmann]

Hi RJ,

 > I think we could shorten that to 1 second and still get the desired 
effect. WDYT?

IMHO the 30 s 1kHzR440HzLReference_32i96kStereo file is not used during 
automatic tests.

It would be no issue for me if we skip most tests during the Mac build, 
since most of them are target independent an already tested during the 
Linux build.





Am 15.11.2016 um 20:58 schrieb RJ Ryan:
> Oh, apparently going over 4MB gets you killed. I'll turn off verbose
> compilation.
>
> On Tue, Nov 15, 2016 at 11:54 AM RJ Ryan <rr...@mixxx.org
> <mailto:rr...@mixxx.org>> wrote:
>
> Hm, I got something slightly different on that commit.
> https://api.travis-ci.org/jobs/176113186/log.txt?deansi=true
>
> "The log length has exceeded the limit of 4 MB (this usually means
> that the test suite is raising the same exception over and over).
> The job has been terminated"
>
> I can't tell if this is still a timeout -- IIRC it says so
> explicitly if you timed out.
> One odd thing I can see, SoundSourceProxyTest.seekForward is parsing
> cover-test.aiff dozens of times. Locally, this test takes 2 seconds.
>
> On Tue, Nov 15, 2016 at 9:18 AM RJ Ryan <rr...@mixxx.org
> <mailto:rr...@mixxx.org>> wrote:
>
> I just tried this to try and speed up builds:
> 
> https://github.com/mixxxdj/mixxx/commit/9b16d3bfe1684b0407c777ce60898cad2f510bf0
>
> Our tests also take a long time to run. Some of the longest
> running tests are those that decode that 30 second long sine
> wave file. Unless we're trying to probe for memory safety issues
> (e.g. as we were in the AnalyzerQueue at one point), I think we
> could shorten that to 1 second and still get the desired effect.
> WDYT?
>
> On Thu, Sep 15, 2016 at 12:35 AM Daniel Schürmann
> <dasch...@mixxx.org <mailto:dasch...@mixxx.org>> wrote:
>
> Hi,
>
> we get lately a lot of false positives building Mixxx on Mac
> via Travis:
> https://travis-ci.org/mixxxdj/mixxx/builds/160026424
>
> This is because Travis has a 45 min time out.
>
> Can one of the Mac contributors have a look at it?
> What is the easiest way to reduce the build time?
>
> Thank you,
>
> Daniel
> 
> --
> ___
> 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] http://www.mixxx.org/forums/ down

[Daniel Schürmann]

Thank you Garth, It works again!

2016-11-09 16:20 GMT+01:00 Garth Dahlstrom <ga...@mixxx.org>:

> Should be okay now, give it a shot and let me know if there's trouble.
>
> On Wed, Nov 9, 2016 at 10:13 AM, Garth Dahlstrom <ga...@mixxx.org> wrote:
>
>> I'll fix it, give me 10 min
>>
>> On Nov 9, 2016 10:01 AM, "Be" <b...@gmx.com> wrote:
>>
>> There was an error on the wiki indicating low disk space before that.
>>
>> On 11/09/2016 08:36 AM, Daniel Schürmann wrote:
>> > Hi,
>> >
>> > who is able to take a look?
>> >
>> > Thank you!
>> >
>> >
>> >
>> >   General Error
>> >
>> > SQL ERROR [ mysqli ]
>> >
>> > Can't connect to local MySQL server through socket
>> > '/var/run/mysqld/mysqld.sock' (2) [2002]
>> >
>> > An sql error occurred while fetching this page. Please contact an
>> > administrator if this problem persists.
>> >
>> >
>> > 
>> --
>> > 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
>> >
>>
>> 
>> --
>> 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
>>
>>
>>
>
> 
> --
> 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
>
--
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] http://www.mixxx.org/forums/ down

[Daniel Schürmann]

 Hi,

who is able to take a look?

Thank you!

General Error
SQL ERROR [ mysqli ]

Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2) [2002]

An sql error occurred while fetching this page. Please contact an
administrator if this problem persists.
--
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] RIAA equalization, timecode, and preamps

[Daniel Schürmann]

Hi Mark,

Interesting! Thank you for the update!

Some time ago I have prepared a branch that emulates the gain change 
during vinyl scratching:

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

I have used a frequency independent gain-by-speed curve picked from a 
Serato vinyl.
https://bugs.launchpad.net/mixxx/+bug/1450665/+attachment/4388671/+files/speed-gain.ods

Thinking about this again, I wonder if this does already include the 
RIAA curve.

A double speed for a 1 kHz signal means approx. -2.5 dB in the RIAA 
curve (ratio 0.75)
Actually the measured ratio is approx 1.4 which includes the RIAA 
negative gain plus a positive gain due to the increased speed.

Maybe the non straight curve form of RIAA is negligible or selves- 
compensating due to the the mechanical effects in a speeding vinyl ..

What do you think?

Kind regards,

Daniel








Am 05.11.2016 um 20:50 schrieb Mark Hills:
> The timecode decoder is almost totally self-calibrating; adding an RIAA
> preamp will have almost no effect on the decoding.
>
> The only reason I can think to implement one in Mixxx is if you want to
> use your software preamp to listen to regular vinyls (not timecode)
>
> Also keep in mind that when scratch etc. the Serato 1KHz sine wave then
> appears at all sorts of frequencies. That would make it technically
> incorrect to apply an RIAA equalisation, but in practice I don't see it
> making any difference.
>
> A more interesting side note is: to emulate a more 'correct' vinyl sound
> during scratching, the playback software should not just timestretch, but
> apply an inverse RIAA curve to the audio file, followed by the necessary
> timestretching, followed by the RIAA curve. I have not tested how
> noticable this difference would be.
>
> (When you scratch on a regular vinyl and turntable it shifts lots of
> frequences around but the equalisation curve is left in place)
>

--
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] RIAA equalization, timecode, and preamps

[Daniel Schürmann]

Hi,

According to this post a solution without the RIAA eq should work "equal
well":
https://sourceforge.net/p/xwax/mailman/xwax-devel/thread/5150c184.40...@oscille.ca/

There is only the remaining issue that path-though will sound bad.

Mixxx already offers a digital 44 dB gain, that should be able to boots the
phone level to line level.

So we may consider to add an RIAA eq to Mixxx.
Unfortunately, we loose bit resolution by such a high digital gain you will
use only 9 bit of your 16 bit ADC. (bit-cruscher effect)

Do we have requests for it?

Kind regards,

Daniel










2016-10-31 9:29 GMT+01:00 Gernot Tutner :

> Have you ever tried it out with a "normal" preamp?
>
> Gernot
>
> 
> --
> The Command Line: Reinvented for Modern Developers
> Did the resurgence of CLI tooling catch you by surprise?
> Reconnect with the command line and become more productive.
> Learn the new .NET and ASP.NET CLI. Get your free copy!
> http://sdm.link/telerik
> ___
> 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
>
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
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] Verify Broadcast Auto Reconnect Feature

[Daniel Schürmann]

Hi,

we are currently working on am "Broadcast Auto Reconnect" feature.
https://github.com/mixxxdj/mixxx/pull/1031

Use cases:

1. Unattended broadcasting: Mixxx should do everything a user would do 
to bring the stream back online without a long interrupt.
2. Mixxx should not try to reconnect, if the stream was intentional 
closed by the server.

The current proposed version has these new preferences options:
* Reconnect Delay [s]
* Maximum Retries
* [x] Limit number of reconnect attempts

Once Mixxx is connected the first time the Auto Reconnect Feature is 
reconnecting on any failure, using these parameters.

Is this sufficient? Could this violate server rules or etiquette?

What are good defaults?

Could we remove ore replace these preference options with something 
better? These values are hard to set just right ...

Thank you for your help.


Daniel


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
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] recommend QT_NO_GLIB ?

[Daniel Schürmann]

Hi

I was exited to see if her is a measurable difference.
So I added a Scoped timer around

 {
 ScopedTimer t("emit(valueChanged())");
 emit(valueChanged(value, pSender));
 }

I did 3 test runs QT_NO_GLIB unset and 3 set. Every time I play 10 
seconds of the same track:

./mixxx --devloper

Debug [Main]: 
Stat("emit(valueChanged())","count=20178,sum=1.0176e+08ns,average=5043.1ns,min=123ns,max=1.20981e+07ns,variance=1.71805e+10ns^2,stddev=131074ns")
Debug [Main]: 
Stat("emit(valueChanged())","count=20268,sum=9.97117e+07ns,average=4919.66ns,min=127ns,max=1.2527e+07ns,variance=1.78212e+10ns^2,stddev=133496ns")
Debug [Main]: 
Stat("emit(valueChanged())","count=20289,sum=1.01444e+08ns,average=4999.94ns,min=124ns,max=1.23328e+07ns,variance=1.50495e+10ns^2,stddev=122676ns")


QT_NO_GLIB=1 ./mixxx --developer

Debug [Main]: 
Stat("emit(valueChanged())","count=20603,sum=9.09682e+07ns,average=4415.29ns,min=128ns,max=1.56305e+07ns,variance=1.53043e+10ns^2,stddev=123711ns")
Debug [Main]: 
Stat("emit(valueChanged())","count=20242,sum=1.04024e+08ns,average=5139ns,min=137ns,max=1.51701e+07ns,variance=2.29287e+10ns^2,stddev=151422ns")
Debug [Main]: 
Stat("emit(valueChanged())","count=20601,sum=1.01946e+08ns,average=4948.57ns,min=130ns,max=1.25509e+07ns,variance=1.57278e+10ns^2,stddev=125410ns")

There is no measurable difference!
Is the test significant?

Kind regards, Daniel




Am 21.10.2016 um 14:53 schrieb RJ Ryan:
> Gah, the sorts of things we do in the audio callback thread. This
> definitely sounds worth testing, thanks Nils!
>
> I'm not sure we would see any difference in profiling since it would
> likely affect tail latency only. Does anybody have a test environment
> they could run some good A/B tests on? It sounds like a netbook or other
> resource constrained environment would be a good place to start -- set
> the latency to a value it just starts to xrun on and then test with and
> without this flag.
>
> On Fri, Oct 21, 2016 at 8:02 AM, Nils Goroll  > wrote:
>
> Hi,
>
> TL;DR: setting QT_NO_GLIB may make QT event delivery more efficient
> which could
> help reduce latencies.
>
> -
>
> I'm using mixxx master on Debian 8.6. While checking for possible
> underrun
> causes, I noticed that an strace of the portaudio callback thread
> shows many
> writes which appear unnecessary:
>
> poll([{fd=56, events=POLLOUT|POLLERR|POLLNVAL}], 1, 11) = 1 ([{fd=56,
> revents=POLLOUT}])
> ioctl(56, SNDRV_PCM_IOCTL_STATUS, 0x7fd3153d4b20) = 0
> write(3, "\1\0\0\0\0\0\0\0", 8) = 8
> write(3, "\1\0\0\0\0\0\0\0", 8) = 8
> ioctl(56, SNDRV_PCM_IOCTL_STATUS, 0x7fd3153d4b20) = 0
> poll([{fd=56, events=POLLOUT|POLLERR|POLLNVAL}], 1, 11) = 1 ([{fd=56,
> revents=POLLOUT}])
> ioctl(56, SNDRV_PCM_IOCTL_STATUS, 0x7fd3153d4b20) = 0
> write(3, "\1\0\0\0\0\0\0\0", 8) = 8
> write(3, "\1\0\0\0\0\0\0\0", 8) = 8
> ioctl(56, SNDRV_PCM_IOCTL_STATUS, 0x7fd3153d4b20) = 0
> poll([{fd=56, events=POLLOUT|POLLERR|POLLNVAL}], 1, 11) = 1 ([{fd=56,
> revents=POLLOUT}])
> ioctl(56, SNDRV_PCM_IOCTL_STATUS, 0x7fd3153d4b20) = 0
> write(3, "\1\0\0\0\0\0\0\0", 8) = 8
> write(3, "\1\0\0\0\0\0\0\0", 8) = 8
> write(3, "\1\0\0\0\0\0\0\0", 8) = 8
> write(3, "\1\0\0\0\0\0\0\0", 8) = 8
> futex(0x2d9f4dc, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647,
> 0x2d9f4b0, 2230) = 1
> futex(0x2d9f4b0, FUTEX_WAKE_PRIVATE, 1) = 1
> ioctl(56, SNDRV_PCM_IOCTL_STATUS, 0x7fd3153d4b20) = 0
>
> turns out that these are caused by glib g_wakeup_signal() writes to
> the glib
> eventfd caused by postEvent()s because QT defaults to
> QEventDispatcherGlib. See
> bottom of the email for some exemplary stack traces.
>
> Also, the receiving side (main thread) needs to read all these off
> the eventfd
> (ultimately happening in g_wakeup_acknowledge()).
>
> I _think_ that glib could do better and avoid notifications
> altogether unless
> the receiving thread is actually polling and reducing the eventfd
> notifications
> to just one, but nevertheless there seems to be an easy way out:
> Instruct QT not
> to use the glib event loop by setting
>
> QT_NO_GLIB=whatever
>
> This instructs QT to fall back to QEventDispatcherUNIX which should
> be less
> efficient for a large number of file descriptors, but appears to be
> significantly more efficient in handling QT events: Only one event
> write is
> generated to wake up poll as can be seen in the strace of the
> portaudio callback
> thread:
>
> poll([{fd=73, events=POLLOUT|POLLERR|POLLNVAL}], 1, 11) = 1 ([{fd=73,
> revents=POLLOUT}])
> ioctl(73, SNDRV_PCM_IOCTL_STATUS, 0x7f72abd81b30) = 0
> ioctl(73, SNDRV_PCM_IOCTL_STATUS, 0x7f72abd81b30) = 0
> poll([{fd=73, 

Re: [Mixxx-devel] Aftertouch as dynamic pitchbend?

[Daniel Schürmann]

Hi Urs,

nice Idea.
Unfortunately there is currently no engine support for the requested
feature.

It should be already be possible to implement it as a controller script.
@all: does anyone know If we have one somewhere?

An engine solution should be similar complex and will allow to map such a
pressure sensitive button directly.

We may add a ControlPotmeter "rate_decelecation" ControlObject, somewhere
here:
https://github.com/mixxxdj/mixxx/blob/e59916caf72a256bb28b1722759a629c5cc9cf81/src/engine/ratecontrol.cpp#L113

Could you file a Bug at https://bugs.launchpad.net/mixxx/+filebug, to track
you request until we have a found one who is willing to implement it?

Thank you.

Kind regards,

Daniel




2016-09-29 13:10 GMT+02:00 :

> Dear list,
>
> I started using Mixxx with a midi-controller as lightweight replacement
> for a full two turntable and mixer timecode-vinyl setup with xwax.
>
> I'm using my Akai MPD226 controller, which features faders, knobs and
> pads. I found the MPD 26 preset a good starting point for the configuration.
>
> Coming from vinyl, I find it very intuitive to slow down a track by
> pressing something where more force means less speed or higher
> deceleration. I think this behavior should be reproducible in a very
> intuitive way using the aftertouch messages from a controller pad.
> I tried to map the aftertouch to the pitch_temp_up/down, however it looks
> to me like pitch_temp_up/down doesn't work with little steps or controller
> signal, but only knows on and off.
>
> I had no luck with google to find out if this is possible, or if someone
> has realized something similar.
>
> Looking forward to any ideas
> Urs
>
> 
> --
> ___
> 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] [PATCH 1/1] coverart.cpp: fix build

[Daniel Schürmann]

Hi Andreas,

the patch looks good and can't be the issue.

What is the output of
aplay -l
?

You may provide the clang error messages, maybe one has an idea for a fix.

Kind regards,

Daniel


Am 22.09.2016 um 22:14 schrieb Andreas Müller:
> On Thu, Sep 22, 2016 at 10:50 AM, Andreas Müller
> <schnitzelt...@googlemail.com> wrote:
>> On Thu, Sep 22, 2016 at 10:40 AM, Andreas Müller
>> <schnitzelt...@googlemail.com> wrote:
>>> On Thu, Sep 22, 2016 at 8:21 AM, Daniel Schürmann <dasch...@mixxx.org> 
>>> wrote:
>>>> Hi Andreas,
>>>>
>>>> The QStringBuilder() is somehow hidden. It is only invoked by the operator
>>>> %.
>>>> In all cases, where % is involved, you can simply replace
>>>> QLatin1Literal("string") by "string".
>>>>
>>>> There is no need for testing, other that it compiles on your Qt 5
>>>> environment.
> FWIW:
>
> Good news:
>  * mixxx runs fine on RaspPi2 - so far (see bad news)
>
> Bad news:
> * Just noticed that I have only Alsa loopback interface - the others
> are gone for not yet known reasons
> * Sent the PR but clang build failed. I could not really find out what
> went wrong and am not that sure if it was caused by the patch I sent..
>
> Andreas
>

--
___
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] [PATCH 1/1] coverart.cpp: fix build

[Daniel Schürmann]

Hi Andreas,

The QStringBuilder() is somehow hidden. It is only invoked by the operator
%.
In all cases, where % is involved, you can simply replace
QLatin1Literal("string") by "string".

There is no need for testing, other that it compiles on your Qt 5
environment.

If you decide to do a GitHub pull request, you have the benefit that the
connected Travis build server will build you code on Ubuntu Trusty using Qt
4.8. Otherwise I will do the 4.8 check.

Could you tell us more about you cross compile project?

Thank you.

Daniel




2016-09-22 0:49 GMT+02:00 Andreas Müller <schnitzelt...@googlemail.com>:

> On Tue, Sep 20, 2016 at 11:42 AM, Daniel Schürmann <dasch...@mixxx.org>
> wrote:
> > I have just filed a QT bug
> > https://bugreports.qt.io/browse/QTBUG-56087
> >
> >
> >
> > 2016-09-20 11:17 GMT+02:00 Daniel Schürmann <dasch...@mixxx.org>:
> >>
> >> Hi Andreas,
> >>
> >> thank you for the patch.
> >>
> >> Looking at it, I havenoticed an Qt issue:
> >>
> >> In Qt 5, there is
> >>
> >> typedef QLatin1String QLatin1Literal;
> >>
> >> However, I cannot find the original template constructor:
> >>
> >> template QLatin1Literal(const char()[N])
> >>
> >> So I am afraid this solution here requires char counting until '\0'
> >>
> >>
> >> https://github.com/qt/qtbase/blob/601019e3f42516b5799fe519115f8f
> bdf44ed18a/src/corelib/tools/qstring.h#L92
> >>
> >> QString has now a template constructor:
> >>
> >> https://github.com/qt/qtbase/blob/601019e3f42516b5799fe519115f8f
> bdf44ed18a/src/corelib/tools/qstring.h#L664
> >>
> >> The sting-builder has the template constructor all the time.
> >>
> >> https://github.com/qt/qtbase/blob/601019e3f42516b5799fe519115f8f
> bdf44ed18a/src/corelib/tools/qstringbuilder.h#L280
> >>
> >>
> >> Conclusion:
> >> User Plain char[N] strings in connection with the String builder
> operator
> >> %
> >>
> >> Would you mind to update the patch or better issue a Github Pull
> request?
> >>
> >> Thank you.
> >>
> >> Kind regards,
> >>
> >> Daniel
> >>
> >>
> Hello Daniel,
>
> 1. sorry for late reply - too many issues
>
> 2. thanks for much interesting investigation - really interesting. I
> expected it would not be that easy :)
> Before sending the patch I never heard of QStringBuilder. So I checked
> the qt docs for QString for 4.8 and 5.7 what might have caused the
> trouble which lead to the patch I sent.
>
> 3. I will build/test with plain char[N] strings tomorrow. Do you think
> that solution will work for Qt 4.8 too? Background: I am (cross)
> building everything and my images are Qt 4.8 free currently. Testing
> with Qt 4.8 would cause hours additional build time
>
> Cheers
>
> Andreas
>
--
___
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] [PATCH 1/1] coverart.cpp: fix build

[Daniel Schürmann]

I have just filed a QT bug
https://bugreports.qt.io/browse/QTBUG-56087



2016-09-20 11:17 GMT+02:00 Daniel Schürmann <dasch...@mixxx.org>:

> Hi Andreas,
>
> thank you for the patch.
>
> Looking at it, I havenoticed an Qt issue:
>
> In Qt 5, there is
>
> typedef QLatin1String QLatin1Literal;
>
> However, I cannot find the original template constructor:
>
> template QLatin1Literal(const char()[N])
>
> So I am afraid this solution here requires char counting until '\0'
>
> https://github.com/qt/qtbase/blob/601019e3f42516b5799fe519115f8f
> bdf44ed18a/src/corelib/tools/qstring.h#L92
>
> QString has now a template constructor:
> https://github.com/qt/qtbase/blob/601019e3f42516b5799fe519115f8f
> bdf44ed18a/src/corelib/tools/qstring.h#L664
>
> The sting-builder has the template constructor all the time.
> https://github.com/qt/qtbase/blob/601019e3f42516b5799fe519115f8f
> bdf44ed18a/src/corelib/tools/qstringbuilder.h#L280
>
>
> Conclusion:
> User Plain char[N] strings in connection with the String builder operator %
>
> Would you mind to update the patch or better issue a Github Pull request?
>
> Thank you.
>
> Kind regards,
>
> Daniel
>
>
>
>
> 2016-09-20 8:34 GMT+02:00 Andreas Müller <schnitzelt...@googlemail.com>:
>
>> fixes (with gcc-6 / Qt5.7):
>> src/library/coverart.cpp:35:44: error: no match for 'operator%' (operand
>> types are 'QString' and 'QLatin1Literal {aka QLatin1String}')
>>  return typeToString(infoRelative.type) % QLatin1Literal(",") %
>> ^
>> src/library/coverart.cpp: In function 'QString
>> {anonymous}::coverInfoToString(const CoverInfo&)':
>> src/library/coverart.cpp:42:44: error: no match for 'operator%' (operand
>> types are 'QString' and 'QLatin1Literal {aka QLatin1String}')
>>  return coverInfoRelativeToString(info) % QLatin1Literal(",") %
>> ^
>>
>> Signed-off-by: Andreas Müller <schnitzelt...@googlemail.com>
>> ---
>>  src/library/coverart.cpp | 14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/src/library/coverart.cpp b/src/library/coverart.cpp
>> index 621b424..2afc5f0 100644
>> --- a/src/library/coverart.cpp
>> +++ b/src/library/coverart.cpp
>> @@ -1,5 +1,5 @@
>>  #include 
>> -#include 
>> +#include 
>>
>>  #include "library/coverart.h"
>>  #include "library/coverartutils.h"
>> @@ -32,15 +32,15 @@ QString typeToString(CoverInfo::Type type) {
>>  }
>>
>>  QString coverInfoRelativeToString(const CoverInfoRelative&
>> infoRelative) {
>> -return typeToString(infoRelative.type) % QLatin1Literal(",") %
>> -   sourceToString(infoRelative.source) % QLatin1Literal(",") %
>> -   infoRelative.coverLocation % QLatin1Literal(",") %
>> -   QLatin1Literal("0x") % QString::number(infoRelative.hash,
>> 16);
>> +return typeToString(infoRelative.type) % QLatin1String(",") %
>> +   sourceToString(infoRelative.source) % QLatin1String(",") %
>> +   infoRelative.coverLocation % QLatin1String(",") %
>> +   QLatin1String("0x") % QString::number(infoRelative.hash, 16);
>>  }
>>
>>  QString coverInfoToString(const CoverInfo& info) {
>> -return coverInfoRelativeToString(info) % QLatin1Literal(",") %
>> -   info.trackLocation % QLatin1Literal(",");
>> +return coverInfoRelativeToString(info) % QLatin1String(",") %
>> +   info.trackLocation % QLatin1String(",");
>>  }
>>  } // anonymous namespace
>>
>> --
>> 2.5.5
>>
>>
>> 
>> --
>> ___
>> 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] [PATCH 1/1] coverart.cpp: fix build

[Daniel Schürmann]

Hi Andreas,

thank you for the patch.

Looking at it, I havenoticed an Qt issue:

In Qt 5, there is

typedef QLatin1String QLatin1Literal;

However, I cannot find the original template constructor:

template QLatin1Literal(const char()[N])

So I am afraid this solution here requires char counting until '\0'

https://github.com/qt/qtbase/blob/601019e3f42516b5799fe519115f8fbdf44ed18a/src/corelib/tools/qstring.h#L92

QString has now a template constructor:
https://github.com/qt/qtbase/blob/601019e3f42516b5799fe519115f8fbdf44ed18a/src/corelib/tools/qstring.h#L664

The sting-builder has the template constructor all the time.
https://github.com/qt/qtbase/blob/601019e3f42516b5799fe519115f8fbdf44ed18a/src/corelib/tools/qstringbuilder.h#L280


Conclusion:
User Plain char[N] strings in connection with the String builder operator %

Would you mind to update the patch or better issue a Github Pull request?

Thank you.

Kind regards,

Daniel




2016-09-20 8:34 GMT+02:00 Andreas Müller :

> fixes (with gcc-6 / Qt5.7):
> src/library/coverart.cpp:35:44: error: no match for 'operator%' (operand
> types are 'QString' and 'QLatin1Literal {aka QLatin1String}')
>  return typeToString(infoRelative.type) % QLatin1Literal(",") %
> ^
> src/library/coverart.cpp: In function 'QString 
> {anonymous}::coverInfoToString(const
> CoverInfo&)':
> src/library/coverart.cpp:42:44: error: no match for 'operator%' (operand
> types are 'QString' and 'QLatin1Literal {aka QLatin1String}')
>  return coverInfoRelativeToString(info) % QLatin1Literal(",") %
> ^
>
> Signed-off-by: Andreas Müller 
> ---
>  src/library/coverart.cpp | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/src/library/coverart.cpp b/src/library/coverart.cpp
> index 621b424..2afc5f0 100644
> --- a/src/library/coverart.cpp
> +++ b/src/library/coverart.cpp
> @@ -1,5 +1,5 @@
>  #include 
> -#include 
> +#include 
>
>  #include "library/coverart.h"
>  #include "library/coverartutils.h"
> @@ -32,15 +32,15 @@ QString typeToString(CoverInfo::Type type) {
>  }
>
>  QString coverInfoRelativeToString(const CoverInfoRelative& infoRelative)
> {
> -return typeToString(infoRelative.type) % QLatin1Literal(",") %
> -   sourceToString(infoRelative.source) % QLatin1Literal(",") %
> -   infoRelative.coverLocation % QLatin1Literal(",") %
> -   QLatin1Literal("0x") % QString::number(infoRelative.hash, 16);
> +return typeToString(infoRelative.type) % QLatin1String(",") %
> +   sourceToString(infoRelative.source) % QLatin1String(",") %
> +   infoRelative.coverLocation % QLatin1String(",") %
> +   QLatin1String("0x") % QString::number(infoRelative.hash, 16);
>  }
>
>  QString coverInfoToString(const CoverInfo& info) {
> -return coverInfoRelativeToString(info) % QLatin1Literal(",") %
> -   info.trackLocation % QLatin1Literal(",");
> +return coverInfoRelativeToString(info) % QLatin1String(",") %
> +   info.trackLocation % QLatin1String(",");
>  }
>  } // anonymous namespace
>
> --
> 2.5.5
>
>
> 
> --
> ___
> 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] Travis CI False Positives Mac Builds

[Daniel Schürmann]

Hi,

we get lately a lot of false positives building Mixxx on Mac via Travis:
https://travis-ci.org/mixxxdj/mixxx/builds/160026424

This is because Travis has a 45 min time out.

Can one of the Mac contributors have a look at it?
What is the easiest way to reduce the build time?

Thank you,

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] Fwd: Re: New library GUI design [was: Left library pane selection]

[Daniel Schürmann]

Hi Be,

Joan and I are currently working on an improved version of the library 
redesign branch.
It will allow midi and keyboard control.
We have played with your and Ferrans Ideas and now trying to make the 
best of it.
We aren't pleased with the current branch state, so is not yet a good 
candidate for further discussions.
It will probably take a bit since GSoC is now over.

Kind regards,

Daniel



Am 05.09.2016 um 20:07 schrieb Be:
> Thoughts on these ideas?
>
> On 08/22/2016 12:17 PM, Be wrote:
>> I think we have been too constrained in our thinking by the old library
>> design. We're too accustomed to everything being controlled from the
>> left side of the library area. Having all the controls affecting each
>> feature within their own feature area would me more intuitive. It will
>> require a small bit of adjustment for current users, but I think they
>> will quickly get used to it and like it.
>>
>> On 08/22/2016 12:04 PM, Be wrote:
>>> (I forgot to reply list before, but fortunately this actually succeeded
>>> in breaking the super deep thread display in Thunderbird for me).
>>>
>>> Come to think of it, without the feature icon list taking up horizontal
>>> space, I think we could afford to have a LibrarySidebarExpanded adjacent
>>> to each track table!
>>>
>>> On 08/22/2016 12:01 PM, Be wrote:
>>>> On 08/22/2016 11:35 AM, Daniel Schürmann wrote:
>>>>> Am 22.08.2016 3:44 nachm. schrieb "Be" <b...@gmx.com 
>>>>> <mailto:b...@gmx.com>>:
>>>>>
>>>>>> There are two problems with this:
>>>>>> 1. If Auto DJ is open in the right track table, there is a spatial
>>>>>> disconnect between the open feature and where the user has to click to
>>>>>> access its LibrarySidebarExpanded.
>>>>>> 2. The feature icon bar is relatively cluttered. To open the
>>>>>> LibrarySidebarExpanded with your proposal requires searching through
>>>>>> many different icons to find the desired one and understanding where it
>>>>>> would open a track table if it would change the open track tables.
>>>>> Yes, this bugs me as well. The button bar was introduced to avoid
>>>>> scrolling when changing features. But we get not entirely rid of it. We
>>>>> have discussed to introduce a fly out menu or customizable sorting, but
>>>>> no idea has become real by now.
>>>>>
>>>> Oh! Now I understand how a fly out menu could work: to replace the
>>>> feature icon bar entirely. Clicking and releasing the breadcrumb icon
>>>> would change LibrarySidebarExpanded to show the current track table's
>>>> feature. Clicking and holding the breadcrumb icon would bring up a menu
>>>> like the current feature icons list. This would make our differences
>>>> about focusing track table panes moot because different features would
>>>> be opened directly on the track table they change.
>>>>
>>>>>> Having an icon on the track tables for this will solve both issues.
>>>>> Good idea! We have actually an icon for it: The breadcrumb icon. It
>>>>> should be somehow natural for this feature because it matches the button
>>>>> bar icon.
>>>>>
>>>> I was thinking of using the new focus button for this, but I'm liking
>>>> the idea outlined above better.
>>>>
>>>> --
>>>> ___
>>>> 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



--
___
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] FFmpeg and version support

[Daniel Schürmann]

Hi Tuukka,

we normally use Ubuntu as reference which package version we should support
and which not.

Our build system runs on Ubuntu 14.4 (Trusty)
Mixxx has dropped Ubuntu 12.4 (Precise) support due to the introduction of
c++11.

So it would be nice, If we continue to support Trusty.
Unfortunately the switch back to ffmpeg happens after Trusty.

In Trusty there is:
libav 6:9.18-0ubuntu0.14.04.1
with libavcodec54  54.35.0

So it looks like you can remove some of the #ifdefs, if they are itching.

Kind regards,

Daniel.

















2016-09-05 15:38 GMT+02:00 Tuukka Pasanen :

> Hello,
>
> I'm probably the other one (other one is my evil twin) of two who are
> using the FFmpeg input plugin with Mixxx but I'll try to ask this before
> doing anything. Currently FFmpeg supports versions from 0.8 up (my
> testing) 3.0 and same amount of AVconv versions.
>
> Now as semiofficial FFmpeg input plugin user, developer and maintainer I
> like to ask. Which is the lowest version that we should support? Below
> version 1.2 are probably the most problematic because after that they
> changed how samples are in memory. This causes little more #ifdef magic
> that I like to see in code.
>
> Are people even using old and crusty versions of FFmpeg anymore? Please
> have time to answer because if there is now very vocal majority I'll
> remove that support when I clean FFmpeg 3.0 compile errors. AVConv is
> going a way from Debian and Ubuntu so there is no problems with that
> front anymore because removing below 1.2 support will cause Ubuntu 12.04
> and probably 14.04 stop working.
>
> Sincerely,
>
> Tuukka
>
>
> 
> --
> ___
> 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] xspf addon plugins

[Daniel Schürmann]

Hi Antonio,

xspf support would be a nice addition for Mixxx.
It is not hard to add it directly into the Mixxx code base (recompile).
Unfortunately there are no other docs of this topic than the code itself.

Please file a Launchpad bug for your request:
https://bugs.launchpad.net/mixxx/+filebug

Do you have time and fun, to add it to Mixxx?
That would be great.

Here are some general hints:
http://www.mixxx.org/wiki/doku.php/bugfix_workflow

For the implementation, you can use
https://github.com/mixxxdj/mixxx/blob/94e9c0c93d985119ffb6403d774882c02c4ce6a4/src/library/parserpls.cpp
as template.

This seams to be a good overview of Qt XML support:
http://3gfp.com/wp/2014/07/three-ways-to-parse-xml-in-qt/

If you need additional help, just ask!

Kind regards,

Daniel







Am 26.08.2016 um 17:08 schrieb mrn...@mrnfnc.it:
> Hi, there is a way to have a xspf generated out of your mixes? If not
> this is a way to write addons or should I branch mixx recompile the
> whole mixx and add modification.
> So obvious questions that i think you will point out proper doc online.
> Cannot find this myself googling for mixx plugin addon or whatever, beg
> you pardon.
> Cheers
> Antonio
>
>
> --
>
>
>
> ___
> 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] New library GUI design [was: Left library pane selection]

[Daniel Schürmann]

Am 22.08.2016 3:29 nachm. schrieb "Be" :

>> Since this seams to be to opposide opinions which do not fit together,
>> the only solution I see is to make the pane storing a preference option.
>>
>
> I don't think there should be an option. There should be one way that
works. Options will be hard to discover and a hassle to maintain different
code.

If the single one works for me it would be OK :-P

> I don't think forgetting where the focus is will be an issue when there
is always a focus and it can only be set by intentional action to set the
focus. The problem with forgetting where the focus was before arose because
it was confusing to predict which pane would be focused and the focus was
coupled to clicking tracks in the track tables.

Where did you get this opinion from?
Maybe we should implement actually the   the two schemas as preference
option and than we can test and decide what works best.

> It seems we have a choice between which set of buttons serves two
purposes. Either
>
> 1. the feature icons serve the dual purposes of opening track tables and
LibrarySidebarExpanded for features with already opened track tables or
> 2. the new focus icons serve the dual purpose of controlling where the
feature icons will open a track table and opening LibrarySidebarExpanded
>  for features with already opened track tables
>
> I think #2 is more intuitive and straightforward, both for knowing where
a feature icon will open a track table and for opening the
LibrarySidebarExpanded for a feature that already has a track table open.
#1 requires the complicated asymmetric rules discussed below.

For me #1 is more intuitive, it works better for controllers and not at
least it matches exactly the learned behaviour of Mixxx 2.0 in case of one
pane collapsed.

> I think this will not be as self-explaining as my proposal. I think we
will have many users confused and frustrated because they can't figure out
how to change the feature in the right track table pane.

That should be the same in both proposals. The user has to find the
pointing hand.
--
___
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] New library GUI design [was: Left library pane selection]

[Daniel Schürmann]

I think we have a big misunderstanding because of the naming of the 
panes. From left to right, we have:
* ButtonBar
* LibrarySidbarExpandend (holding the tree views)
* left pane (1)
* right pane (2)
* additional panes (n)


>> 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 ;-).
>
> With my proposal, I think this would be less of an issue for a few
> reasons. It would always be explicitly clear which right pane a feature
> icon will open in and it would be difficult for a user to accidentally
> switch the focus.

There is no issue that a user switches existential the focus any more.
The user has now a dedicated click that is required to switch the focus.

 From my experience it helps a lot to let the Auto DJ track table appear 
always right. In your model it happens easy that a user searches for a 
track in the left pane. Now he wants to use AutoDJ controls, lets say 
"Fade now", he clicks on AutoDJ controls the Auto DJ button without 
caring about the focus. Result: The library track tabke is replaced with 
a second AutoDJ pane. This is worse in two ways. He lost the state of 
the current search process in the library, and he gets a second unwanted 
AutoDJ pane.

Some clicks later, he has learned to click on the preselect button 
before changing to AutoDJ, he forgets setting the focus when going back 
and ends up in the AutoDJ track table left.
This is also annoying, because you can easily oversee the breadcrumb 
title and use the wrong pane in the head of the night.

With the saved pane association al this bad cannot happen. But you can 
still follow your favorite concept to preselect the pane as you like.


> If the user wants AutoDJ on the right, they click the
> focus icon of the right track table and click the Auto DJ feature icon.
> No exceptions and no surprises.

This will work in your model and in mine the same way.

> Also, removing the dual purpose of the
> feature icons (opening left and right panes in different situations)
> would make it more difficult for users to accidentally open a feature
> where they don't want to.

I assume that the case is far more common that the user wants to open 
the track table where it was before the moving it around. For me moving 
panes around is only a one time issue at the very start of a new use case.

> * Turn browse encoder: scroll through selected GUI pane. If feature icon
> bar is selected, open each feature in the focused track table as each
> feature icon is scrolled through. If left pane is selected, open
> selected tree item in focused track table (don't do anything for buttons
> like Auto DJ and Analyze controls though). If track table is selected,
> scroll through it but do not take action as each track is selected.

I want to keep my library left and AutoDJ right association even when I 
use the controller. Taking the mouse to switch the pane focus makes the 
whole controller navigation useless. If I do open every feature in the 
left pane, the whole dual pane feature is useless.

> * Push browse encoder: similar to current Tab key behavior, but not
> quite the same. Cycle through selecting feature icons/left pane/right
> track tables to scroll through
> * Shift + push browse encoder: toggle focused track table like the new
> focus icons
> * Load buttons: load selected track to respective deck
> * Shift + load buttons: eject track from respective deck

That might work, but is not self explaining.

> I was referring to a
> situation like having a Library track table and Auto DJ track table both
> open. When the left pane shows the library tree and the user wants to
> access the left pane controls for Auto DJ, how should they do this? IMO
> it requires a bit of a mental disconnect to remember to move the cursor
> from the Auto DJ track table back over to the Auto DJ feature icon. It
> would be most straightforward to click the new focus icon on the Auto DJ
> track table.

This is somehow a matter of taste. The AutoDJ button is always next to 
the area where the AutoDJ controls will appear, independent where the 
AutoDJ pane is currently displayed. That's not to odd in my opinion.

>> 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.
>
> Not quite. If the left pane follows the right pane focus as I propose,
> to open two playlists side-by-side:
>
> * Click focus button on a track 

Re: [Mixxx-devel] Left library pane selection

[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
>>
>
> --
> ___
> 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] Left library pane selection

[Daniel Schürmann]

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

[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 <dasch...@mixxx.org
<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

[Daniel Schürmann]

Hi Ferran,

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

My issue comes in when you just forget about the two panes and focus and 
all the stuff. Your thoughts are around the audience and which track is 
the next one and where you find it.

For me it is clear that keeping the panes association is desired.
The button bar is very easy to click, but sometimes you cannot just 
click, you have to correct the focus. Unfortunately the pane focus is 
somehow out of sight and hard to change by the controller.
Arranging a desired view is easy with your model, but keeping it is 
hard, but IMHO the later is the desired behaviour during the night.

In your tab model the issue becomes worth because the additional degree 
of freedom. The user must always verify and possible correct the pane 
focus and the tab before clicking the button bar. Opening a new tab in 
the AutoDJ pane is even more work.

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.

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

It looks like we cannot find a compromise based one of our discussed 
options.

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.

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.

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"

What do you think?















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