rockout developers guide 1. what bugs are there to be fixed? 2. fun stuff you may want to change 3. tests you must do to make sure your code change was successful 4. my explanation of the flow of the program (i also put lots of comments in the code) 1. what bugs are there to be fixed? a) the biggest bug, identified with codeword bug 12345, is the case of the missing BUTTON_REL. long story short, if you LET GO of a sample button, the sample should end right? well if at that very moment, if you're just starting to hit a different button, about 1 in 3 times it will not notice that you released the initial button (the initial sample will continue playing). i don't know if it's hardware, or what. you can reproduce this error by hitting a new button while letting go of another, you should hear it continue on for a second before my bugfix comes in. search 12345 in the code and you should find my bugfix (basically if the code doesn't notice any BUTTON_REPEAT messages for a while, it cuts the sample, to catch samples that continue along). b) another bug, once in a while the effectmode will change. i assume this is to do with my code concerning using the e200 wheel with the buttons (basically the wheel can't be used in combination with other buttons, so i made it so if "recently" you have hit the wheel then the combo will activate.. and i think it could be tweaked a bit). not a big bug at all but anyhow. c) ideally i would like to cut the latency down to make this successful, you will be my hero. please see "2) tests you must do to make sure your code change was successful" d) code could be cleaned up.. please unless there is major efficiencies in length of written code, or decent efficiencies in result (less processor drain), then do not needlessly clean up code, i would like not to have to relearn my code as much as possible. ie) if you can figure out a way to compress the button events (it's obscenely long the way i did it), great. if you can take some if..then statements out of loops that would result in efficiency gains, great. otherwise.. i know you have a different coding style (better) but i'm not quite sure i want to have cosmetic changes too much to the code. i mean i'm being anal retentive and code improvements are welcome but keep this in mind perhaps. e) the amount of samples you can have on disk is limited (the array that holds the filenames maxes out at like 8 folders of 88 sampels ors something.. i would like this doubled/tripled.. i'm sure this is easy enough to do.. somehow to use the stolen_buffer for this array somehow).. at the moment if you increase the array it gets plugin out of memory error on compile. f) WAV header isn't saved in saved loops when you save a file, it saves it essentially as a 16 bit 44khz stereo RAW file (there's no header written). needs to be done. g) I think I remember some samples load with a little click at the beginning, apparently the SEEK past the wav header isn’t always working properly. 2. fun stuff you may want to change a) make new glitch sequences. mine are a bit doodie. b) make distortion more accessible maybe? (it's already programmed in, it's just not included in the effect switch button). i dunno i'm ambivalent (nice but more complexity for user) c) make the drum and bass rewind something you can trigger (again, it's already programmed in, it's just not included in the effect switch button. i forsee this as something you can trigger with the glitch button instead of glitch). i suppose you could just make a glitch sequence that starts with a rewind too. .. both b) and c) aren’t implemented due to lack of buttons left to use and don’t want to make the UI overly complex. d) make new sample packs. very fun. please share them 3. tests you must do to make sure your code change was successful there are two things that can go wrong, if you do any change that will slow down the code (usually too many "if..then"'s somewhere that gets repeated) or if you do any change that screw up something: first thing that may go wrong: you will hear a little (quite little) click near the beginning of the sample (and sometimes also about every 5 seconds). this is the file opening on the disk for buffering (it plays a second or two, then opens the file, then starts buffering). this is a bit voodoo magic that it isn't there anymore, but i don't want these clicks back. TO HEAR THESE CLICKS you must be playing long (10 seconds+) samples that are extremely quiet (load a wav that has been turned down 90% in a wav editor).. or you may have your own way, with a continuous sine wav down to a low bass, or whatever. i think this problem may be permenantly fixed so feel free to skip this step if you want.. unless you really added some heavy dude intense processing stuff. second thing that goes wrong: it fails to buffer fast enough (sloppy code or too ambitious code). to test this, play 5-6 samples at once that are long, and after 5-10 seconds, you'll know if one of them failed to buffer (white noise, very loud). you will hear "clicks" from it clipping but that is normal. please check for these after any major code revision. (or at the very least, the second one). all it takes is to jam all the buttons at once, see if it buffers. 4. my explanation of the flow of the program (i also put lots of comments in the code) plugin starts at plugin_status plugin_start(const void* file) in that function, it calls load_to_mem() which loads the first big chunk of audio of each sample into stolen_audio_buffer1 to 5 [the following paragraph is only for long long samples that need disk buffering] in drumkit_main, all the buttonpress stuff is there, and at the very end of that function, there is a catch spot where if the sample is long, and is getting close to the end of the first 1/2 of the sample (only 1/2 was loaded initally above), it will start buffering more off disk into the first extra chunk of memory (from 1/2 to 3/4 of the stolen audio buffer area). also, when it's almost 3/4th of the way through, it loads the final chunk (from 3/4 to the full stoleN_audio_buffer area). then, when playback is almost at the end of the whole stolen_audio_buffer area, it starts loading from 1/2 to 3/4 again (ie: i made it so the buffer chunk is split into 3 parts, the 1/2 half, then 1/2-3/4, and 3/4 to 4/4, so that if someone retriggers the sample from the beginning, the beginning will always be there ready to go (the 1/2 half of stolen_audio_buffer never changes, the disk buffering takes place completely from 1/2 to 3/4 and 3/4 to 4/4).