Garth Dahlstrom 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).
>
Ah, I've not tried scratching mode, other than to see that the track
does go backwards when you rotate the wheel CCW. I'm no scratcher, but
will get a Windows machine with VDJ up together to compare.
>
> 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];
> }
>
>
Ok, this will be rid of anyhow once we start using the XML 'group' param
so may as well stay as is for the time being?
>
>
> 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.
>
Yes, I am only passing 0x00 for off and 0x7F for on, and I had changed
the LED midi addresses to what I 'discovered' them to be.
>
> 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.
>
Yes, that is very handy! Checked this and they were all right bar 1.
So, the problem still remained. Turning them on with this:
for ( var LED in HerculesMk2.leds ) {
midi.sendShortMsg(0xB0, HerculesMk2.leds[LED], 0x7F);
}
results in generally 2 or 3 leds not being on. Run it again once or
twice and the 'gaps' get filled in. Same happening turning them all off.
So, I slowed it down to try and see what was going on by sticking a
500ms pause between each midi.sendShortMsg. When I did this, they all
behaved themselves, like as soon as you try and examine the problem,
it's not there :)
The only conclusion I can draw is that if the device receives a load of
midi messages too quickly it can't cope/loses some. I got the pause
between midi.sendShortMsg calls down to 6ms, which, on .init(), causes a
nice cascade of leds on/off given that they appear in the right order
(visually top to bottom) in the .leds object. The turning on of all leds
before turning the off (in .init()) is unnecessary really but serves
as a nice "I'm alive" indicator.
It seems you've implemented the above loop to turn the leds off on the
RMX. Do you have that working? Did you not experience this problem where
it often misses some?
>
> 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.
>
Yep, I found it in the Mk2 manual:
midi.sendShortMsg(0xB0, 0x7F, 0x7F); // Update analog controls
I imagine there's something similar/same for the RMX.
Once I compare scratch modes with VDJ we'll have a midi script that:
a) means we can stop using hercjog
b) initialises all leds (and turns them all off on shutdown)
c) sets the values of the sliders and pots in the app based on what they
are set do on the hardware.
Given a tidy version of that (with all the unnecessary commented out
stuff removed), it's probably worth committing I'd say.
> -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
