Hi Garth, Garth Dahlstrom wrote: > Hi Jim, > > I applied all of your changes for the Mk2 accept for "wheel" stuff > from the wheel_decay function... that bit was from the old RMX code I > wrote and has since been corrected (decay is not necessary because the > "jog" key will decay automatically for pitch adjust)... All your > other stuff is in r2424.
Excellent, thanks. I've merged the wheelDecay function from r2424 back into the local copy I'm working on. > > I like that it flashes all the LEDs... I noticed it sets the CUE led > when tracks are loaded (does VDJ do that, I wonder?)... I'm pretty sure it does. I think the cue button is lit to show that the track is currently positioned at the cue point. When a track is loaded it is automatically positioned at the cue point, so it makes sense the cue button is lit. Will double check VDJ functionality. > nice that > that midi short msg seems to get the controller to spit its control > values... Yes that is handy. It's called 'Update analog controls' in the Herc Mk2 manual's midi spec. Guess the RMX will have something similar. > > Could you do me a favour when you get a chance and add a table under > the Mk2 which talks to the changes in the patch for 1.7 on the Wiki @ > http://mixxx.org/hercules (you can look at the 2nd the table I made > under the RMX for an idea of what I'm talking about). Sure, will do. I'm not sure at present that there's any control functionality change/addition to detail. In terms of controls on the device and what they do, it still works the same as listed in the existing Hercules MP3/MK2 Controls Default Mixxx Mapping table. Please advise if I've missed something. There will be some stuff to detail there soon however with kill/fx/cue/loop mode switching on its way. The track buttons are mapped to NextTrack and PrevTrack but these controls don't load tracks in the order they appear on screen in the library. Seems a bit random. Guess this is something needs sorting in the app itself? Anyhow these buttons don't appear in the existing Hercules MP3/MK2 Controls Default Mixxx Mapping table - should I note them there but as 'buggy'? Cheers, Jim. > > Cheers, > > -G > > __ > --- == __/ t.O ==-- > http://stacktrace.org/ > > > > On Tue, May 26, 2009 at 7:31 PM, James Evans <[email protected]> wrote: >> Hi Garth, >> >> Garth Dahlstrom wrote: >>> Hi Jim, >>> >>> comments inline below... >>> >>> On Tue, May 26, 2009 at 6:00 AM, James Evans <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> In your RMX scripts, I can't quite see what functionality you're >>> trying to achieve with HerculesRMX.cueButton & HerculesRMX.cuePlay. >>> Could you let me know so I can see if it's something the Mk2 should >>> be doing too. >>> >>> >>> So, I was trying to emulate CDJ behaviour where by if you hold CUE the >>> music starts to play, if you release CUE the song position returns to the >>> CUE point, however if you hold CUE and then hit PLAY (CUE+PLAY) before >>> releasing CUE the song goes into normal playback mode preventing the release >>> of CUE from repositioning the song. >> Cool, though it looked something like that. >> >>> The Javascript code I wrote seems like it ends up fighting the playback >>> engine in some kind of race (which is why it trys to do get position, stop, >>> reposition, play really quickly)... It only works something like one 5th >>> the time for me on the RMX. This was something we originally talked about >>> doing inside the playback engine, but I thought it would be interesting to >>> see if it was possible doing it via javascript. >>> >> Yes, I tried it and got the same problem. >> >>> Headphone selection - The device has the following settings: Deck >>> A/Deck B/Mix/Split. For Deck A and Deck B I can use [ChannelN] pfl >>> (in the mapping xml), but I'm not sure what to use for Mix/Split as >>> these modes use both channels. At present I've just used [Master] >>> pfl in the xml - although there is no corresponding Mixxx control, >>> this does allow at least for the relevant script function to be run >>> (turning both Headphone buttons on in the Mixxx UI for Mix/Split >>> modes). >>> >>> >>> I believe the original Hercules/VDJ spec for Mix/Split is that Mix should >>> be the same as your Master out, while Split should have the Master in the >>> Left headphone and the last deck to be loaded in the Right (Left and Right >>> might be switched, don't remember 100%). Alternatively, for Split could do >>> it Deck1 in Left, Deck 2 in Right... I'm not really sure it's doable to >>> manipulate the channels in the headphones like that within Mixxx, though I >>> haven't spent much time on it. >>> >> Yes, mix is as you describe it. Split (according to the Herc MK2 manual) is >> not used in VDJ 3. Deck1 in Left, Deck 2 in Right sounds sensible to me. >> I'll leave that for the time being, may have a gander at the code to see >> what might be possible (with my very rusty old C++ knowledge!). >> >>> Loop/Cue/Fx LEDs and mode selector - Currently the Loop/Cue/Fx mode >>> selector buttons play the track in reverse using >>> <key>reverse</key>. I would personally find it more useful to turn >>> these buttons back to (into) Loop/Cue/Fx mode selectors. This way, >>> when no mode is selected (which would be default at startup), the >>> 1/2/3 buttons can work as bass/mid/treble kills as they currently >>> do, but then, selecting different modes for those buttons, they can >>> be used for fx, cuing and looping (when it arrives in Mixxx). This >>> would however mean ditching use use of the Fx/Cue/Loop LEDs as VU >>> meters. I would personally forgo the VU metering for mode indicators >>> (I don't find the metering particularly useful anyhow given that I >>> can see it in the UI if necessary). >>> >>> You have any take on that? Should I just get on and do it? >>> >>> >>> Right, so I would be in support of changing into Loop/Cue/Fx as you >>> described. The mappings (see mixxx.org/hercules/ >>> <http://mixxx.org/hercules/>) are defined to 1,2,3 kill hi, mid, lo, and >>> mode arrow is reverse. The reason the mappings are as they currently are >>> is, that until Mixxx 1.7, we had no way to dynamically remap functions via >>> modes (all controllers were stateless from Mixxx's perspective) and we also >>> lacked the ability to easily redefine the behaviours. >>> >> Ok, cool. I'll sort that out. Already have the existing kills scripted. >> >>> The attached are a pretty good starting point (for scripting the >>> Mk2) anyhow I'd say. Perhaps you could consider these for committing >>> so at least the stuff so far is there for other Mk2 users to >>> use/work with? >>> >>> >>> I want to play with them on my Mk2 (have to go to work, first), then if >>> they look good. In the mean time, I want to encourage other Herc Mk2 users >>> on the list to grab them and offer feed back. At the moment, I think only >>> yourself and Siarhei are into the Mk2 scripting, but Robin and others may >>> also be interested as we should try to keep the behaviour of the Mk2 as >>> consistent the the MP3 control as possible. >>> >> Great, feedback gratefully received. >> >> Cheers, >> >> Jim. >> >>> Anyway, keep plugging at it... this is good. :D >> Cool :) >> >>> Cheers, >>> >>> -G >>> >> > > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
