Re: [Mixxx-devel] 1.12 release progress
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 ferranpujolcam...@gmail.com 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, re-cy...@hushmail.com mailto:re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann dasch...@mixxx.org 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 b...@gmx.com mailto:b...@gmx.com: On 07/22/2015 12:00 AM, Sébastien BLAISOT wrote: Hi all, Some more blockers : *
Re: [Mixxx-devel] 1.12 release progress
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 b...@gmx.com 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 remaining. Is there other work needed ? * website updates (RJ ryan is working on this). We also need to open more languages for website translation on transifex. it's actually limited
Re: [Mixxx-devel] Advanced mapping questions
--- 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
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
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] 1.12 release progress
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 ferranpujolcam...@gmail.com 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, re-cy...@hushmail.com mailto:re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann dasch...@mixxx.org 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
Re: [Mixxx-devel] 1.12 release progress
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 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, re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann 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
Re: [Mixxx-devel] 1.12 release progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 17:28:17 + Sébastien BLAISOT mi...@blaisot.org 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 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, re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann 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
Re: [Mixxx-devel] 1.12 release progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann 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 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
[Mixxx-devel] Advanced mapping questions
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
[Mixxx-devel] Bug ?
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
Re: [Mixxx-devel] 1.12 release progress
Well, you've already reviewed PR #639 https://github.com/mixxxdj/mixxx/pull/639, you might want to check one more time. The only issue I see to it is that sometimes the show library option on the view menu does nothing. But, AFAIK, the skin has no way to tell Mixxx when this option should be grayed out and when it should be active. 2015-07-22 23:02 GMT+02:00 Owen Williams owilli...@mixxx.org: 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 ferranpujolcam...@gmail.com 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, re-cy...@hushmail.com mailto:re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann dasch...@mixxx.org 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
Re: [Mixxx-devel] 1.12 release progress
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 ferranpujolcam...@gmail.com 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, re-cy...@hushmail.com mailto:re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann dasch...@mixxx.org 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
Re: [Mixxx-devel] 1.12 release progress
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 ferranpujolcam...@gmail.com 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, re-cy...@hushmail.com mailto:re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann dasch...@mixxx.org 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 -
Re: [Mixxx-devel] 1.12 release progress
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
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
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 rr...@mixxx.org: 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, re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann 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 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: *
Re: [Mixxx-devel] 1.12 release progress
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, re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann 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 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
Re: [Mixxx-devel] 1.12 release progress
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, re-cy...@hushmail.com va escriure: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 22 Jul 2015 06:28:38 + Daniel Schürmann 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 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
