djlotus

Not familiar with this guy so I was expecting a lovely train wreck. I was happily wrong. Not my favorite sound but damn that dude is precise.

My thought process is pretty similar to yours as far as functionality goes. You have some great ideas in there that I didn't think of such as a "silence" sample and Q & A mode. The part is tripping me up, specific to the Web Audio API, is looping the generated scratch sentence. Each sample that is generated is linked as an audio buffer source node. These buffers are then sent to an array and randomized using the Fisher-Yates algorithm. From here it is no problem to play the sentence once. Unfortunately, audio buffers can only have the start() function called on them once which prevents the sentence from looping/playing again because once the sample plays through you cannot call the start() function again. I am trying to figure out a workaround but am coming up short. I have looked into a process which which would concatenate the files associated with the array into a single file, but the same issue persists. I have thought about duplicating the array at the end of playback so a new array is available to play every time but I'm not sure what effect that will have on performance.

I posted a light proof-of-concept at http://www.heyimjames.com/combo-thing/index.html

hey guys. sorry to hijack the thread but I have a serious problem. buddy of mine installed of these JD faders per specs on the vid. while doing so, possibly busted a resistor. We replaced the resistor, but still no dice. The fader, and the switch, now don't do shit. any suggestions. My boy needs this shit to work and doesnt want to ship to the other coast just so dude can "maybe" look at it. Thanks in advance.

Sounds great Deft. I've made some good progress the past few days. Web Audio API is a bit limiting so I am having to find work around's for a few things such as managing the sample libraries and creating a faux "reset" function. I'm updating the Wikis on the repo every few days with my thoughts and discoveries if you want to see how I am going about everything. Handling the actual audio is going to be the biggest problem. I have it set up now so you select the sample library you want to use, choose if you want to include a background looper, and then select the looper you want to include. Obviously more functionality needs to be added (tempo, repeat, recording etc.) but, I have broken the functionality into modular parts and will build one by one and add to it as I go. I do have some questions about the samples/sample libraries if you want to give me some guidance: When recording the samples I was thinking of recording them at 120 BPM. I think that tempo will make it easier to apply quantizing and swing in the future and make the timing functions easier overall.Regardless of the recorded BPM, should all samples be recorded at 1 BPM? For example, at 120 BPM a baby would be 0.5 seconds long. Should all scratches be recorded at that length? That could cause serious timing/audio issues if the pattern were " baby, 2-click-forward, reverse stab, baby, forward-tear." Maybe this is the way to go and we can adjust the tempo on a per sample basis. (I'm thinking of creating objects for each sample type and tying extra info to them in JSON format. Could store tempo adjustments and anything else we needed on the object and just reference it from there when needed).I am progressing right now with a system that (basically) creates nodes for each scratch sample and then plays them end to end. bufferArray[0].start(); bufferArray[0].onend = function() { bufferArrray[1].start(); }and so on). The buffer objects are incredibly light and trash collected quickly so performance is not an issue. I am exploring whether it may be better to take take the samples individually and concatenate them into a single file at runtime and use a marker in the head to jump from sample to sample. Thoughts?I just learned that when exporting .MP3 0.26s of empty data is added to the beginning and end of the file. I wonder if this will impair the looping functionality?I could on for hours. Below are some crude flow diagrams of functionality and such. The one with the controls on it isn't meant to be a reference for layout. It's just a visual to keep track of what controls will be needed. Let me know what you think:

Sorry if this is in the wrong place but wanted to start a new thread related to http://www.digitalvertigo.co.uk/forum/index.php?showtopic=1385&view=getnewpost. I'm not sure how practical it is but, I've decided to try to make a browser-based version of Sideshow's combo generator. I was too late to actually see it work (Windows 7) and non of the file links work anymore so I'm basically taking the idea and starting over. I have lots of questions for anyone who go to play with the program. I've preliminarily decided to build it with the Web Audio API and Canvas API. I could use all the help I can get. I set up a repo at https://github.com/djlotus/combo-gen and for real-time discussion I set up a Gitter at https://gitter.im/combo-gen/ I'd love to open the discussion here about it. If I'm over-stepping my bounds by bringing this back to life let me know and I kill the project. Thanks everyone.

I created a repo at: https://github.com/djlotus/combo-gen. Nothing is there content wise. Just threw together a little ReadMe and a couple crude flow charts for now. Plan is to use NPM and Gulp to manage the build so the parts can be built separately and compiled in the build process. An easier workflow for me personally.

I wish I had gotten my hands on the original so I could piece together specifics to answer some questions I have about it. Do all of the scratch patterns in each sample pack use the same sample? Was it tempo dependent?. i.e. All samples recorded at x tempo, but tempo is adjustable in program? Were scratch patterns able to be quantized to lower than a whole note? Was there an option to play a looper in the background? Was there an option to loop the scratch sample? Was it possible to record your scratch input? Should any form of notation be included as well?i guess these aren't vital questions if building from the ground up but would be good to get an idea of everything it did/didn't do. Would also help to gauge the feasibility for me to design and build this thing.

I may give building a browser version of this a try. Would take a while but could post on GitHub for collaboration.

Love watching stuff like this.

You are right Jam. The only IC on the bottom board. Found some 6x and 8x replacements but no 54 pin. Got a 61 today.switched out the plastic fader carriers for the metal ones in the 56 and I'll just part out the rest.

'Im pretty sure, at this point, the problem is in the micro-controller. I have tested for proper control voltage at every regulator, diode, op-amp, etc. I even have the proper voltages at the inputs to the mc. It appears the audio signal is fed through the mc, out to the faders, back to the mc, and out to all of the output channels. The mc they used is now obsolete and I can't find a 54 pin replacement online. I will be parting this mixer out. Thanks for you help everyone. I didn't fix it but, I did learn a bit.

Ill be ready to part it out as soon as the new mixer gets here and I can verify it works as it should. Hopefully middle of next week. I would prefer to just send the entire board to you and let you use that or pull parts off you need. I'll let you know as soon as I'm ready to go.

I grabbed a 61 off ebay. If you have issues finding the pots you need let me know. I'll probably be parting out my 56.

Got outbid. Not willing to drop more than $75 on a busted mixer in that terrible condition.