This is turning into a nice proposal :) Some comments and questions for this new draft:
1. Cue colors: How to represent these? HTML/CSS style RGB codes? Integers mapped to specific colors? I think it would make sense to use RGB codes in the backend for maximum flexibility in the future but only present the options for a handful of specific colors on the front end. By default, I think it would be good to have each type of cue correspond to a different color but let the user edit the color manually if they would like. 2. There are use cases for manually typing the time of a hotcue in edit mode, so an arrow icon in the time field in edit mode would be good. For example, a user may be very familiar with a track from listening to it in other music players and have a specific time point memorized. Another use case would be that a user has a cue point saved in another program, such as Amarok or Traktor, that Mixxx doesn't (yet) have a way to import cue points from, but wants to put them in exactly the same spots. It would be good to support creating a new hotcue in an empty hotcue slot this way. This could also alleviate the issue of moving hotcues that are close together by dragging and dropping on the waveform. 3. The up/down arrows for moving hotcues in the list would work, but could be a bit cumbersome. It would be good to also support dragging and dropping, but that could wait till after GSoC. 4. I think cues should be able to be dragged and dropped on the overview as well as the detail waveform. Perhaps this should only work while the cue list is in edit mode to prevent accidental moving. Dragging & dropping on the overview waveform would be particularly helpful for section cues. 5. To make sure the complementary features at the end aren't forgotten, it would be good to make Launchpad bugs for the ideas that aren't in Launchpad already. 6. Regarding numbering of cues on the waveform, perhaps this could dynamically change with the filtering of the cue list. If the list shows all cues, number the cues on the waveform sequentially. If the list is filtered (with any type of filter selected), number cues on the waveform sequentially by type. On 03/22/2016 06:19 AM, Ferran Pujol Camins wrote: > Hello, I've reworked the specification to include some of your > considerations. What's new: > > -I've written the cue point list section (including mock-ups). > -The editing of cue points is now integrated in the main window. > -Extended explanation of why I exclude support for cue points not > assigned to any hot cue. > -Added explanation of why I leave a cue list filtering feature to a "2.0 > phase" of the project. > -Minor improvements in the document. > > I appreciate your feedback. > > Best regards, Ferran. > > 2016-03-17 9:53 GMT+01:00 Ferran Pujol Camins > <ferranpujolcam...@gmail.com <mailto:ferranpujolcam...@gmail.com>>: > > You made some interesting observations, so long mail :) : > > > 2016-03-16 21:28 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org > <mailto:dasch...@mixxx.org>>: > > * Recall loop cues: > IMHO DJSally jump mode requires, that the jump happens on cue > button press and not after release. > If you distinguish, the activate mode by a long press, you can't > jump mediately, which is probably required to mix beat sync by > ear. Do you think we can introduce a new cue type to distinguish > these types of loops? > > > That's a good point I didn't think about. Let's see: > I just realize that the reloop button in Mixxx actually does the > "jump&reloop" mode rather than "only reloop" mode. So first of all > I'll need to add a new CO for it. Binding it to the right click is > the obvious approach, but we need this to be consistent with what we > do with loop hot cues (which won't be right click because it is > already used to clear the hot cue). > > Similarly, for the hot cues we'll need two CO: "hotcue_X_activate" > and a new "hotcue_X_reloop" (for cue points that are a time point > rather than a time range both CO will do the same). > > Solution 1 is to use a modifier key like control or shift to choose > which trigger mode to use. In fact this is the natural approach for > controllers. But currently we don't use keyboard modifiers to alter > mouse behaviour in Mixxx, don't we? How does this sounds to you? > > Solution 2 is to have an additional button (that appears only when > the hot cue is assigned to a loop) that allows to activate the loop > without jumping to it. This is the approach Serato takes: > > A similar cue list widget is in the proposal but I haven't got time > to write the corresponding section yet. > > The problem with the second approach is that it doesn't fit with our > current cue point buttons. However, what I could do is: implement > only the jump&loop trigger mode first, and once the cue list is > done, implement the other mode. It seems reasonable to me. > > I don't really like the idea of two distinct cue types for this. I > feel some users would end up with to identical loops just to be able > to choose how to trigger them. > > > > > > 2016-03-16 21:28 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org > <mailto:dasch...@mixxx.org>>: > > * Section cues: We have already "sections" defined by the > detected keys I wonder how these key sections compares to the > cue section. Maybe we can use the key infos to help the Dj > setting up the cue sections. > > > How are key sections going to be displayed? Maybe they could be > modelled with a new cue type called "key zone" (or whatever name we > find appropriate). > > Key marks are similar to beatgrid: is information that can be > empirically determined. On the other hand, cue sections are more a > subjective thing: sure tracks somehow have a determined structure > (intro, break....outr), but different users might prefer to focus on > different track features. For example, a user might prefer to use > section cues to simply mark where the kick is on or off in the > track, while another one might prefer to use section cues to reflect > where the break, intro, outro, etc are. > > For this reason, the way I understand it, this sections will be > edited in a different tab in track preferences (the same way > beatgrid is). We can visualize them in the cue points tab waveform > (in a similar way we do with beatgrid) to help user make educated > decisions about the section cues he/she wants to create. > > So, the way I see it is: key sections would fit well with my > proposal, but since it is not yet a finished feature, I would prefer > to leave it out of my proposal. > > > > > > 2016-03-16 21:28 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org > <mailto:dasch...@mixxx.org>>: > > * 2.3.2 Bottom section > I am not sure if it is a good idea to display all cue types in a > common list. This surely works wit a hand full of cues but might > getting hard with a lot of them. Especially the section cues > should be in a separate list. > How about a simple type filter. > > > Totally agree. Maybe I'm going to schedule this as a 2.0 development > phase for the track preferences pane, but definitely going to > include this in my proposal. > > > > > > 2016-03-16 21:28 GMT+01:00 Daniel Schürmann <dasch...@mixxx.org > <mailto:dasch...@mixxx.org>>: > > * Will it be possible to change a cue type live? For example a > break section can be used as a jump or as a loop. Is it a valid > use case or just a stupid idea? > > Not stupid idea :). I think the general case of using a cue as a > different type from which it was originally created adds unnecessary > complexity. However, you can always trigger a loop cue and > immediately exit the loop. And conversely, you can always jump to a > simple cue and immediately set a loop. You could even set a loop cue > and a simple cue to the same place if you really feel it would be > better to you. > > > > > > > > 2016-03-16 22:24 GMT+01:00 Be <b...@gmx.com <mailto:b...@gmx.com>>: > > My biggest concern is requiring another window to be opened for the > fully featured cue point editor. I forsee a few issues with > this. First, > it would require duplicating a lot of design and functionality > from the > main window/skins. It would also present an issue for controller > mappings as Daniel pointed out. Also, I think the workflow would be > awkward for editing cues while playing. I think it would be > better to > implement the GUI features as a section of skins that could be > toggled > between showing and hidden. If all features can be intuitively > controlled from the main window, I think the cue tab in the Track > Properties window would be redundant and could be removed. > > > I can see your point. My idea was to provide basic cue point editing > capabilities to the main window and delegate a complete editor to > the preferences window, because you are definitely not going to set > your section cues during a live set for example, it is something you > want to do will preparing your tracks. > > However, I can see your point and I may like it. I'm going to > prepare a mock-up for how this could be fitted in Deere (Latenight > should be about the same). My biggest concern here is the little > sister: Shade. Can this all be fitted into Shade? > > > > 2016-03-16 22:24 GMT+01:00 Be <b...@gmx.com <mailto:b...@gmx.com>>: > > Is there anything that should be done for "the" cue point? How > does it > fit into this expanded model of cue points? > > > From a quick analysis: not really. Am I missing something? > > > > > 2016-03-16 22:24 GMT+01:00 Be <b...@gmx.com <mailto:b...@gmx.com>>: > > A feature that would compliment what you've proposed and be > helpful for > using controllers would be to create control objects that > sequentially > represent a specific type of cue. For example, setting > loop_cue_1 to 1 > would enable whatever the first loop cue is, regardless of what > number > hotcue it is assigned or what number cue it is in the database. This > would allow controller mappings to have different layers for their > pads/buttons for using different types of cues. All types of > cues should > be able to be mixed and matched in one big list as well. This would > allow users to arrange different types of cues however they want > in a > way that makes sense for their use and on their controller. For > example, > a user could set cue 1 to a simple hotcue for a point and cue 2 to a > loop cue starting at that same point, but the user might not > ever want a > loop at cue 3. The user could either press pad 1 or 2 depending on > whether they wanted to loop without having to switch to a different > layer of the mapping. > > > That's something interesting, but it needs think through. How are > you going to render a a loop cue in the waveform? It is going to be > cue point nº 3 but maybe loop nº 1. Let me add this to the list of > things to do next, it's a list of cool things to implement but that > are second priority (sort of cue points revamp 2.0 material). > > > > 2016-03-16 22:24 GMT+01:00 Be <b...@gmx.com <mailto:b...@gmx.com>>: > > Another use case I thought of for these automatically activating > type of > loops would be in sample decks. If the load cue is set at the > same point > as an automatically activating loop cue, the user would only have to > press play on the sampler to utilize a loop without having to > use one of > the main decks or cut that loop out into another file. > > > Maybe we could remove the cue type "Load", and rather add an > exclusive flag to the cue model that indicates that this is the cue > point to be used as Load cue. This way the load cue can be a simple > cue or a loop. > > > ------------------------------------------------------------------------------ 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=278785351&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
