> Hi Jim, > Hi
> Sean and I were chatting on IRC and we are thinking about putting the > XML "group" param into scripting for Mixxx 1.8 (1.7 is in feature > freeze)... so that will mean there will be a new 'group' parameter with > "[ChannelN]" in it. > Ok. While we're changing stuff like that would [DeckN] make more sense than [ChannelN] ? > That being the case, I've renamed my use of 'channel' to 'group' so when > the parameter is introduced we can just remove the group = getGroup > assignment ... you can use the following to update your script file. > Yes, good plan. > sed -e "s/channel/group/g" -e "s/function (group/function (channel/g" -e > "s/Channel/Group/g" -e "s/\[Group/\[Channel/g" > Hercules-DJ-Console-Mk2-scripts.js > new.js # make the change > wdiff Hercules-DJ-Console-Mk2-scripts.js new.js | colordiff | less -R # > review using word diff and colordiff > > If it looks good then just mv new.js to Hercules-DJ-Console-Mk2-scripts.js > Done that. > Cheers, > > -G > __ > --- == __/ t.O ==-- > http://stacktrace.org/ > > > On Mon, May 18, 2009 at 11:49 AM, Garth Dahlstrom <[email protected] > <mailto:[email protected]>> wrote: > > > On Mon, May 18, 2009 at 6:21 AM, James Evans <[email protected] > <mailto:[email protected]>> wrote: > > The currently enabled behaviour for the jog is scratchMode > == true, scratchMode == false just passes through to > "[ChannelN] jog" (which sounds the same as r2415), feel free > to flip it back to false to get the normal behaviour back. > You'll have to go into the midi dialog and reload the > mapping file each time you save the .xml or .js files to get > the new binds / javascript functions to load. There's also > a HerculesMk2.debug flag that can be toggled to get more > verbose messages in the console. > > > It seems to be working fine for me without changing any of your > values. > > > Thanks, I'm wasn't sure if it sounds quite right (I don't have > windows + VDJ around to compare scratching mode with). > > > > I realize the code is a bit of a mess (part of that is > historical - i.e channel used to be "[ChannelN]" now it is a > midi chan & part just experimenting to get stuff to work)... > so feel free to change it anyway you see fit. The only > requirement for it to work is the method signatures must contain > the correct arguments. > > > Are you saying here we're moving away from using [ChannelN]? Not > sure what you're driving at. > > > Not exactly... When midi script was first introduced, the "channel" > in the call back method sig "function (channel, control, value, > status) {" was "[Channel1]" or "[Channel2]" which made it very easy > to figure out which deck to apply the control behaviour against > (i.e. you got "[Channel1]" jog_wheel -> you were applying a change > against "[Channel1]" "scratch"). Somewhere along the way channel > was changed to become the midi channel number from the control > changed... meaning there is no longer any way to tell which > "[ChannelN]" the binding is for... > > That resulted in the following method to look up the "[ChannelN]" > value based on the physical position of the control with this > function... IMO its a bit ugly > > HerculesMk2.getChannel = function (control){ > // get the "group" that used to be provided in channel, this is not > reusable across devices > // and also breaks remapping of these functions to other buttons. > controlToChannel = { > /* > 0x2F:"[Channel1]", > 0x30:"[Channel2]", > 0x0C:"[Channel1]", // Cue > 0x24:"[Channel2]", > 0x0B:"[Channel1]", // Play > 0x23:"[Channel2]", > 0x0D:"[Channel1]", // Stop > 0x25:"[Channel2]", > 0x12:"[Channel1]", // Load Deck > 0x16:"[Channel2]", > 0x2F:"[Channel1]", // Jog Wheels > 0x30:"[Channel2]" > */ > 0x36:"[Channel1]", // Mk2 Jog Wheels > 0x37:"[Channel2]" > } > return controlToChannel[control]; > } > > > > > I've implemented the following: > > HerculesMk2.setLeds = function(value) { > for (var LED in HerculesMk2.leds) { > if (HerculesMk2.debug) print("Set LED: " + LED + " Value: > " + value.toString(16)); > midi.sendShortMsg(0xB0, HerculesMk2.leds[LED], value); > } > }; > > called from .init using HerculesMk2.setLeds(HerculesMk2.ledOff) > to clear the leds. It's not reliable though, i.e. does not > necessarily turn all the leds off (or turn them all on for that > matter, if I pass the function HerculesMk2.ledOn). I typically > have to reload the preset 2 or three time to get the all off > (this at least proves I have the led MIDI addresses correct) Any > thoughts on this? > > > I believe the LEDs on the Hercs accept 0x00=off and 0x7F=on values > only... The HerculesMk2.leds in the code I sent is a copy of the > RMX leds (remember I just copied the script and renamed RMX->Mk2), > you'll have to replace the values with the LED values in the back of > the Mk2 manual for it to behave correctly. > > > I go the midi addresses of the leds by sending 0-127 to he > device using the jog wheels. Do we have actual spec(s) for the > Mk2 anywhere? > > > Back of the Mk2 manual documents all midi input and output codes on > the Hercs. I'm thankful Hercules actually did this, because makes > it very straight forward to figure out mappings for. > > > Also, the app currently doesn't get the current fader and eq > values from the hardware and set them in mixxx accordingly when > the app starts. Is this something that will also be done via the > midi script? If so I can get on with it. > > > I think there is a way to do it via sending some midi signal to it, > but I don't know any details of how it works. > > -G > > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
