Hi RAWRR, thanks for your input. To be clear, I am not advocating for supporting newer controllers merely for the sake of newness. I am advocating for that because controllers have gotten better and cheaper over the years and people outside of the bubble of current Mixxx users are more likely to get them. Today's controllers by and large have better build quality and more sophisticated features than comparably priced controllers from years ago. For example, compare a Vestax VCI-100 (http://ecx.images-amazon.com/images/I/81vu3%2Bt70SL._SL1500_.jpg ) to a Pioneer DDJ-SB2 (hhttp://d3qk4yk8nq0n55.cloudfront.net/wp-content/uploads/2015/08/pdj_ddj-sb2-main.png.jpeg?iv=34 ).
I'm not advocating that we only support shiny new expensive controllers. I want Mixxx to be as accessible as possible, and a part of that is good mappings for cheap controllers--but not only the very cheapest controllers. I'm pointing out that the lack of support for shiny expensive controllers and mid-grade controllers is a glaring weak point to anyone outside of our bubble of current Mixxx users. I understand that old, undocumented mappings are still important for many users. I think what would help is to clearly designate them as such, as a sort of sign saying "buy these at your own risk--they may or may not work well". Marking discontinued controllers as discontinued on the wiki helps, but there could be more. I have been thinking about replacing the "Supported since Mixxx version" column on the wiki tables with a "Last updated for Mixxx version" column. This will also help us keep track of mappings that could use updating. The trouble is how to find that information. For mappings that have been updated in the last few years, running git log on the mapping files is easy. For older mappings, I'd appreciate some tips on how to find that information. For most of them, I think it's fairly safe to guess that they have not been updated since the Mixxx version they were first bundled with, but I don't want to assume that. Perhaps at some point I will go looking for old controllers to remap and document. But first I'd like a better mapping system. All that said, I still think we should hold new mappings to a higher standard than mappings have been held to before. On 11/22/2015 06:38 PM, re-cy...@hushmail.com wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My two cents, Be: > > I've been using Mixxx once a month or so every month for the last > five years, and was interested in it before then even. I love this > program and admire the developer community enormously. > > I shop for controllers by form factor and features, not newness. I > also like old hardware because it won't put me out half a grand, > but really, I shop old i hardware for the same reason I shop old > for clothes - I need choices. Decades reliably provide what recent > trends very often lack. > > What I'm saying is, as a user - I'm going to be really happy to > have a clear documentation and template path laid out for me with > articulate and straightforward tutorials. Git definitely should be > demystified for all average computer users moving forward. Thanks > you for helping to chart this territory in Mixxx, I will definitely > travel it. In fact, I need clear documentation so much that I > myself worked on the skinning tutorial wiki for awhile, just to > help myself understand it. > > However. I will be really pissed if the diversity of mappings is > abridged at any point. Ever. Quality or no. And will be further > pissed if forum members' contributions are *by policy* buried in > the jungle of the forum. > > We already have a standard in place for "community supported > mappings" vs. "certified mappings", and there is no reason to flout > this. It's fun, it's professional, and it works. If anything, this > is another standard in need of clearer workflow and signposts. But > you're doing well at facilitating those kinds of things thus far, > and helping here would be an assist appreciated as much for its non- > destructiveness as its productivity. I personally really want you > to lighten up on the "hardware-new! new! new!" pot-clanging, > please. Not shut up - lighten up. Please. > > I agree with: > >> "I would like to see Mixxx outgrow this reputation." > > Meaning the "just for beginners who like to tinker" rep that > reviews occasionally give it. > > But it *is* happening, and you are helping. Everyone is moving > forward steadily. > > So please stop agitating for throwing all of the ancient half-assed > mappings overboard in the name of the hypothetical shiny > uncompromising professional DJ superstar. Mixxx obviously has a > increasingly powerful future, but it also has a character and, > basically, a ministry (I've been one of the most devout of the > converted). Rewrite the old mappings yourself if you have so much > disdain for sloppy community participation. But I want them to > stay. And I want them all bundled with Mixxx - labeled properly. > > This includes references to older controllers in the wiki, by the > way, which was something else i kept meaning to mention, but it > fits well here. > > End rant, with apologies to everyone for contributing to any > nonproductive tangents. > > ~RAWRR > > > On Mon, 23 Nov 2015 00:23:03 +0200 "Be" <b...@gmx.com> wrote: >> (I'm consoldiating these related threads into one.) >> >> On 11/19/2015 08:18 PM, RJ Ryan wrote: >> >>> The standards are much lower since there is little risk to >> doing so. If >>> we took in C++ patches without review we could cause crashes or >> actual >>> damage to the user's computer. The sandboxed environment we run >>> Javascript in is not capable of this. While it's true that >> Javascript >>> can trigger unexpected behavior in Mixxx there is not an >> effective way >>> to explore the set of possible inputs a script will provide to >> Mixxx >>> without the device in hand. In most cases, a preset is not >> going to take >>> down Mixxx. >> >> Mixxx crashing is beside the point to someone who has spent $600+ >> on a >> controller if Mixxx doesn't even support the controller. >> >> Reviewers have been saying for years that the haphazard controller >> >> support is one of Mixxx's biggest weak points and not much has >> been done >> about it till now. They're not just talking about any support >> because >> that is beside the point for someone who spent money on a >> controller and >> could use other software that came with the controller and does >> support >> it. They're talking about fully mapped controllers with >> documentation. >> For example: >> >> http://djtechtools.com/2012/08/07/review-mixxx-1-10-dj-software/ >> >> "Besides, Mixxx includes a good start on MIDI controller >> compatibility, >> with Mixx Certified mappings for 13 controllers — including the >> Midi >> Fighter Classic — and community supported mappings for 29 >> controllers. >> They would love to have you fill in the blanks by creating a new >> mapping. *The functionality and quality of documentation among the >> >> community-supported mappings varies.* [emphasis mine] >> >> I tested Mixxx with the community-supported mapping for the M- >> Audio >> Xponent. It was a nice way to resurrect a controller I had mostly >> placed >> on the shelf. I was able to control Mixxx almost entirely from the >> >> Xponent. With the exception of some browser functions and Sampler >> Deck >> control, keyboard shortcuts could make up for what the controller >> mapping didn’t provide." >> >> >> http://djworx.com/mixxx-1-12-beta-still-free/ >> >> "Setting up isn’t as plug ‘n’ play as commercial offerings, >> either, with >> mapping options relying on DIY rather than a large existing >> library of >> controllers." >> >> Including incomplete mappings like the Xponent mapping reviewed >> above >> does not change this situation. It's still DIY to get one's >> hardware to >> actually work. >> >> >> http://www.digitaldjtips.com/2011/11/review-mixxx-10-1-0-free-dj- >> software/ >> >> "Review Summary: >> >> Mixxx is now better than it’s ever been. If you’re an open source >> enthusiast who knows a bit about Midi, XML and coding in general, >> you >> can get involved and adapt Mixxx to suit whatever Midi gear you >> have, >> but if you’re just a plug-and-play DJ, unless you have one of the >> controllers it is already mapped for, *it isn’t going to be of >> much use >> to you.* [emphasis mine] >> >> ... >> >> Midi and mappings >> But the crucial area where Mixxx still lacks for me is in out-of- >> the-box >> Midi control. Mixxx 1.10.0 comes with support of variable quality >> for a >> small number of controllers, *but it’s not the ones that are >> selling >> well today.* [This was four years ago and the situation hasn't >> changed >> much.] >> >> Now, it is perfectly possible to produce your own mappings. Indeed >> >> there’s a Midi Learn option where you are talked through the >> various >> controls to get a rudimentary mapping going in a matter of minutes >> (I >> got the Vestax VCI-400 we are currently reviewing partly >> controlling the >> software in less than five minutes). >> >> But getting your mapping 100% right? That’s harder. Jogwheels are >> famously the hard bit about Midi mapping, and you need to get your >> >> sleeves rolled up and start hacking in order to add this kind of >> functionality to a custom mapping, using Midi sniffer apps and >> writing >> XML. If you thought mapping Traktor was hard, wait until you get >> stuck >> into this beast. There’s a friendly user community and an >> excellent >> wiki, but plug and play it ain’t, unless you have one of the >> controllers >> it natively supports." >> >>> None of us are lawyers, so we should not be making >> decisions about a >>> legal grey area. I think the legally clearest and safest >> situation would >>> be to require mappings to be licensed under the GPLv2 or >> later >> and have >>> mapping authors sign the agreement. >>> >>> >>> I understand your position here. I've consulted lawyers about >> this. I'd >>> prefer to not discuss this any further on our public email >> list. >> >> The question of legality isn't my only concern about taking >> mappings >> without explicit consent. I am also concerned about the quality of >> the >> mapping. If mappers have to submit mappings themselves, I don't >> think >> anyone is going to submit a mapping before they feel it is >> complete and >> ready. >> >> On 11/22/2015 02:22 PM, Be wrote: >>> On 11/20/2015 10:53 AM, Sean M. Pappalardo - D.J. Pegasus wrote: >>>> On 11/19/2015 11:06 PM, Be wrote: >>>>> Also, what devices do people want supported? IMO it is a big >> problem >>>>> that Mixxx lacks much support for popular brands that make >> quality >>>>> hardware that is commercially available today. Where is the >> support >>>>> for contemporary Native Instruments, Pioneer, Akai, and DJ >> Tech Tools >>>>> controllers? >>>> >>>> Supporting newer controllers requires either manufacturer >> cooperation >>>> (many of them have their hands tied when they do bundling deals >> with >>>> other DJ software,) or funds to purchase the controllers >> ourselves, >>>> which we definitely don't have because we have no income >> stream. >>> >>> Both of those would be great, but neither are necessary. For >> popular >>> controllers, enough users come by Mixxx interested in a mapping. >> Soon >>> enough one of them has the ability and time to make a mapping. >> These >>> users need to be supported technically and encouraged, which I >> have been >>> doing. >>> >>>>> ~3/4 mappings in Mixxx are for devices that have been >> discontinued. >>>> >>>> That's due to a number of things 1) the market moves so quickly >> that >>>> controllers are discontinued within a year in some cases and 2) >> a >>>> majority of Mixxx users are in situations where second-hand >> controllers >>>> make the most sense for them, so those are what people create >> presets for. >>>> (This latter point isn't a bad thing because people new to >> Mixxx can try >>>> it with whatever controller they already have or can get >> inexpensively.) >>> >>> The market moving quickly is not an excuse for not keeping up. >> We can. >>> As I mentioned above, people want the latest controllers to work >> with Mixxx. >>> >>> I think a majority of Mixxx users are in situations where second- >> hand >>> controllers make the most sense for a few interrelated reasons. >> It's >>> kinda a chicken-and-egg problem. Before I overhauled the wiki >> this >>> summer, it was difficult to tell what Mixxx actually supported, >> which >>> made it confusing and difficult to pick a controller to use with >> Mixxx. >>> So, it's not surprising that many people would get whatever >> controller >>> they could find cheaply and hope it worked. Also, Mixxx has a >> reputation >>> of being just a nice thing to try for beginner DJs without >> having to >>> invest much, so these have generally been the people who came to >> Mixxx. >>> >>> I would like to see Mixxx outgrow this reputation. I would like >> to see >>> new DJs coming to Mixxx and staying with Mixxx. I would like to >> see DJs >>> switching to Mixxx from proprietary DJ programs and sticking >> with Mixxx. >>> This requires fully supporting popular middle and high grade >> controllers >>> like the Traktor Kontrol S4 and Pioneer DDJ-SR and DDJ-SX2. With >> 2.0, >>> Mixxx is getting close to outgrowing that reputation in terms of >>> features. But I think including mappings without any quality >> control >>> will hold it back. >>> >>>>> Write the documentation, and people step up to do the work. >>>> >>>> While good documentation is indeed essential, our experience >> with many >>>> Mixxx users who want to add support for a controller is that >> they are >>>> spooked even by the idea of editing an XML file*, let alone >> working with >>>> JavaScript, despite the extensive documentation on the wiki >> which was >>>> available when the scripting engine was released. >>>> >>>> *So often that one person made a lighthearted joke about it: >>>> http://downloads.mixxx.org/mess/baddudes.gif >>>> >>>> In short, the average Mixxx user is not a developer by any >> stretch and >>>> has no interest in becoming one. While it's fine to have a >>>> developer-friendly work flow (i.e. Github PRs) _available_ for >> preset >>>> contributors, it cannot be required. There are already too many >> required >>>> technical hurdles for non-developer contributors; we certainly >> can't >>>> afford to add another. >>> >>> The XML mapping format is inadequate and any GUI that could be >> designed >>> around it would be too. It may have made sense 8 years ago when >> MIDI >>> controllers designed for DJing were just starting to be made and >> when >>> the M-Audio Xponent and Vestax VCI-100 were decent controllers. >> But now, >>> even cheap controllers like the Mixtrack Pro 3 and Pioneer DDJ- >> SB2 are >>> complex devices designed to have multiple layers of >> functionality (and >>> increasingly the LEDs make use of different colors). >>> >>> There is no good way to support such devices without a fully >> featured >>> programming language -- unless you think Traktor's maze of mouse- >> driven >>> menus or VirtualDJ's hacky scripting language are good >> solutions. I >>> suspect extending the XML mapping format would bring us closer >> to those >>> messes. I think the best way to move forward with mappings is to >> make it >>> easier to use JavaScript well. >>> >>> Being free software and the only digital DJ program for >> GNU/Linux that >>> can do anything more than vinyl control, Mixxx attracts plenty >> of >>> technically-inclined people who could program mappings in >> JavaScript. >>> I'm thinking of people like myself who have programmed a few >> little >>> things here and there, may or may not have any formal training >> in >>> programming, and probably don't know JavaScript well or at all. >> These >>> are generally the people who have been making mappings. As >> evidence, >>> consider that many mappings were previously scattered around the >> web in >>> their own GitHub repository (that wasn't forked from >> mixxxdj/mixxx) or >>> on a personal blog. For this group, learning the basics of git >> is not >>> too much to ask. The mapping documentation should be written for >> this >>> audience. It should go out of the way to explain some basic >> things about >>> JavaScript and good coding practices rather than assuming the >> reader >>> understands the example code with minimal explanation. >>> >>>> >>>> Remember that Mixxx users are our customers and this (like all >>>> user-facing items) is a customer service issue. To that end, >> what the >>>> average user needs most is a GUI preset creation system that >> can map >>>> everything, jog wheels included. (I have plans to make this >> actually >>>> happen even for HID controllers.) They are then free to share >> these with >>>> us any way they are able, be it Github PR, forum post, E-mail >>>> attachment, SD card on a carrier pigeon, etc. >>> >>> As explained above, we shouldn't expect good mappings without >> coding. >>> There is a place for incomplete mappings. That place is the >> forum. But >>> those mappings should not be included in Mixxx. No matter what >>> disclaimers we say, if someone buys a controller and tries a >> mapping >>> included in Mixxx but it doesn't really work, or it works in an >> awkward >>> way, that reflects poorly on Mixxx. >>> >>> On that note, "Community Supported Mappings" has been a >> misleading term. >>> A mapping author continuing to staying involved in the Mixxx >> community >>> and supporting the mapping has been more the exception than the >> rule. >>> Keeping mappers involved is also important for getting input on >> how to >>> improve the mapping system. I don't think requiring mappings to >> go >>> through code review on a GitHub pull request will totally solve >> this >>> issue, but I think it is a step towards keeping mappers engaged. >> Towards >>> that end, I just put a note on the Contributing Mappings wiki >> page >>> encouraging mappers to join the mailing list. >>> >>>> Again, thank you for your time and interest in improving Mixxx. >> We >>>> appreciate the occasional whip-crack to keep the documentation >> up to >>>> stuff. (It's important for fellow developers as well as users!) >>> >>> Thanks for making the only mapping system for DJ software that >> uses an >>> actual programming language. :) >>> >>> ----------------------------------------------------------------- >> ------------- >>> _______________________________________________ >>> Get Mixxx, the #1 Free MP3 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 > -----BEGIN PGP SIGNATURE----- > Charset: UTF8 > Note: This signature can be verified at https://www.hushtools.com/verify > Version: Hush 3.0 > > wpwEAQMCAAYFAlZSYAgACgkQzo/Gj4mkNMyJygP+NWKN92Ym9W523i8MLz6ksnj996gj > Uz16jI6aPZ/6CT5/m9tXE2tZBniQN2PeMpUd090Gg950rttnflV2Hi4TeNmpQ8HM3OGx > R9b4SGU6yUO4Tu6hkYmzX5VaMW3lKt8etkia2vLc4n5hISd2HGkoJPnpYnijbYVFpan3 > 44YxAAw= > =uDxP > -----END PGP SIGNATURE----- > ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741551&iu=/4140 _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
