VCI-100mkII: rewrite with new loop, effect and navigation CO#1293
VCI-100mkII: rewrite with new loop, effect and navigation CO#1293sohet wants to merge 24 commits intomixxxdj:masterfrom
Conversation
There was a problem hiding this comment.
Thanks for continuing to take care of this old controller. :) The use of the new loop, beatjump, and effects controls seems odd in a handful of ways as detailed in comments in the code.
I suggest mapping the bottom row of buttons like the Pioneer DDJ-SB2 mapping. That would require moving or removing the functionality of button 26. I mapped keylock on my first controller mapping but I found that I never actually used it while mixing; I just keep keylock on. Is it really useful to you to have this mapped on your controller? Similarly, the waveform zoom levels are not something I want to adjust while mixing; I have them set how I like then leave them. If you want to keep keylock on the controller, you could move it to shift + button 25 if you remove the waveform zooming.
I have some ideas about how to adjust the effects mapping for this controller. You could use buttons 1 & 2 to switch the top row of buttons (currently only used for hotcues) between different modes. One mode could control the effect enable switches and another could allow choosing the focused effect. You could get the buttons back to hotcue mode by pressing button 1 or 2 again (depending on which was last pressed to activate a layer).
| if (n) { | ||
| VCI102.parameter(ch, value, VCI102.slot(group, n), "parameter4"); | ||
| } else { | ||
| VCI102.meta(ch, value, group, "super1"); |
There was a problem hiding this comment.
Why did you change this from "mix" (dry/wet)? The superknob is redundant with access to each metaknob.
There was a problem hiding this comment.
Since "send" is added to effects that need it (as reverb) by you, I feel dry/wet mix is not necessary any more.
There was a problem hiding this comment.
The dry/wet knob is necessary for controlling the whole chain together. You may want to keep the metaknob of one effect like Filter or Reverb at one position while using the chain and manipulate the metaknobs of other effects. Without the dry/wet knob, you'd have to turn the metaknobs of every effect when mixing the effects in and out, but that does not work well when you want to leave one or more metaknobs in the same position. It also doesn't work well when you are using all 3 effects in a chain, unless you happen to have 3 hands.
There was a problem hiding this comment.
You may want to keep the metaknob of one effect like Filter or Reverb at one position while using the chain and manipulate the metaknobs of other effects. Without the dry/wet knob, you'd have to turn the metaknobs of every effect when mixing the effects in and out, but that does not work well when you want to leave one or more metaknobs in the same position.
For this purpose, we have multiple effect units. For example, using one effect unit for variable effects and another unit for constant effects.
It also doesn't work well when you are using all 3 effects in a chain, unless you happen to have 3 hands.
"super1" can also be used for changing 3 effects simultaneously.
I think "mix" and "super1" have pros and cons in controlling the whole effect unit. "mix" can control it with ease and acceptable sound quality, but "super1" can control it with fine adjustments (by changing links from prameters) and better sound quality (mixing wet and dry may degrade the sound).
| if (engine.getValue(group, "loop_enabled")) { | ||
| engine.setValue(group, "reloop_toggle", 1); | ||
| // restore beatloop_size | ||
| engine.setValue(group, "beatloop_size", VCI102.loopSize[ch]); |
There was a problem hiding this comment.
Why are you storing this in a script variable? Mixxx keeps track of this.
There was a problem hiding this comment.
I don't want to change beatloop_size (used as default value) while temporary changing loop size on loop. So I save the size at the beginning and restore the size on exit. But now I find "loop_scale" control for temporary change, so rewrite the script.
There was a problem hiding this comment.
loop_scale is not intended for use with beatloops. It only takes into consideration the size of the loop, not the beat positions, so it will create off beat loops with non constant beatgrids.
There was a problem hiding this comment.
If you would like to keep this nonstandard behavior, then make it easy for users to change with a boolean variable at the top of the script file. IMO it should default to false.
| ["loop_enabled", "play", "reverse"].forEach(function(key) { | ||
| engine.connectControl(deck, key, VCI102.slip); | ||
| }); | ||
| engine.connectControl(deck, "beatloop_size", beatjumpSize); |
There was a problem hiding this comment.
Why are you tying these together? They are intentionally separate values. Even if there are not enough controls to manipulate beatjump_size from the controller, users should still be able to set it via mouse or keyboard.
There was a problem hiding this comment.
Ok, separate current loop size, beatloop_size and beatjump_size.
| engine.setValue(group, "beatloop_size", VCI102.loopSize[ch]); | ||
| } else { | ||
| VCI102.loopSize[ch] = engine.getValue(group, "beatloop_size"); | ||
| engine.setValue(group, "beatloop_activate", 1); |
There was a problem hiding this comment.
beatloop_activate should be reset to 0 or the skin button for it will stay lit.
There was a problem hiding this comment.
Add engine.setValue(group, "beatloop_activate", 0). Also add engine.setValue(group, "loop_out", 1) for future possible changes.
There was a problem hiding this comment.
Do not add engine.setValue(group, "loop_out", 1) when releasing this button. When a loop is active and loop_out is 1, the loop out point will be continuously adjusted to the play position until loop_out is reset to 0. This is is meant so you can hold down loop_in/loop_out buttons while moving a jog wheel to finely adjust manual loops.
| var key, n = engine.getValue(group, "focused_effect"); | ||
| if (n) { | ||
| group = VCI102.slot(group, n); | ||
| key = "prev_effect"; |
There was a problem hiding this comment.
prev/next_chain aren't very useful at the moment. In the future (after Mixxx 2.1) I think they'll be revived to cycle through user defined chain presets.
There was a problem hiding this comment.
I think effect chain and super knob have been central ideas of Mixxx effect system. Linking parameters of effects various way to one knob is like making an complicated instrument on synthesizer, and controlling such complicated effects by one knob is of great fun. I miss user defined chain presets and want to remain effect chain and super knob till then.
| VCI102.fxKnob[ch] = group.slice(0, -1) + "_Effect1]"; | ||
| VCI102.parameter = function(ch, value, group, key) { | ||
| if (VCI102.shift[ch % 2]) { | ||
| // link to meta, inverse variants -> none -> direct variants |
There was a problem hiding this comment.
It doesn't really hurt to have this, but I don't think there's a need to manipulate metaknob linking from a controller. That's meant to be set-and-forget. Mixxx now saves and restores changes the state of metaknob linkings on shutdown/startup.
There was a problem hiding this comment.
I know some people using compact controllers like this for preparing tracks at home. For those (including me) mapping editing controls (link to meta, waveform zoom, beats translate, ...) is useful.
|
It is easier to review changes if you split them into smaller commits. The easiest way for you to do this is to work on one change at a time then commit it. Unlike older version control systems, Git works offline, so you can make multiple commits on your computer before pushing them to GitHub for a pull request. If you have modified your code to work on a few unrelated things, you can pick individual changes to stage for a commit, then pick the other changes for the next commit. Using a graphical Git client helps a lot for that. Personally I like Git Cola, but there are others available that you may prefer. |
| VCI102.reloop = function(ch, midino, value, status, group) { | ||
| if (value) { | ||
| if (engine.getValue(group, "loop_enabled")) { | ||
| engine.setValue(group, "loop_out", 1); |
There was a problem hiding this comment.
I don't understand why this button is using loop_out. It is unrelated to reloop_toggle. reloop_toggle should be accessible when loops are disabled.
There was a problem hiding this comment.
If you want to use a single button for both beatloop_activate and reloop_toggle, I suggest mapping it like I have mapped pushing the loop encoder on the Hercules P32:
- Push with no loop active: beatloop_activate
- Push with loop active: reloop_toggle
- Shift + push with no loop active: reloop_toggle
- Shift + push with loop active: reloop_andstop
There was a problem hiding this comment.
This controller sends different messages depending on the shift button. I map VCI102.loop (without shift) and VCI102.reloop (with shift) to the same button 27. So total behavior is,
- Push with no loop active: beatloop_activate
- Push with loop active: reloop_toggle
- Shift + push with no loop active: reloop_toggle
- Shift + push with loop active: loop_out
Of course I have realized that "loop_out" is intended to be used with "loop_in" for manual loop, but it can be used with "beatloop_activate" (or other beatloop starters) for manual loop. For example,
- Begin beatloop by "beatloop_activate" with size 8
- After 5 beats, activate-deactivate "loop_out"
- Continue to loop with size 5
Though it is not intended use of "loop_out", but works fine at least from Mixxx 1.11 till now. This use of "loop_out" can add manual loop to usual beatloop mapping with minimal cost, I think.
| engine.setValue(group, "beatjump_size", | ||
| engine.getValue(group, "beatjump_size") * scale); | ||
| } else if (engine.getValue(group, "loop_enabled")) { | ||
| engine.setValue(group, "loop_scale", scale); |
There was a problem hiding this comment.
loop_scale is only for manual loops set with loop_in and loop_out which are not mapped on this controller.
a435b87 to
563d7c8
Compare
|
Drastic change of the layout.
https://www.mixxx.org/wiki/doku.php/vestax_vci-100mkii#mapping_for_mixxx_development |
|
FYI, I haven't forgotten about this, but I'm prioritizing getting things together for 2.1 beta. Controller mappings can be merged during the beta period after feature freeze. |
10678b7 to
fed20b1
Compare
68a406d to
0c6eed1
Compare
|
In case you missed it, we've decided to release Mixxx 2.1 beta on 2017-12-22. I'll get back to reviewing controller mappings to be included in the 2.1 release after the beta is released. |
|
I will get to reviewing this soon, but for now I will be taking a break from development and code review for a few days. |
Be-ing
left a comment
There was a problem hiding this comment.
Thanks for updating this. Sorry for the delay reviewing it. Overall it looks good. I made a few comments below. Will you have time to address those comments in the next few days before the 2.1 release and rebase this on the 2.1 branch? If not, we can merge it as it is.
| VCI102.parameter(ch, VCI102.slot(group, n), "parameter3", value); | ||
| } else { | ||
| VCI102.set(VCI102.slot(group, 3), "meta", value); | ||
| } |
There was a problem hiding this comment.
These parameter functions duplicate code. You could have one function and get the parameter number from the MIDI note number. Alternatively, you could create 3 different functions with a for loop.
| value -= 27; | ||
| } else if (value > 50) { | ||
| value = 50; | ||
| } |
There was a problem hiding this comment.
I'm confused what this is doing. Could you explain?
| if (value) { | ||
| if (engine.getValue(group, "loop_enabled")) { | ||
| engine.setValue(group, "loop_out", 1); | ||
| engine.setValue(group, "loop_out", 0); |
There was a problem hiding this comment.
Having loop_out mapped without loop_in seems strange. Maybe you could use reloop_andstop here instead? If you prefer it how it is that is okay though.
There was a problem hiding this comment.
loop_out should be set to 1 on button press and set to 0 on button release. That way, when the user holds the button down, the loop out point will move with the play position until they release the button. This allows for setting a new loop out point outside of a loop that is active.
There was a problem hiding this comment.
I have just now realized the exact function of "loop_out". Then beginning loop size is irrelevant to manual loop! I will change the code.
There was a problem hiding this comment.
This ability to hold down loop_out buttons is new in 2.1 (it was added in #1187).
| } | ||
| }; | ||
|
|
||
| VCI102.reloop = function(ch, midino, value, status, group) { |
There was a problem hiding this comment.
I got quite confused figuring out how this is working. Could you add a comment explaining that this is the loop button with shift?
There was a problem hiding this comment.
Some old controllers including VCI-100mkII send messages with different midi numbers depending on shift. So not only VCI102.loop(without shift)-VCI102.reloop(with shift), but also other controls, play-reverse, sync_enabled-quantize, ... can be mapped to same buttons without scripts. You can see them in "Vestax VCI-100MKII.midi.xml".
|
Thank you for reviewing. I don't want to change codes at this moment, so only add some comments. How to rebase it on the 2.1 branch? |
|
If you haven't done so already, add the upstream repository as a remote: then |
|
LGTM, thank you! @daschuer, I tried rebasing this branch on 2.1 but there are some conflicts. Could you take care of that? I'm not super familiar with resolving rebasing conflicts and don't want to mess up the Git history somehow. |
|
Sometimes I rebased this branch to Master during this long Pull. And now when I try to rebase it to 2.1, following warnings are shown. How can I resolve it? First, rewinding head to replay your work on top of it... When you have resolved this problem, run "git rebase --continue". |
|
I rebased this on 2.1 and pushed it directly to that branch. I had to use |
https://www.mixxx.org/wiki/doku.php/vestax_vci-100mkii#mapping_for_mixxx_development
Great thanks to Be and Ronso for preparing the new environment!