-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It does look exciting.
However, if that feature cannot "autogenerate" crates according to artist (or genre or BPM or whatever is preferred) it 100% *does not* fulfill the same purpose. I have over a thousand artists in my collection. Making a Crate for each of them would literally take an entire day or more, and frankly would be a simply excruciating exercise. And what happens then if my database gets lost or corrupted? Ack! >_<;! I'm sure most other DJs have a similar number of tracks/artists. There has to be a way Mixxx can naturally and automatically visualize tracks as directories by artist (or other tag). Unless I'm missing an aspect of pull 726, crates cannot fulfill this requirement. Thanks for your patience, RAWRR On Tue, 05 Apr 2016 07:25:31 +0100 "Daniel Schürmann" <dasch...@mixxx.org> wrote: >Hi, > >please Note, that there is an unfinished "Multilevel crates" >branch the >looks promising: >https://github.com/mixxxdj/mixxx/pull/726 >I like to see it in Mixxx and it should fit to Joan's proposal. > >Kind regards, > >Daniel > >2016-04-05 0:42 GMT+02:00 <re-cy...@hushmail.com>: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >> On Mon, 04 Apr 2016 16:35:55 -0100 "Joan Marcè i Igual" >> <j.marce.ig...@gmail.com> wrote: >> >Hi RAWRR, >> > >> >Thank you for your suggestions. >> > >> >When you talk about the Browse PC view you refer to porting the >> >the >> >advantage of using folders elsewhere in the library. Do you >mean >> >by this >> >adding also the folders feature to the current library and >> >allowing the >> >user to >> >set the tracks on "virtual" folders only existing in Mixxx? Do >you >> >think >> >it can be a bit confusing for the final user having also the >> >Clementine look >> >like sort (v.0.1.2)? >> > >> >> Yes I agree confusion is possible, or even likely if the UI is >not >> arranged just right. I think you might be uncertain if I mean >> adding a direct view of local filesystem to your v0.1.2 section. >> No, that isn't my suggestion. It seems like you may have a kind >of >> virtual folders already suggested and local view and virtual >view >> are not both necessary in the same section. >> >> So there are two fundamental UI perspectives here. one is the >idea >> of sorting, the other is the idea of containing, and they are >not >> the same workflow. >> >> In the case of sorting we presumably have a potentially enormous >> list, and the current "sort by column" allows the user to >"clump" >> groups of tracks according to categories. >> >> In the case of containing, more or less that means folders; they >> can be called crates or playlists or virtual folders, it doesn't >> change the fact that they function in the Mixxx UI as a kind of >> directory. So these directories can be virtual (crates or >> playlists, or autogenerated according to categories, whatever) >or >> they can be a direct view of existing structure in a user's >local >> filesystem, but they are ways to isolate tracks in a container >and >> thereby abbreviate the list a DJ must scroll through to grab >what >> they need. >> >> I'm a little confused at v0.1.2 by the wording and accompanying >> image: "the view has two modelers one for the menu (Library, >> Autodj, iTunes...) and other for the songs" - I can't see in the >> diagram where "menu" is. But what I do see seems to suggest you >> already have an implementation of virtual folders envisioned >(re: >> above "autogenerated according to categories"). >> >> As long as we have a tree of folders/crates/directories - visual >> containers, in other words - I think that works, so long as each >of >> these containers have all the columns and options the current >main >> Library view has, meaning easter egg, Preview, Year, BPM, etc.. >> >> Currently Browse View is the only View that allows in Mixxx any >> visualization of tracks by "container", and this Browse View >lacks >> some of main Library's features. This is the problem that >inspired >> the two bugs cited. >> >> > >> >I like your "lasso (rubber band) select in library" and it can >be >> >very >> >useful also, >> >the scrollbars "midi-scriptable" will be very useful but I >think >> >that it's >> >beyond this project. >> > >> >> So rubberband select is a yes? If so, great! I understand re: >> scrollbars. >> >> > >> >I've been playing a bit with skins and I think that splitting >the >> >library >> >view into a set of >> >widgets can give the skin designer a lot of freedom. Currently >the >> >skin >> >supports tags >> >for *LibrarySidebar*, *SearchBox*, *CoverArt*, and the >*Library* >> >itself, in >> >my opinion the >> >State / Progress / Controls widget can also be separated (in a >> >*LibraryControls* tag >> >for example). To allow the skin designer to play with this we >can >> >separate >> >the >> >*LibrarySidebar* tag in different tags: *LibrarySidebarButtons* >> >and >> >*LibrarySidebarMenu*, >> >the first one will contain the main buttons (Library, Notes, >> >AutoDJ) and >> >the second one >> >will contain the sub-menus for every item (Library Tree >(legacy), >> >Crates, >> >Playlists >> >for the Library item). >> > >> >> I mainly want to see the thought of others on these items. >> >> > >> >I like your colored line idea maybe we can allow the skin >designer >> >to set a >> >border color >> >when creating widget groups. >> > >> >> Sounds good. Basically I mean either a colored border that >> surrounds both a tab and its children, or a colored line that >leads >> from a tab to its children. >> >> > >> >What do you think about times? Will be enough time to do the >> >rubber band >> >select? >> > >> >> I do feel that at a minimum your new code should support this >> feature's future place, because I'm not sure how well the >current >> Library code does. But I'd hate to sabotage your schedule with >my >> old feature request. I guess this is another item I hope others >> will vote on. >> >> > >> >What others think? >> > >> >I've added all of this to this bug thread ( >> >https://bugs.launchpad.net/mixxx/+bug/986704) >> > >> >On Mon, 4 Apr 2016 at 09:45 <re-cy...@hushmail.com> wrote: >> > >> >> -----BEGIN PGP SIGNED MESSAGE----- >> >> Hash: SHA1 >> >> >> >> I keep track of my own bugs and those I subscribe to best, so >> >here >> >> are a few relevant ones juxtaposed with observations and >> >> suggestions: >> >> >> >> - - Library view v0.1.2 - >> >> >> >> This more or less offers a solution to "request filter system >in >> >> browser on i.e. genre tag" >> >> (https://bugs.launchpad.net/mixxx/+bug/671630). Great! Your >> >designs >> >> seem more or less satisfactory. >> >> >> >> - - Browse PC view v.0.3 - >> >> >> >> My concerns are: >> >> >> >> "option to subdivide Library tracks into virtual folders" >> >> (https://bugs.launchpad.net/mixxx/+bug/1228789) >> >> >> >> and "Add Preview column in Browse, and External Libraries >views" >> >> (https://bugs.launchpad.net/mixxx/+bug/1160525) >> >> >> >> The arguments are provided at the bugs, but a synopsis is >that I >> >> strongly feel that large collections are well served by being >> >> sorted into folders. My preference is to create folders by >> >artist, >> >> but others might prefer genre or something else. Browse view >> >> currently allows a Mixxx user to browse their files by >whatever >> >> structure they have crafted in their local filesystem. >> >> >> >> I'm all for relegating the Browse view to an impromptu >discovery >> >> tool, but only if its current advantage of using folders is >> >ported >> >> elsewhere in the Library. >> >> >> >> Two more items: >> >> >> >> I'd like to ask what you think of "lasso (rubber band) select >in >> >> library" (https://bugs.launchpad.net/mixxx/+bug/1093598). For >> >> adding swaths of tracks to either AutoDJ, Analyze, Playlists, >or >> >> Crates, rubberband select can't be beat, and is far and away >> >> superior to ctrl+clicking groups of tracks. >> >> >> >> The other is "all scrollbars midi-scriptable" >> >> (https://bugs.launchpad.net/mixxx/+bug/1463677). Many >> >controllers >> >> have a browse rotary dial with push toggle, for browsing >> >libraries. >> >> It only works currently in Mixxx if the user selects a track >> >> explicitly, at which point the browse knob can do some >> >scrolling. >> >> It takes way too many steps to get to that function and >making >> >the >> >> scrollbars scriptable would clean this up considerably. >> >> >> >> Lastly, I've looked over the entire proposal with an eye >toward >> >> eventual touch features, and really the only thing I can find >> >that >> >> might cause problems are Library view v0.2.0 (v0.1.1), >wherein >> >> right-clicking is discussed, an awkward requirement in touch >> >> interfaces, but this is a larger issue throughout the project >> >and >> >> in this case there are alternative routes to the same result >so >> >it >> >> should be ok. Other than this nitpick, I'm a little worried >> >about >> >> treeview at all for touch devices as treeviews typically >favor >> >> small (read: not finger size) controls for collapsing and >> >expanding >> >> the tree. This again is a problem which already exists (if it >> >can >> >> be agreed it is a problem at all) and not something Joan's >> >proposal >> >> introduces. Still, it ears mentioning that facility which >relies >> >on >> >> treeview probably won't work elegantly for eventual touch >> >workflow. >> >> >> >> The only aesthetic complaint I have is that subdividing the >> >Library >> >> into too many sections starts to look like some kind of >fractal, >> >> with smaller and smaller nested fields; it can devolve into a >> >soup >> >> of confusing rectangles. There needs to be a way that the >> >hierarchy >> >> of parents is unmistakable, in other words, what object on >the >> >left >> >> is responsible for any given rectangle on the right. Perhaps >a >> >> color trace (a colored line) or shared highlight color, >flowing >> >> from a tab to its boxes? >> >> >> >> All in all, it looks like a solid apprehension of our needs, >> >with >> >> only a few loose ends. Thanks for the effort and vision, >Joan! >> >> >> >> RAWRR >> >> >> >> >> >> On Sun, 03 Apr 2016 06:59:12 -0100 "Daniel Schürmann" >> >> <dasch...@mixxx.org> wrote: >> >> >Hi skin artists, >> >> > >> >> >IMHO Joan's proposals, will work good together with various >> >future >> >> >Mixxx >> >> >features. >> >> >But how about the beauty? >> >> > >> >> >Are there special demands, he has to consider to work >smoothly >> >> >with all >> >> >sorts of skins and design aspects? >> >> > >> >> >Which part might become an independent widget? >> >> > >> >> >If Mixxx will have a touch or a radio skin, will it still >work? >> >> > >> >> >Does anyone have a cool idea to make the library look >modern? >> >> > >> >> >Thank you for comments. >> >> > >> >> >Kind regards, Daniel >> >> >Am 02.04.2016 6:35 nachm. schrieb "Joan Marcè i Igual" < >> >> >j.marce.ig...@gmail.com>: >> >> > >> >> >> Hello, >> >> >> I am Joan and I am currently at my third year of >engineering >> >in >> >> >Computer >> >> >> Science and Mechanical Engineering at UPC, Barcelona. >> >> >> I applied for GSoC under Mixxx for a Library Layout >Redesign. >> >> >> The idea is to change the current Qt TreeView (at the left >of >> >> >the library) >> >> >> to buttons at the left allowing more space in the view, >> >change >> >> >the playlist >> >> >> view, change the current library view and (if there's >enough >> >> >time) add a >> >> >> Browse PC view where the user can select songs directly >from >> >a >> >> >PC folder. >> >> >> The project will split developed in different releases >with a >> >> >new release >> >> >> every two weeks. >> >> >> You can see all the info in the proposal document ( >> >> >> >> >> >> >>>https://docs.google.com/document/d/1HaZ5s7PKmE73LacEGbxRJy9LIKi0Z >F >> >b >> >> >Z-emdSQ1m68o/edit?usp=sharing). >> >> >> Also I include the mock-up of the proposed redesign. >> >> >> >> >> >> I will be waiting your feedback. >> >> >> >> >> >> Regards, >> >> >> Joan Marce >> >> >> >> >> >> >> >> >> ----------------------------------------------------------- >--- >> >--- >> >> >------------- >> >> >> Transform Data into Opportunity. >> >> >> Accelerate data analysis in your applications with >> >> >> Intel Data Analytics Acceleration Library. >> >> >> Click to learn more. >> >> >> >> >>http://pubads.g.doubleclick.net/gampad/clk?id=278785471&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 >> >> >> >> >> -----BEGIN PGP SIGNATURE----- >> >> Charset: UTF8 >> >> Note: This signature can be verified at >> >https://www.hushtools.com/verify >> >> Version: Hush 3.0 >> >> >> >> >> >>wpwEAQMCAAYFAlcCG4EACgkQzo/Gj4mkNMytPwP/dwbpvJl6/xBOxB1husgfbviGW3 >I >> >D >> >> >> >>4Ie2HSwQkqtSCi+cgAs46Da6OxKKrGF7lj9Nfs7Wq9X4jyldfj3bVc/zgW4H4HEtJc >z >> >C >> >> >> >>2rflnObDnSiGRI83kjBiwMH59fbGOYZ2mDbA+4CLfbvnmiJGwydVUXmVQHRThSvx/c >W >> >G >> >> Dt8Vg/c= >> >> =zYTu >> >> -----END PGP SIGNATURE----- >> >> >> >> >> -----BEGIN PGP SIGNATURE----- >> Charset: UTF8 >> Note: This signature can be verified at >https://www.hushtools.com/verify >> Version: Hush 3.0 >> >> >wpwEAQMCAAYFAlcC7fMACgkQzo/Gj4mkNMxDMAP+KWnScGQQlTGL0xk6GcI3N3QJ9wM >u >> >Y4JWw1hnDjrZSRmf4HWRmjuDgtPw4vZB7cRLL4mgAxtC+N1qMwuzNjybmnJ5u33g3Ms >J >> >bSRo+5TeDjRXUEyyvX5R/7nSX5/polBZyjdsYbdx5/aAVCDsHLk1XxL7cMoT4yCywLY >0 >> jKVJDjk= >> =carB >> -----END PGP SIGNATURE----- >> >> -----BEGIN PGP SIGNATURE----- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wpwEAQMCAAYFAlcEDgIACgkQzo/Gj4mkNMwGQgP/dl2yscTCxWF+PMwn/KYDwHdPAN8Y yw66mJ9n26a64vDK2WpE9WLyrzwgl+77cMAjCFXh+V1jv+AMyGxmb0rEfDzp9//+H+j2 2xLDn4rXO8CBHcl62Z0Sqr2wBV8xJilpd6lZ9cySO3bJGTWqfj64wjy9yR8VPv5mnPEw svw+5Ko= =u85Y -----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
