Another idea: the status of the cue list edit mode could be a CO that is accessible by controller scripts. Although I think in most cases it would be easiest to do most editing of cue points with a mouse, some users may want to do that with a controller.
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
