Re: [Mixxx-devel] 1.12 release progress

[re-cycle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On Wed, 22 Jul 2015 23:49:13 + "Sébastien Blaisot"
 wrote:
>I agree, we should wait post 1.12 release to discuss this. at
>first, i
>wanted to wait for 1.12 release before talking about that, but
>todays
>discussion let me at least disappointed.
>
>for the windows specific issue, absolutely no build env is needed
>because one PR targets the installer, the other one targets the
>default
>skin. You just need a windows machine to test. or at least discuss
>about
>the consequences of the change I propose.
>

I've got a Windows 7 environment, will that do? If so, just tell me
what to do and look for. Just do an upgrade over 1.11 with the
latest beta? What else?

~RAWRR

>but, yes, more windows compiling env would be better ;)
>
>sb
>
>Le 22/07/2015 19:47, Be a écrit :
>> I agree. I think we should discuss these issues in detail after
>1.12 is
>> released. For now, let's focus on getting those active PRs
>merged and
>> the manual.
>>
>> The long review time for Windows-specific issues is a problem.
>For me,
>> the issue is how much of a hassle it is to compile on Windows.
>I'd be
>> happy to borrow a computer with Windows for testing if that
>didn't
>> require installing a bunch of stuff to compile an unmerged pull
>request.
>>
>> On 07/22/2015 12:27 PM, Sébastien BLAISOT wrote:
>>> Hi,
>>>
>>> I strongly disagree with you. We have a wonderfull new feature
>with
>>> resizable skins and this new feature is ruined by our windows
>installer
>>> because if you install 1.12 on top of 1.11, you get the old
>skins :(
>>> Upgrade is not rare. We already discussed about that, I
>proposed a PR
>>> which is waiting review since 1+ month. Saying today that this
>is not a
>>> blocker don't correct the real problem : nobody seems to care
>about
>>> windows users. This is relatively easy to merge, we must
>improve 1.12
>>> quality including this PR.
>>>
>>> In my opinion, the problems of the mixxx project aren't
>marketing or
>>> software quality, but two others :
>>>
>>> - The lack of release management process. We need to know when
>are the
>>> new functionnality merge windows, when we are in feature
>freeze, what
>>> and how we should consider blockers, and so on. and we need
>someone / a
>>> team that dispatch remaining work to achieve release with a
>clearly
>>> stated date or quality and focus every developpers on
>correcting
>>> remaining bugs when we are about to release (for example avoid
>wasting
>>> time talking about coding style during beta cycle). With a
>release
>>> managemen process, the goal won't shift, or only in a
>controlled way.
>>>
>>> - The lack of decision process. This project is only driven by
>strong
>>> consensus. When we don't have an overall agreement, nothing is
>done. it
>>> is normal, in real life, that different people have different
>opinions.
>>> We need a way to choose between different opinions. Either with
>a strong
>>> project leader, or with a published process (like voting for
>example).
>>> This should be published.
>>>
>>> ---
>>> Sébastien Blaisot
>
>
>
>---
>---
>___
>Get Mixxx, the #1 Free MP3 DJ Mixing software Today
>http://mixxx.org
>
>
>Mixxx-devel mailing list
>Mixxx-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/mixxx-devel
-BEGIN PGP SIGNATURE-
Charset: UTF8
Version: Hush 3.0
Note: This signature can be verified at https://www.hushtools.com/verify

wpwEAQMCAAYFAlWwhbcACgkQzo/Gj4mkNMzj8gP/bYRLvagdoDdYvtEI9iZdpgplqvP6
9Gb74TOHCBU8rEvVnu/Ibi+ouJLfWMC6RDG+53hQHhnEJhhUp+TELAegqdwhg1flaKvy
Wy0MFCMDqd+4bvYaelA7MnQI82nJmrdDqga+JW5E28YnXMnd9WMDtPhsrHkqPrh41Ir2
IzQVxjA=
=apqV
-END PGP SIGNATURE-


--
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Re: [Mixxx-devel] 1.12 release progress

[Be]

PR 638 and PR 657 are ready.

On 07/22/2015 05:30 PM, Be wrote:
> PR 649 is ready. I'll finish up PR 638 tonight.
>
> On 07/22/2015 04:02 PM, Owen Williams wrote:
>> For PRs that people think are ready and would like to merge in, can you
>> list the actual numbers?  Our PR list is very dense and fast-moving.
>>
>> I am willing to take a look at the PRs that are in flight, but I can't
>> guarantee that I will agree that everything is low risk or ready to
>> merge.  If people trust me enough to make that decision then the process
>> can work, but if not then I'd rather not spend the time doing the
>> review.  If someone asks for my review and they don't like the answer,
>> then they didn't want a review, they wanted a rubber stamp :).  I am
>> admittedly quite conservative when it comes to LGTMing a PR for the
>> beta, but I'd argue that's what we need.
>>
>> It would also be nice if our milestone list was more realistic:
>> https://launchpad.net/mixxx/+milestone/1.12.0  There are tons of bugs
>> targeted to 1.12 that will not get fixed and shouldn't block the
>> release.  I'd like people to go through the list and remove the target
>> milestone if they don't think a bug should really block the release.
>> (Don't switch the milestone to the next version either, just remove it.)
>> This even goes for crashers that are just too hard to reproduce.
>>
>> For instance, as much as it annoys me that the analyze pane doesn't pick
>> up the custom font choice, it's not worth blocking over.
>> (https://bugs.launchpad.net/mixxx/+bug/1427368)
>>
>> Owen
>>
>> On Wed, 2015-07-22 at 10:50 -0500, Be wrote:
>>> Most of the issues listed by Sebastian and I are low risk and pretty
>>> much ready to merge. The points that aren't being addressed yet are the
>>> flaky broadcasting connection, Opus crash, and library search bar focus
>>> issue. I'd be fine merging the key sorting as is without polishing it
>>> for the Lancelot notation system if that's not ready by release time.
>>>
>>> On 07/22/2015 09:12 AM, RJ Ryan wrote:
 Daniel/RAWRR are right -- the goal posts are moving slightly and we're
 scope creeping.

 Active, trivial / low-risk PRs can merge if they are ready but shouldn't
 be blocking.

 For me, the final blocker is the manual and website / press material --
 which we simply can't launch without. :)

 Best regards,
 RJ

 On Wed, Jul 22, 2015 at 8:11 AM, Ferran Pujol Camins
 mailto:ferranpujolcam...@gmail.com>> wrote:

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

   So my modest opinion is the same that Daniel.

   El dia 22/07/2015 12:16, >>>   > va escriure:

   -BEGIN PGP SIGNED MESSAGE-
   Hash: SHA1



   On Wed, 22 Jul 2015 06:28:38 + "Daniel Schürmann"
   mailto:dasch...@mixxx.org>> wrote:
>Hi,
>
>We have to be careful to consider what is a release blocker.
>Mixxx 1.12 beta is already so much better than 1.11 that it is 
 not
>worth to
>block it at all from this point of view.
>
>Of cause we should try to fix all critical bugs before a 
 release
>date, but
>in this stage I consider a
>release blocker only a regression that prevents one from using
>1.12.
>>From this point of view only this one is a blocker:
>* flaky broadcasting connections: LP 1277274
>
>The other topics are its the over all quality issue.
>
>Everyone can already use 1.12 beta. What is the difference to a
>1.12
>release?
>IMHO it is all the shiny stuff that makes the difference from a
>project to
>a product.
>It is marketing, design, manual, advertising texts, screen 
 shots
>and so on.
>A product with good maketing/design is always considered as 
 high
>quality,
>regardless
>of the number of critical bugs.
>
>Unfortunately marketing experts are rare among our 
 contributors.
>Any Idea to change this?
>

   Yeah.

   If the betas really are that close, arrive at a consensus 
 regarding
   some reasonable candidate among these beta versions to designate 
 as
   a release, publish it, and continue on behind the

Re: [Mixxx-devel] 1.12 release progress

[Sébastien Blaisot]

Le 22/07/2015 23:02, Owen Williams a écrit :
> For PRs that people think are ready and would like to merge in, can you
> list the actual numbers?  Our PR list is very dense and fast-moving.
>
> I am willing to take a look at the PRs that are in flight, but I can't
> guarantee that I will agree that everything is low risk or ready to
> merge.  If people trust me enough to make that decision then the process
> can work, but if not then I'd rather not spend the time doing the
> review.  If someone asks for my review and they don't like the answer,
> then they didn't want a review, they wanted a rubber stamp :).  I am
> admittedly quite conservative when it comes to LGTMing a PR for the
> beta, but I'd argue that's what we need.

I trust everyone who is willing to take a look at the PR I make and give 
me some feedback, even if the feedback is "we will not merge this crap" ;)

PR621: The question is: is it acceptable to ship Mixxx with a faulty 
upgrade path between 1.11 and 1.12 which leads to 1.12 with 1.11 skins
PR627:  The question is: is it acceptable to ship Mixxx with the effect 
eject button replaced by a square in the default skin

Thanks in advance for reviewing this

sb


--
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Re: [Mixxx-devel] 1.12 release progress

[Sébastien Blaisot]

I agree, we should wait post 1.12 release to discuss this. at first, i 
wanted to wait for 1.12 release before talking about that, but todays 
discussion let me at least disappointed.

for the windows specific issue, absolutely no build env is needed 
because one PR targets the installer, the other one targets the default 
skin. You just need a windows machine to test. or at least discuss about 
the consequences of the change I propose.

but, yes, more windows compiling env would be better ;)

sb

Le 22/07/2015 19:47, Be a écrit :
> I agree. I think we should discuss these issues in detail after 1.12 is
> released. For now, let's focus on getting those active PRs merged and
> the manual.
>
> The long review time for Windows-specific issues is a problem. For me,
> the issue is how much of a hassle it is to compile on Windows. I'd be
> happy to borrow a computer with Windows for testing if that didn't
> require installing a bunch of stuff to compile an unmerged pull request.
>
> On 07/22/2015 12:27 PM, Sébastien BLAISOT wrote:
>> Hi,
>>
>> I strongly disagree with you. We have a wonderfull new feature with
>> resizable skins and this new feature is ruined by our windows installer
>> because if you install 1.12 on top of 1.11, you get the old skins :(
>> Upgrade is not rare. We already discussed about that, I proposed a PR
>> which is waiting review since 1+ month. Saying today that this is not a
>> blocker don't correct the real problem : nobody seems to care about
>> windows users. This is relatively easy to merge, we must improve 1.12
>> quality including this PR.
>>
>> In my opinion, the problems of the mixxx project aren't marketing or
>> software quality, but two others :
>>
>> - The lack of release management process. We need to know when are the
>> new functionnality merge windows, when we are in feature freeze, what
>> and how we should consider blockers, and so on. and we need someone / a
>> team that dispatch remaining work to achieve release with a clearly
>> stated date or quality and focus every developpers on correcting
>> remaining bugs when we are about to release (for example avoid wasting
>> time talking about coding style during beta cycle). With a release
>> managemen process, the goal won't shift, or only in a controlled way.
>>
>> - The lack of decision process. This project is only driven by strong
>> consensus. When we don't have an overall agreement, nothing is done. it
>> is normal, in real life, that different people have different opinions.
>> We need a way to choose between different opinions. Either with a strong
>> project leader, or with a published process (like voting for example).
>> This should be published.
>>
>> ---
>> Sébastien Blaisot



--
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Re: [Mixxx-devel] 1.12 release progress

[Be]

PR 649 is ready. I'll finish up PR 638 tonight.

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

Re: [Mixxx-devel] 1.12 release progress

[Ferran Pujol Camins]

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

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

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

Re: [Mixxx-devel] 1.12 release progress

[Owen Williams]

For PRs that people think are ready and would like to merge in, can you
list the actual numbers?  Our PR list is very dense and fast-moving.  

I am willing to take a look at the PRs that are in flight, but I can't
guarantee that I will agree that everything is low risk or ready to
merge.  If people trust me enough to make that decision then the process
can work, but if not then I'd rather not spend the time doing the
review.  If someone asks for my review and they don't like the answer,
then they didn't want a review, they wanted a rubber stamp :).  I am
admittedly quite conservative when it comes to LGTMing a PR for the
beta, but I'd argue that's what we need.

It would also be nice if our milestone list was more realistic:
https://launchpad.net/mixxx/+milestone/1.12.0  There are tons of bugs
targeted to 1.12 that will not get fixed and shouldn't block the
release.  I'd like people to go through the list and remove the target
milestone if they don't think a bug should really block the release.
(Don't switch the milestone to the next version either, just remove it.)
This even goes for crashers that are just too hard to reproduce.

For instance, as much as it annoys me that the analyze pane doesn't pick
up the custom font choice, it's not worth blocking over.
(https://bugs.launchpad.net/mixxx/+bug/1427368)

Owen

On Wed, 2015-07-22 at 10:50 -0500, Be wrote:
> Most of the issues listed by Sebastian and I are low risk and pretty 
> much ready to merge. The points that aren't being addressed yet are the 
> flaky broadcasting connection, Opus crash, and library search bar focus 
> issue. I'd be fine merging the key sorting as is without polishing it 
> for the Lancelot notation system if that's not ready by release time.
> 
> On 07/22/2015 09:12 AM, RJ Ryan wrote:
> > Daniel/RAWRR are right -- the goal posts are moving slightly and we're
> > scope creeping.
> >
> > Active, trivial / low-risk PRs can merge if they are ready but shouldn't
> > be blocking.
> >
> > For me, the final blocker is the manual and website / press material --
> > which we simply can't launch without. :)
> >
> > Best regards,
> > RJ
> >
> > On Wed, Jul 22, 2015 at 8:11 AM, Ferran Pujol Camins
> > mailto:ferranpujolcam...@gmail.com>> wrote:
> >
> >  From my point of view, marketing wise, we could consider 1.12 a
> > modest release. Because despite the huge amount of work there's
> > behind it, every review out there will essentially say "it is great
> > and finally have FX, but the built in FX are weak".
> >
> > So my modest opinion is the same that Daniel.
> >
> > El dia 22/07/2015 12:16,  > > va escriure:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> >
> >
> > On Wed, 22 Jul 2015 06:28:38 + "Daniel Schürmann"
> > mailto:dasch...@mixxx.org>> wrote:
> >  >Hi,
> >  >
> >  >We have to be careful to consider what is a release blocker.
> >  >Mixxx 1.12 beta is already so much better than 1.11 that it is not
> >  >worth to
> >  >block it at all from this point of view.
> >  >
> >  >Of cause we should try to fix all critical bugs before a release
> >  >date, but
> >  >in this stage I consider a
> >  >release blocker only a regression that prevents one from using
> >  >1.12.
> >  >>From this point of view only this one is a blocker:
> >  >* flaky broadcasting connections: LP 1277274
> >  >
> >  >The other topics are its the over all quality issue.
> >  >
> >  >Everyone can already use 1.12 beta. What is the difference to a
> >  >1.12
> >  >release?
> >  >IMHO it is all the shiny stuff that makes the difference from a
> >  >project to
> >  >a product.
> >  >It is marketing, design, manual, advertising texts, screen shots
> >  >and so on.
> >  >A product with good maketing/design is always considered as high
> >  >quality,
> >  >regardless
> >  >of the number of critical bugs.
> >  >
> >  >Unfortunately marketing experts are rare among our contributors.
> >  >Any Idea to change this?
> >  >
> >
> > Yeah.
> >
> > If the betas really are that close, arrive at a consensus regarding
> > some reasonable candidate among these beta versions to designate as
> > a release, publish it, and continue on behind the scenes
> > developing, like you do.
> >
> > Mixxx is marketed really well already. If you are thinking
> > representation to the public is unclear, consider that perception
> > will be clarified when the download page has a "release", and
> > further accentuated with the usual rounds of well-crafted press
> > submissions to various DJ industry and tech sites and magazines
> > (which one of you f

Re: [Mixxx-devel] 1.12 release progress

[re-cycle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On Wed, 22 Jul 2015 17:28:17 + "Sébastien BLAISOT"
 wrote:
>Hi,
>
>I strongly disagree with you. We have a wonderfull new feature
>with
>resizable skins and this new feature is ruined by our windows
>installer
>because if you install 1.12 on top of 1.11, you get the old skins
>:(
>Upgrade is not rare. We already discussed about that, I proposed a
>PR
>which is waiting review since 1+ month. Saying today that this is
>not a
>blocker don't correct the real problem : nobody seems to care
>about
>windows users. This is relatively easy to merge, we must improve
>1.12
>quality including this PR.
>
>In my opinion, the problems of the mixxx project aren't marketing
>or
>software quality, but two others :
>
>- The lack of release management process. We need to know when are
>the
>new functionnality merge windows, when we are in feature freeze,
>what
>and how we should consider blockers, and so on. and we need
>someone / a
>team that dispatch remaining work to achieve release with a
>clearly
>stated date or quality and focus every developpers on correcting
>remaining bugs when we are about to release (for example avoid
>wasting
>time talking about coding style during beta cycle). With a release
>managemen process, the goal won't shift, or only in a controlled
>way.
>
>- The lack of decision process. This project is only driven by
>strong
>consensus. When we don't have an overall agreement, nothing is
>done. it
>is normal, in real life, that different people have different
>opinions.
>We need a way to choose between different opinions. Either with a
>strong
>project leader, or with a published process (like voting for
>example).
>This should be published.
>
>---
>
>Sébastien Blaisot
>

A big +1 to this whole entry. However, (mirroring Be's thought) the
concerns of all but the first paragraph should not be debated until
the work is done to get 1.12 out, and it is released.

After release, it will be nice to put whichever release management
process gets chosen up on GitHub as well, even if it will probably
remain static for a long time. Mixxx's reference base is already
powerful, and this basic detail should be part of it.

Re: manuals, we can introduce a contributor etiquette wherein
authors of new features/functionalities are strongly encouraged at
their point of introduction (GitHub?) to update the corresponding
section of the manual once their work is done. This can be helped
enormously if the Mixxx code and the relevant Manual section can be
crosslinked in some way - if markers of some kind are in the Manual
code, and can be used, we can do: X information lives at Y section
of the manual, etc..

~RAWRR

>Le 22/07/2015 16:12, RJ Ryan a écrit :
>
>> Daniel/RAWRR are right -- the goal posts are moving slightly and
>we're scope creeping.
>>
>> Active, trivial / low-risk PRs can merge if they are ready but
>shouldn't be blocking.
>>
>> For me, the final blocker is the manual and website / press
>material -- which we simply can't launch without. :)
>>
>> Best regards,
>> RJ
>>
>> On Wed, Jul 22, 2015 at 8:11 AM, Ferran Pujol Camins
> wrote:
>>
>> From my point of view, marketing wise, we could consider 1.12 a
>modest release. Because despite the huge amount of work there's
>behind it, every review out there will essentially say "it is
>great and finally have FX, but the built in FX are weak".
>>
>> So my modest opinion is the same that Daniel.
>> El dia 22/07/2015 12:16,  va escriure:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Wed, 22 Jul 2015 06:28:38 + "Daniel Schürmann"
>>
>>  wrote:
>>> Hi,
>>>
>>> We have to be careful to consider what is a release blocker.
>>> Mixxx 1.12 beta is already so much better than 1.11 that it is
>not
>>> worth to
>>> block it at all from this point of view.
>>>
>>> Of cause we should try to fix all critical bugs before a
>release
>>> date, but
>>> in this stage I consider a
>>> release blocker only a regression that prevents one from using
>>> 1.12.
 From this point of view only this one is a blocker:
>>> * flaky broadcasting connections: LP 1277274
>>>
>>> The other topics are its the over all quality issue.
>>>
>>> Everyone can already use 1.12 beta. What is the difference to a
>>> 1.12
>>> release?
>>> IMHO it is all the shiny stuff that makes the difference from a
>>> project to
>>> a product.
>>> It is marketing, design, manual, advertising texts, screen
>shots
>>> and so on.
>>> A product with good maketing/design is always considered as
>high
>>> quality,
>>> regardless
>>> of the number of critical bugs.
>>>
>>> Unfortunately marketing experts are rare among our
>contributors.
>>> Any Idea to change this?
>>>
>>
>> Yeah.
>>
>> If the betas really are that close, arrive at a consensus
>regarding
>> some reasonable candidate among these beta versions to designate
>as
>> a release, publish it, and continue on behind the scenes
>> developing, like you do.
>>
>> Mixxx is marketed really well already. If you

[Mixxx-devel] 1.12 manual

[Be]

Can we make a TODO list and designate tasks for the 1.12 manual?

adding section for splitter cable setup: myself
effects: ???
new screenshots: ???
hierarchical library sorting: Daniel?
vinyl and auxiliary passthrough: ???
What else is missing?

Btw, I find it hilarious that the screenshot of the search term is "dank" :P

--
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Re: [Mixxx-devel] 1.12 release progress

[Sean M. Pappalardo - D.J. Pegasus]

On 07/22/2015 08:24 AM, RJ Ryan wrote:

The manual still needs a fair bit of work -- if a section looks like it
was updated for 1.12 then it's probably safe to translate that.


RJ, since you have the most knowledge of who worked on what new 1.12 
features, can you post such a list here so we can then ask those folks 
for details as we update the manual?


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



smime.p7s
Description: S/MIME Cryptographic Signature
--
___
Get Mixxx, the #1 Free MP3 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] Advanced mapping questions

[Sean M. Pappalardo - D.J. Pegasus]

Hello.

Glad you like my work!

On 07/22/2015 05:32 AM, Stephan Balmer wrote:

1. Is there a way to communicate state between controllers? As far as  I
understand the scripts run isolated.


That's correct. There is an open bug to address this though: 
https://bugs.launchpad.net/mixxx/+bug/374239
so please vote for that, but as Be said, we plan to address it with a 
Control system overhaul. Though addressing this doesn't _require_ a 
control system overhaul, just the ability for scripts to create and 
destroy new internal Mixxx controls.


In the meantime, hacks like what you did (re-purposing another Mixxx 
control) will work, but obviously aren't guaranteed, and may cause 
problems if users actually use that control for its intended purpose. :)



I wanted the deck devices to  switch
decks automatically when the deck is changed on the mixer.


That's exactly why I filed the bug in the first place. :)
This also applies to SCS.1, Numark V7, and Behringer CMD devices. 
(Pretty much any modular controllers.)


I don't have answers for the others. Perhaps RJ can chime in about the 
effects, as he wrote most of that code.


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



smime.p7s
Description: S/MIME Cryptographic Signature
--
___
Get Mixxx, the #1 Free MP3 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] Advanced mapping questions

[Be]

There is no good way for inter-device communication without affecting 
the Mixxx engine. I think in the future there should be a way for 
scripts to create their own control objects in the future. See also:
https://bugs.launchpad.net/mixxx/+bug/1470278
http://mixxx.org/wiki/doku.php/new_control_mapping_format

On 07/22/2015 07:32 AM, Stephan Balmer wrote:
>
> Hi Mixxxers
>
> Thanks for your work on 1.12.  I like it, especially having the  effects!
>
> My 1.12 mapping for the Stanton SCS3 system has progressed into a
> 'usable for me' state where it has all the functionality I need and it
> has no known issues that would prevent live use. I've started a thread
> on the forum to discuss mapping decisions, but there are some questions
> best addressed here, I think.
>
> The current state of the SCS mapping:
> https://github.com/sbalmer/mixxx.scs3m
>
> A big thank to Sean  for your scripts! Your work was the reason I bought
> the devices in the first place, and figuring out how to talk to them
> would have been very cumbersome without that head-start.
>
>
> There are a few things where I hope for input.
>
> 1. Is there a way to communicate state between controllers? As far as  I
> understand the scripts run isolated.
>
> The SCS3 system consists of three devices. One central mixer device,
> and two deck devices. The mixer has buttons to switch between decks  and
> as such it is ready for four decks. I wanted the deck devices to  switch
> decks automatically when the deck is changed on the mixer.
>
> Because I couldn't find a way to have the scripts communicate directly
> to each other, I repurposed an engine control to hold deck state. Now
> "[PreviewDeck1] quantize" is used to hold an integer with three bits  of
> state which is set and read by the three devices. I know this is
> horrible practice and if there is a better way to do it please let me
> know. Works fine though :-)
>
>
>
> 2. Should I care about the filter controls being deprecated?
>
> The wiki at http://www.mixxx.org/wiki/doku.php/mixxxcontrols says that
> the filter controls filterLow/Mid/High are deprecated. I don't know  how
> I could replace them to control the standard EQ.
>
>
>
> 3. Do you have recommendations regarding the mapping of effect chains?
>
> I added some mapping to control effect chains. Or more specific, you
> choose the effect chain you'd like to control, then the EQ-sliders
> control the first three EQ-knobs of the first effect in the chain.  This
> falls short of the visions laid out in the 'effects_framework'
> wiki-page. I developed this using the Latenight skin, then I saw that
> Shade uses different logic assigning channels to chains where each deck
> uses one chain, and now I'm  confused about how to go on.
>
>
>
> I know that there may not be a good answer to these questions, but  even
> some hints could improve the situation.
>
> Thanks
> Stephan
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> ___
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org
>
>
> Mixxx-devel mailing list
> Mixxx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>

--
___
Get Mixxx, the #1 Free MP3 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] Advanced mapping questions

[Sébastien BLAISOT]

 

something went wrong when sending the mail. It was an answer to this
question 

> 2. Should I care about the filter controls being deprecated?
> 
> The wiki at http://www.mixxx.org/wiki/doku.php/mixxxcontrols [1] says that 
> the filter controls filterLow/Mid/High are deprecated. I don't know how 
> I could replace them to control the standard EQ.

---

Sébastien Blaisot 

Le 22/07/2015 19:46, Sébastien BLAISOT a écrit : 

>> ---
>> 
>> Sébastien Blaisot
> 
> you can use : 
> Low => engine.setValue("[EqualizerRack1_[Channel1]_Effect1]", "parameter1", 
> value)
> Mid => engine.setValue("[EqualizerRack1_[Channel1]_Effect1]", "parameter2", 
> value) 
> High => engine.setValue("[EqualizerRack1_[Channel1]_Effect1]", "parameter3", 
> value) 
> 
> I don't have answer for the other questions. 
> 
> regards, 
> 
> sb 
> 
> --
>  
> 
> ___
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org [2]
> 
> Mixxx-devel mailing list
> Mixxx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel [3]
 

Links:
--
[1] http://www.mixxx.org/wiki/doku.php/mixxxcontrols
[2] http://mixxx.org
[3] 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] 1.12 release progress

[Be]

I agree. I think we should discuss these issues in detail after 1.12 is 
released. For now, let's focus on getting those active PRs merged and 
the manual.

The long review time for Windows-specific issues is a problem. For me, 
the issue is how much of a hassle it is to compile on Windows. I'd be 
happy to borrow a computer with Windows for testing if that didn't 
require installing a bunch of stuff to compile an unmerged pull request.

On 07/22/2015 12:27 PM, Sébastien BLAISOT wrote:
> Hi,
>
> I strongly disagree with you. We have a wonderfull new feature with
> resizable skins and this new feature is ruined by our windows installer
> because if you install 1.12 on top of 1.11, you get the old skins :(
> Upgrade is not rare. We already discussed about that, I proposed a PR
> which is waiting review since 1+ month. Saying today that this is not a
> blocker don't correct the real problem : nobody seems to care about
> windows users. This is relatively easy to merge, we must improve 1.12
> quality including this PR.
>
> In my opinion, the problems of the mixxx project aren't marketing or
> software quality, but two others :
>
> - The lack of release management process. We need to know when are the
> new functionnality merge windows, when we are in feature freeze, what
> and how we should consider blockers, and so on. and we need someone / a
> team that dispatch remaining work to achieve release with a clearly
> stated date or quality and focus every developpers on correcting
> remaining bugs when we are about to release (for example avoid wasting
> time talking about coding style during beta cycle). With a release
> managemen process, the goal won't shift, or only in a controlled way.
>
> - The lack of decision process. This project is only driven by strong
> consensus. When we don't have an overall agreement, nothing is done. it
> is normal, in real life, that different people have different opinions.
> We need a way to choose between different opinions. Either with a strong
> project leader, or with a published process (like voting for example).
> This should be published.
>
> ---
> Sébastien Blaisot
>
> Le 22/07/2015 16:12, RJ Ryan a écrit :
>
>> Daniel/RAWRR are right -- the goal posts are moving slightly and we're
>> scope creeping.
>> Active, trivial / low-risk PRs can merge if they are ready but
>> shouldn't be blocking.
>> For me, the final blocker is the manual and website / press material
>> -- which we simply can't launch without. :)
>> Best regards,
>> RJ
>>
>> On Wed, Jul 22, 2015 at 8:11 AM, Ferran Pujol Camins
>> mailto:ferranpujolcam...@gmail.com>> wrote:
>>
>> From my point of view, marketing wise, we could consider 1.12 a
>> modest release. Because despite the huge amount of work there's
>> behind it, every review out there will essentially say "it is
>> great and finally have FX, but the built in FX are weak".
>>
>> So my modest opinion is the same that Daniel.
>>
>> El dia 22/07/2015 12:16, > > va escriure:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>
>> On Wed, 22 Jul 2015 06:28:38 + "Daniel Schürmann"
>> mailto:dasch...@mixxx.org>> wrote:
>> >Hi,
>> >
>> >We have to be careful to consider what is a release blocker.
>> >Mixxx 1.12 beta is already so much better than 1.11 that it
>> is not
>> >worth to
>> >block it at all from this point of view.
>> >
>> >Of cause we should try to fix all critical bugs before a release
>> >date, but
>> >in this stage I consider a
>> >release blocker only a regression that prevents one from using
>> >1.12.
>> >>From this point of view only this one is a blocker:
>> >* flaky broadcasting connections: LP 1277274
>> >
>> >The other topics are its the over all quality issue.
>> >
>> >Everyone can already use 1.12 beta. What is the difference to a
>> >1.12
>> >release?
>> >IMHO it is all the shiny stuff that makes the difference from a
>> >project to
>> >a product.
>> >It is marketing, design, manual, advertising texts, screen shots
>> >and so on.
>> >A product with good maketing/design is always considered as high
>> >quality,
>> >regardless
>> >of the number of critical bugs.
>> >
>> >Unfortunately marketing experts are rare among our contributors.
>> >Any Idea to change this?
>> >
>>
>> Yeah.
>>
>> If the betas really are that close, arrive at a consensus
>> regarding
>> some reasonable candidate among these beta versions to
>> designate as
>> a release, publish it, and continue on behind the scenes
>> developing, like you do.
>>
>> Mixxx is marketed really well already. If you are thinking
>> representation 

Re: [Mixxx-devel] Advanced mapping questions

[Sébastien BLAISOT]

 

> ---
> 
> Sébastien Blaisot

you can use : 
Low => engine.setValue("[EqualizerRack1_[Channel1]_Effect1]",
"parameter1", value)
Mid => engine.setValue("[EqualizerRack1_[Channel1]_Effect1]",
"parameter2", value) 
High => engine.setValue("[EqualizerRack1_[Channel1]_Effect1]",
"parameter3", value) 

I don't have answer for the other questions. 

regards, 

sb --
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Re: [Mixxx-devel] 1.12 release progress

[Sébastien BLAISOT]

 

Hi, 

I strongly disagree with you. We have a wonderfull new feature with
resizable skins and this new feature is ruined by our windows installer
because if you install 1.12 on top of 1.11, you get the old skins :(
Upgrade is not rare. We already discussed about that, I proposed a PR
which is waiting review since 1+ month. Saying today that this is not a
blocker don't correct the real problem : nobody seems to care about
windows users. This is relatively easy to merge, we must improve 1.12
quality including this PR. 

In my opinion, the problems of the mixxx project aren't marketing or
software quality, but two others : 

- The lack of release management process. We need to know when are the
new functionnality merge windows, when we are in feature freeze, what
and how we should consider blockers, and so on. and we need someone / a
team that dispatch remaining work to achieve release with a clearly
stated date or quality and focus every developpers on correcting
remaining bugs when we are about to release (for example avoid wasting
time talking about coding style during beta cycle). With a release
managemen process, the goal won't shift, or only in a controlled way. 

- The lack of decision process. This project is only driven by strong
consensus. When we don't have an overall agreement, nothing is done. it
is normal, in real life, that different people have different opinions.
We need a way to choose between different opinions. Either with a strong
project leader, or with a published process (like voting for example).
This should be published. 

---

Sébastien Blaisot 

Le 22/07/2015 16:12, RJ Ryan a écrit : 

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

Re: [Mixxx-devel] 1.12 release progress

[Be]

Most of the issues listed by Sebastian and I are low risk and pretty 
much ready to merge. The points that aren't being addressed yet are the 
flaky broadcasting connection, Opus crash, and library search bar focus 
issue. I'd be fine merging the key sorting as is without polishing it 
for the Lancelot notation system if that's not ready by release time.

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

Re: [Mixxx-devel] 1.12 release progress

[RJ Ryan]

The manual still needs a fair bit of work -- if a section looks like it was
updated for 1.12 then it's probably safe to translate that.

On Wed, Jul 22, 2015 at 10:44 AM, Ferran Pujol Camins <
ferranpujolcam...@gmail.com> wrote:

> Are the manual sources updated? I can translate to Spanish and Catalan but
> I'd like to wait until I know the sources won't change anymore (or change
> very slightly).
>
> 2015-07-22 16:12 GMT+02:00 RJ Ryan :
>
>> Daniel/RAWRR are right -- the goal posts are moving slightly and we're
>> scope creeping.
>>
>> Active, trivial / low-risk PRs can merge if they are ready but shouldn't
>> be blocking.
>>
>> For me, the final blocker is the manual and website / press material --
>> which we simply can't launch without. :)
>>
>> Best regards,
>> RJ
>>
>>
>> On Wed, Jul 22, 2015 at 8:11 AM, Ferran Pujol Camins <
>> ferranpujolcam...@gmail.com> wrote:
>>
>>> From my point of view, marketing wise, we could consider 1.12 a modest
>>> release. Because despite the huge amount of work there's behind it, every
>>> review out there will essentially say "it is great and finally have FX, but
>>> the built in FX are weak".
>>>
>>> So my modest opinion is the same that Daniel.
>>> El dia 22/07/2015 12:16,  va escriure:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On Wed, 22 Jul 2015 06:28:38 + "Daniel Schürmann"
  wrote:
 >Hi,
 >
 >We have to be careful to consider what is a release blocker.
 >Mixxx 1.12 beta is already so much better than 1.11 that it is not
 >worth to
 >block it at all from this point of view.
 >
 >Of cause we should try to fix all critical bugs before a release
 >date, but
 >in this stage I consider a
 >release blocker only a regression that prevents one from using
 >1.12.
 >>From this point of view only this one is a blocker:
 >* flaky broadcasting connections: LP 1277274
 >
 >The other topics are its the over all quality issue.
 >
 >Everyone can already use 1.12 beta. What is the difference to a
 >1.12
 >release?
 >IMHO it is all the shiny stuff that makes the difference from a
 >project to
 >a product.
 >It is marketing, design, manual, advertising texts, screen shots
 >and so on.
 >A product with good maketing/design is always considered as high
 >quality,
 >regardless
 >of the number of critical bugs.
 >
 >Unfortunately marketing experts are rare among our contributors.
 >Any Idea to change this?
 >

 Yeah.

 If the betas really are that close, arrive at a consensus regarding
 some reasonable candidate among these beta versions to designate as
 a release, publish it, and continue on behind the scenes
 developing, like you do.

 Mixxx is marketed really well already. If you are thinking
 representation to the public is unclear, consider that perception
 will be clarified when the download page has a "release", and
 further accentuated with the usual rounds of well-crafted press
 submissions to various DJ industry and tech sites and magazines
 (which one of you folks usually does that anyway?).

 It seems like everyone in development wants 1.12 to be a singular,
 glorious debut - but I think looking for that misses the mark.
 There is an actual glorious debut, but it was and is the momentum
 in productivity that fired up six months or so ago and will push
 all the way through 1.12 to the continuing evolution of the
 project, and a more modern style of development cycle.

 

 Also my personal two cents about the roadmap (apologies if it is
 off-base): I think new feature sprawl might be happening? If so, I
 myself probably contributed to it. I know this observation won't be
 popular!! Everyone wants and loves new features. But I think many
 of the debates going on will be less exasperating and more
 manageable when there are fewer projects underway in general.
 Between 1.11 and 1.12, so much got piled on the plate!! Even as
 someone without responsibilities free to simply observe, I find it
 difficult to keep track of all the threads underway.

 ~RAWRR

 >Kind regards,
 >
 >Daniel
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >2015-07-22 7:55 GMT+02:00 Be :
 >
 >>
 >>
 >> On 07/22/2015 12:00 AM, Sébastien BLAISOT wrote:
 >> > Hi all,
 >> >
 >> > Some more blockers :
 >> >
 >> > * (win) installing 1.12 on top of a previous version
 >installation
 >> > (lp:1457618) => PR621 is *still* waiting for merge. Please
 >review and
 >> > discuss if we move version to beta2
 >> >
 >> > * (win) Eject symbol not shown in LateNight skin (lp:1454649)
 >=> PR627
 >> > is *still* waiting for review and merge
 >>
 >> Who ca

Re: [Mixxx-devel] 1.12 release progress

[Be]

On 07/22/2015 01:28 AM, Daniel Schürmann wrote:
> Everyone can already use 1.12 beta. What is the difference to a 1.12
> release?
> IMHO it is all the shiny stuff that makes the difference from a project
> to a product.
> It is marketing, design, manual, advertising texts, screen shots and so on.
> A product with good maketing/design is always considered as high
> quality, regardless
> of the number of critical bugs.
>
> Unfortunately marketing experts are rare among our contributors.
> Any Idea to change this?

I don't think Mixxx has much of an issue with marketing. "Free DJ 
software" almost markets itself. People seem to know about Mixxx, but 
they consider it a thing just for beginners (see 
https://www.reddit.com/r/Beatmatch/comments/3e4fk1/aspiring_young_dj_questions/ 
for example). The website is pretty and the manual has been clear about 
how to use Mixxx. I think Mixxx's biggest marketing issue has been 
clarity about what it doesn't do that people have come to expect from DJ 
software based on what Traktor, Serato, and Virtual DJ can do. With 
1.12, I think the biggest weak point is support for popular controllers, 
which is why I put so much effort into the Hardware Guide on the wiki. I 
don't think it really helps for the website to have a giant list of 
devices that are mostly discontinued and weren't that popular to begin 
with. The other big weak point, as Ferran pointed out, are the effects.

One strength of Mixxx that I think the website should make a bigger deal 
about is free DVS support that works with any capable sound card. I 
think that should be mentioned on the front page.

> Kind regards,
>
> Daniel
>
>
>
>
>
>
>
>
>
> 2015-07-22 7:55 GMT+02:00 Be mailto:b...@gmx.com>>:
>
>
>
> On 07/22/2015 12:00 AM, Sébastien BLAISOT wrote:
> > Hi all,
> >
> > Some more blockers :
> >
> > * (win) installing 1.12 on top of a previous version installation
> > (lp:1457618) => PR621 is *still* waiting for merge. Please review and
> > discuss if we move version to beta2
> >
> > * (win) Eject symbol not shown in LateNight skin (lp:1454649) => PR627
> > is *still* waiting for review and merge
>
> Who can review these? Who uses Windows?
>
> > About startup time, I noticed, under windows, that startup time is
> > *very* long if I have network shares mounted and a slow (like
> > slooow) network connection. Mixxx probably tries to enumerate all
> > drives at startup, even network ones. I think it should be limited to
> > local drives. Launch time is short if I unmount network shares before
> > launching mixxx. Hope this can be of any help in sorting out this issue.
>
> Why does Mixxx need to enumerate all drives at startup? Shouldn't it
> only need to enumerate drives that the library is configured to scan in?
>
> > ---
> > Sébastien Blaisot
> >
> > Le 22/07/2015 00:03, Be a écrit :
> >
> >> Where are we now? Let's make a list of release blockers:
> >> * skin polish: Ferran's updates to LateNight in PR #639 is a good step
> >> and he said he'd work on Deere too
> >> * weird bug with library search bar focus in LateNight:
> >>https://bugs.launchpad.net/mixxx/+bug/1462061
> >> * Startup time: Mixxx takes a long time to start up on some systems. PR
> >> #655 and PR #650 will alleviate the issue without risking regressions 
> by
> >> messing with the startup code much.
> >> * Opus crash: LP 1458380
> >> * flaky broadcasting connections: LP 1277274
> >> * key sorting: PR #649 in progress
> >> * updating documentation links: PR #657
> >> * manual updates. IMO the people who wrote new features should be the
> >> ones who explain how they work.
> >>
> >> * Electrix Tweaker mapping: PR #638 is almost ready. I ran into a bug
> >> where I couldn't exit a loop using my controller last night. I'm not
> >> sure if it was an issue with the mapping or Mixxx.
> >> * Pioneer DDJ-SB mapping: How is progress on this Joan? Can you put it
> >> on GitHub? See
>  >> http://mixxx.org/wiki/doku.php/midi_scripting#setting_up_git for
> setting
>  >> up git for mappings.
>  >>
>  >> On 06/14/2015 12:33 PM, Sébastien Blaisot wrote:
>  >>>
>  >>> OK, trying to gather what we said about "1.12 release blockers":
>  >>>
>  >>> Done:
>  >>> * skin polish (Jus has an active Deere branch) => PR579 & PR608
> merged.
>  >>> * (win) installing 1.12 on top of a previous version
> installation =>
>  >>> PR621 waiting for merge
>  >>> * (win) Uninstalling Mixxx leave files behind => PR603 merged
>  >>> * (win) Incorrect preferences folder path => PR606 merged
>  >>>
>  >>> Remaining:
>  >>> * critical Windows bugs => RJ told he will have a look at them.
> can we
>  >>> list the critical blockers here ?
>  >>> * skin polish (Jus has an active Deere branch) => bug lp:1454649
>

Re: [Mixxx-devel] 1.12 release progress

[RJ Ryan]

Daniel/RAWRR are right -- the goal posts are moving slightly and we're
scope creeping.

Active, trivial / low-risk PRs can merge if they are ready but shouldn't be
blocking.

For me, the final blocker is the manual and website / press material --
which we simply can't launch without. :)

Best regards,
RJ


On Wed, Jul 22, 2015 at 8:11 AM, Ferran Pujol Camins <
ferranpujolcam...@gmail.com> wrote:

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

Re: [Mixxx-devel] 1.12 release progress

[Ferran Pujol Camins]

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

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

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

[Mixxx-devel] Bug ?

[Peter G. Marczis]

https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Page tells me to tell the admin, that you have a bug :)

Br,
 P.
--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

[Mixxx-devel] Advanced mapping questions

[Stephan Balmer]

Hi Mixxxers

Thanks for your work on 1.12.  I like it, especially having the  effects!

My 1.12 mapping for the Stanton SCS3 system has progressed into a 
'usable for me' state where it has all the functionality I need and it 
has no known issues that would prevent live use. I've started a thread 
on the forum to discuss mapping decisions, but there are some questions 
best addressed here, I think.

The current state of the SCS mapping:
https://github.com/sbalmer/mixxx.scs3m

A big thank to Sean  for your scripts! Your work was the reason I bought 
the devices in the first place, and figuring out how to talk to them 
would have been very cumbersome without that head-start.


There are a few things where I hope for input.

1. Is there a way to communicate state between controllers? As far as  I 
understand the scripts run isolated.

The SCS3 system consists of three devices. One central mixer device, 
and two deck devices. The mixer has buttons to switch between decks  and 
as such it is ready for four decks. I wanted the deck devices to  switch 
decks automatically when the deck is changed on the mixer.

Because I couldn't find a way to have the scripts communicate directly 
to each other, I repurposed an engine control to hold deck state. Now 
"[PreviewDeck1] quantize" is used to hold an integer with three bits  of 
state which is set and read by the three devices. I know this is 
horrible practice and if there is a better way to do it please let me 
know. Works fine though :-)



2. Should I care about the filter controls being deprecated?

The wiki at http://www.mixxx.org/wiki/doku.php/mixxxcontrols says that 
the filter controls filterLow/Mid/High are deprecated. I don't know  how 
I could replace them to control the standard EQ.



3. Do you have recommendations regarding the mapping of effect chains?

I added some mapping to control effect chains. Or more specific, you 
choose the effect chain you'd like to control, then the EQ-sliders 
control the first three EQ-knobs of the first effect in the chain.  This 
falls short of the visions laid out in the 'effects_framework' 
wiki-page. I developed this using the Latenight skin, then I saw that 
Shade uses different logic assigning channels to chains where each deck 
uses one chain, and now I'm  confused about how to go on.



I know that there may not be a good answer to these questions, but  even 
some hints could improve the situation.

Thanks
Stephan

--
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
___
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Re: [Mixxx-devel] 1.12 release progress

[Ferran Pujol Camins]

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

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

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

Re: [Mixxx-devel] 1.12 release progress

[re-cycle]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On Wed, 22 Jul 2015 06:28:38 + "Daniel Schürmann"
 wrote:
>Hi,
>
>We have to be careful to consider what is a release blocker.
>Mixxx 1.12 beta is already so much better than 1.11 that it is not
>worth to
>block it at all from this point of view.
>
>Of cause we should try to fix all critical bugs before a release
>date, but
>in this stage I consider a
>release blocker only a regression that prevents one from using
>1.12.
>>From this point of view only this one is a blocker:
>* flaky broadcasting connections: LP 1277274
>
>The other topics are its the over all quality issue.
>
>Everyone can already use 1.12 beta. What is the difference to a
>1.12
>release?
>IMHO it is all the shiny stuff that makes the difference from a
>project to
>a product.
>It is marketing, design, manual, advertising texts, screen shots
>and so on.
>A product with good maketing/design is always considered as high
>quality,
>regardless
>of the number of critical bugs.
>
>Unfortunately marketing experts are rare among our contributors.
>Any Idea to change this?
>

Yeah.

If the betas really are that close, arrive at a consensus regarding
some reasonable candidate among these beta versions to designate as
a release, publish it, and continue on behind the scenes
developing, like you do.

Mixxx is marketed really well already. If you are thinking
representation to the public is unclear, consider that perception
will be clarified when the download page has a "release", and
further accentuated with the usual rounds of well-crafted press
submissions to various DJ industry and tech sites and magazines
(which one of you folks usually does that anyway?).

It seems like everyone in development wants 1.12 to be a singular,
glorious debut - but I think looking for that misses the mark.
There is an actual glorious debut, but it was and is the momentum
in productivity that fired up six months or so ago and will push
all the way through 1.12 to the continuing evolution of the
project, and a more modern style of development cycle.



Also my personal two cents about the roadmap (apologies if it is
off-base): I think new feature sprawl might be happening? If so, I
myself probably contributed to it. I know this observation won't be
popular!! Everyone wants and loves new features. But I think many
of the debates going on will be less exasperating and more
manageable when there are fewer projects underway in general.
Between 1.11 and 1.12, so much got piled on the plate!! Even as
someone without responsibilities free to simply observe, I find it
difficult to keep track of all the threads underway.

~RAWRR

>Kind regards,
>
>Daniel
>
>
>
>
>
>
>
>
>
>2015-07-22 7:55 GMT+02:00 Be :
>
>>
>>
>> On 07/22/2015 12:00 AM, Sébastien BLAISOT wrote:
>> > Hi all,
>> >
>> > Some more blockers :
>> >
>> > * (win) installing 1.12 on top of a previous version
>installation
>> > (lp:1457618) => PR621 is *still* waiting for merge. Please
>review and
>> > discuss if we move version to beta2
>> >
>> > * (win) Eject symbol not shown in LateNight skin (lp:1454649)
>=> PR627
>> > is *still* waiting for review and merge
>>
>> Who can review these? Who uses Windows?
>>
>> > About startup time, I noticed, under windows, that startup
>time is
>> > *very* long if I have network shares mounted and a slow (like
>> > slooow) network connection. Mixxx probably tries to
>enumerate all
>> > drives at startup, even network ones. I think it should be
>limited to
>> > local drives. Launch time is short if I unmount network shares
>before
>> > launching mixxx. Hope this can be of any help in sorting out
>this issue.
>>
>> Why does Mixxx need to enumerate all drives at startup?
>Shouldn't it
>> only need to enumerate drives that the library is configured to
>scan in?
>>
>> > ---
>> > Sébastien Blaisot
>> >
>> > Le 22/07/2015 00:03, Be a écrit :
>> >
>> >> Where are we now? Let's make a list of release blockers:
>> >> * skin polish: Ferran's updates to LateNight in PR #639 is a
>good step
>> >> and he said he'd work on Deere too
>> >> * weird bug with library search bar focus in LateNight:
>> >> https://bugs.launchpad.net/mixxx/+bug/1462061
>> >> * Startup time: Mixxx takes a long time to start up on some
>systems. PR
>> >> #655 and PR #650 will alleviate the issue without risking
>regressions by
>> >> messing with the startup code much.
>> >> * Opus crash: LP 1458380
>> >> * flaky broadcasting connections: LP 1277274
>> >> * key sorting: PR #649 in progress
>> >> * updating documentation links: PR #657
>> >> * manual updates. IMO the people who wrote new features
>should be the
>> >> ones who explain how they work.
>> >>
>> >> * Electrix Tweaker mapping: PR #638 is almost ready. I ran
>into a bug
>> >> where I couldn't exit a loop using my controller last night.
>I'm not
>> >> sure if it was an issue with the mapping or Mixxx.
>> >> * Pioneer DDJ-SB mapping: How is progress on this Joan?