All day drumming. All damned day. Trying to settle this whole ASIO thing and get my MIDI EDrum solution for the IED05 MKII stabilized. ASIO4ALL had been really inconsistent, occasionally working perfectly, then acting up again on the next system reboot; dropping or losing hits. It's very frustrating. This is not the way computing is supposed to be and it's putting me in a bad mood. Results are supposed to reproduce on a computer. Same hardware, same software, same situation, same results. Zero or one. On or off, damnit!
Anyway I tried this alternative to ASIO4ALL called ASIO2KS, and spent all day developing a theory as to why some buffer rates were perfect - didn't drop a single hit - while others, regardless of buffer size, were complete rubbish. I penciled down the few buffer rates that were working, noted a significant sound improvement and immediate end to the buffer overrun fart-noises in 3 and 4 block mode, but couldn't find an absolutely perfect buffer rate in those modes. I finally accepted that I wouldn't be able to use ASIO2KS because the designer wrote in a kind of shareware-style thing where after ten minutes use it starts beeping every thirty seconds, ostensibly making it unusable for recording and damned annoying for everything else. It's especially ridiculous because the guy isn't even selling it! If it had worked flawlessly, and he'd wanted ten or twenty dollars to get rid of the beep, I might've sprung for it, (eventually) but you go to his site and everything is a beta version. He so anticipated selling the thing that he built a 'pester' into it from day one so everyone would have to come back to him for the retail version, and then he never actually took it to market. There's capitalism for you, folks. An otherwise perfectly usable program sabotaged by its maker on the merits of anticipated revenue; greed, to be followed by stifling apathy.
ASIO2KS being therefore deprecated I eventually reinstalled ASIO4ALL, hoping to apply what I'd learned in ASIO2KS. Mind you, the learning process was all day... It was 10pm when I, at last, went back to ASIO4ALL. And quickly discovered that nothing I had learned about ASIO2KS bore any relevance to the configuration of ASIO4ALL.
Nevertheless our stalwart hero marched on. I quickly found that setting ASIO4ALL to 3 kernel buffers and any buffer size below 192 samples ended my disappearing strike woes, and in the end I actually left it at 4 kernels and 152 samples, which seemed to be the 4-kernel butter-zone where all buzzing disappears.
This, however, I have no faith in, seeing as the last time I found the "perfect" settings, they ceased being "perfect" on the next restart of my machine. I did, however just notice in the ASIO4ALL documentation that they recommend turning off processor p-state switching (SpeedStep) while ASIO is in use. Now I just happen to be running the awesomest mobile processor Intel ever put out - the Pentium M - and she is known for her seductively sultry ability to clock down from 1.6Ghz to 600mhz in steps of 200mhz, under varying loads. I suppose that could be causing some of my problems... I'll reserve judgment there until further testing. For while it seems a plausible suspect prima facie, I happen to know SuperDrumFX (the VSTi I'm loading) to be a major draw on my CPU's resources. I would be surprised if Intel's SpeedStep is finding occasion to do anything but open the throttle up wide as she'll go, while SDFX is in use, Captain. (Probably has to take off the governor, matter of fact.)
Recording is going to be the biggest bitch of all. My preference is to record as MIDI data. That would be best as it would allow for the most flexibility. I get butterflies in my naughty-bits when I imagine being able to reach into a drum performance and nudge an early strike into its proper place. The problem with MIDI recording is that I just don't seem to have the power here. Running SuperDrumFX on any host more complex than SAVI or VSTHost just lags it all to hell. My trusty HP NC6000 laptop is at last, and finally, showing it's age. Funny to think that it took all this -- a demand for less than 10ms audio response from dynamically generated, overlapping wav playback during simultaneous timestamping of incoming midi events. It's the first thing in so many years that 1.6Ghz and 768Mbs hasn't been able to handle. Goes to show how overpowered the average computer is these days, with your Quad-core, 4GB DDR3, 32Mb cache SATA-II, and whatnot. I digress.
MIDI recording while the VSTi is active has so far resulted in little more than the occasional sputter of an errant drum firing way off time. The MIDI input seems to all get recorded well enough, but the solution is not of much value if I can't hear what I'm playing while I'm playing it. And in fact, even playback of the recorded MIDI track has been too much for the sequencer I tested to handle. More of the strikes playback than sound during recording, but thirty percent or more still disappear in lagsville.
If I can't have MIDI recording, I'll settle for capturing the wave output, but there are problems here as well. The A-number-one problem is playback during recording. To record for production purposes I need to be able to playback a music track to drum along with during record. Because I lack an elegant solution that can simultaneously host the VSTi and record the output without bogging down SuperDrumFX, I've had to playback the song and record the wav output using a seperate program. I've been trying Audacity.
But Audacity can't just reach in with a magic microphone and record the audio being produced by SuperDrumFX. If I want to record the SuperDrumFX output with a separate program, Audacity or any other, I can only do so by recording the main audio bus, or in other words I have to record every sound that is currently being sent to the speakers. This, unfortunately, would include the playback of the song that I'm drumming along with. Sigh... The shorter version is: I can't easily record a clean drum track during playback. I have hopes that I'll be able to put VSTHost to the task of overcoming this. It hosts SuperDrumFX well enough, and if I can simply figure out why it's recording functions are producing wav files nothing knows how to read, I might have a way of capturing my VSTi's output before it hits the bus.
If I ever succeed in nailing down all this mind-numbing bullshit I mean to write and record a whole slew of material promoting the IED05 MKII as a viable eDrum kit. I might just start a separate blog dedicated to expanding the capabilities of the IED05 out of the box. In fact, once I've hammered out an all-purpose software solution, I'd even like to delve into DIY'ing some more natural drums for the kit. All together it's a good winter project and for $140.00, let me tell you, when you get this little kit working perfect - if you can get this little kit working perfect - it's a damned beautiful sight to hear.
0 comments:
Post a Comment