On Wed, 2007-12-05 at 19:12 +1000, Poor Yorick wrote: > Hi all, > > I've come across a few interesting things in relation to the vinyl > control code. And managed to debug mine so that it works again! > (!!!) ... At least in the old trunk version. : P > > Someone broke Trunk when they added the new Hercules code (I think it > was Adam who was working on the Hercules? He's on Windows?). The new > code is shiny (I hear, I don't have a Hercules :P ), but I think an > include or somesuch is missing for Linux: > > /home/yorick/development/mixxx/mixxx/src/dlgprefmidi.cpp:200: > undefined reference to `HerculesLinux::HerculesLinux()' > > I don't understand enough to go poking around in there, and obviously > I can't test to see if I break anything either, so I cut out that > block and compiled successfully, but segfaults occur on startup, and > the GNU debugger reveals: > > DlgPrefMidi::slotApply (this=0x86156b0) at src/dlgprefmidi.cpp:462 > 462 > m_pHercules->selectMapping(ComboBoxHercules->currentText()); > > i.e. removing that block doesn't reaaaally work. If someone could hop > on this so I can get a stable (ish) trunk build to start from it'd be > great. :
Hopefully this will be fixed soon otherwise I'll take a look at it tonight. (remind me on IRC) > > So! On to vinyl commentary, and the mystery > Yoricks-vinyl-is-fucking-weird-bug solved! > > Basically, the vinyl control seems to tie into the pitch faders > already in Mixxx somehow. Since mine were inverted (down speeds up, > like my Technics) and at +/-50%, my vinyl control was totally, totally > weird. Many debugging ideas were put forth as to why when I changed > the speed of the record by less than a percent, it would hop from > slowed down to squirrel-on-helium, but it turns out that this was the > problem. Setting my pitch faders back to +/-8% and up-is-fast solved > *that* particular weird issue. Though that shouldn't have happened... I thought the inverted speed thing would have been fixed by Martin Sakmar's patch a few weeks ago. It's still broken in trunk? (I thought I tested this too, but I could be totally wrong) The pitch range IS hardcoded in the vinyl control. It's probably like a 3 line change to fix it though, feel free to send a patch. (At the very least, file a bug in the tracker so I don't forget to fix it.) Had I sat down and written the vinyl control stuff all in one go, I probably wouldn't have done stupid things like hardcoding that and just done it the right way the first time around. Unfortunately, my resources are just spread too thinly to fix everything right now. (send me patches!) > > On to the rest of the commentary (or black-hat thinking as it were) as > I'm using the vinyl control (I haven't read much of the code yet): > > 1: It looks like the vinyl control of the waveform is basically built > on top of the pitch-fader widget. This *works* but isn't the greatest > way to do things for these reasons: It's built on-top of the whole "control" engine. The pitch-fader widget simply displays the value of the pitch from inside the engine. > 1a: It means that if you want one vinyl control deck and a non-vinyl > control deck, you can't change the virtual one to have a non-standard > pitch range. I mean, both virtual decks inside Mixxx have the same pitch range right now... so it that such a crime? :) > 1b: The BPM detection breaks (well, just assumes the pitch is +/-0) > when you go off the end of the pitch fader and it snaps back to 0. Once you exceed the pitch range the code falls back into what's essentially "scratch mode", which is why you're seeing that. For anyone interested, it changes control mechanisms at that point - instead of feeding values to a "rate" ControlObject, it starts talking to the "scratch" (it's like "wheel") ControlObject. If you can come up with a better behaviour, be my guest. I guess what you're proposing (which is really not using the "rate" ControlObject) is to use the "scratch" ControlObject the whole time (while in absolute positioning mode)? This would show the pitch faders locked at zero, and I'm not sure about the BPM. (Does it work if you go to scratch mode in the options?) > 1c: As far as widgetised design go it just seems making a "virtual > deck" object and a "vinyl deck" object subclassing "deck" object would > make more sense. I don't know enough about the internals yet to really > say, but from a user POV having the pitch faders/virtual deck tied so > strongly to the virtual one is confusing. Yeah, I could only wish it was that simple. (The deck analogy breaks down when you start considering MIDI controllers, etc., so I don't fault Mixxx's class organization there.) So we have two options - Lock the pitch faders in the GUI at 0% and use the "scratch" ControlObject inside the vinyl control code or I could just add smoothing to the pitch fader's value and we'll see what it looks like. I need to add the smoothing regardless, but it might look better once it's not jumping around like crazy. (Ben was saying he could hear it sounding like crap because the pitch variations were so rapid, but I couldn't reproduce it until last week when I cranked my latency super low. So no Ben, you don't have super-human hearing. :) Smoothing should fix this.) > 1d: There is no indication what the 'expected' pitch range is for the > vinyl control. AFAICT it's +/-10%. Patch, patch, patch, p... > > 2: The sound is amazingly harsh and digital, and is tied into the > latency you set in the menu. I think I talked to Albert about this at > some stage, but there wasn't much conclusion on it? Basically you get > a 'grating' sound as a lot of very short samples are played end to end > with seams, and at low latency it just sounds horrid when the vinyl is > moving extremely slow or is stopped, with pops as each sample is > played... I don't think this is to do with my hardware, as xwax and a > good half-dozen Windows programs have no problem with its > configuration (and M-Audio Deltas can get pushed pretty hard to > boot). > Dive into enginebufferscalelinear.cpp then. I took a poke at it the other day, but there's quite a bit of stuff I just don't understand about the code. I suspect part of the crackly stuff might be because it's not interpolation across buffer boundaries nicely (we're getting discontinuities). As well, when you change directions there's another nice big spike for some reason. If you try "vinyl emulation" mode at 96000 Hz it'll sound _much_ better though for some reason. Again, this is another one of these tasks that I just haven't had the time to work on because there's other things with higher priority. I'd really appreciate it if someone could poke at it. > 3: I've tried the Mixvibes DVS vinyls in CD mode, and they don't work. > It really *does* mean CDs. :) > > Another thing: Resetting the audio connections to JACK when you hit > okay in the preferences, and you haven't changed anything related to > audio (or at all) is bloody annoying. It means you have to go back and > rewire things, and the PortAudio connection labels JACK has change too > (numbers go up) - meaning that patchbay connections can't easily be > used. > There's a PortAudio function (introduced a few months ago) that allows us to set the JACK name explicitly. I avoided adding it because PortAudio-v19 is still an unstable API, and we can't count on Ubuntu, Debian, etc. having a new enough packaged version of PortAudio. I've sent a related question about this upstream to PortAudio's mailing list, we'll see if we get anywhere. (It's a slightly different question, but it'll let me get around this.) > One last thing, I ran into a deadlock while trying to open a song. > Just putting yet another mutex bug out there. : \ Multi-threading is a > bitch. Were you using two decks with vinyl control at the time? (ie. were two input devices selected in the vinyl control prefs? This is important...) Thanks, Albert ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
