timaeus222

I'm not sure; I would be ready to do it, but The Damned, is it still a yes? Brandon, you don't have to take off your mastering. I promise, if it takes minimal adjustments to get things consistent, it will be minimal, and I'm sure yours is like 99.999999999999999999% there.

Why are we still talking about me? I'm pretty sure you smashed your keyboard through the desk typing my name over and over again. Move on?

That's true to an extent; if you pay closer attention to the faults in your audio systems, then in understanding the faults, you have a better idea of what is acceptable on the particular system based on the characteristics inherent in that system. In other words, with experience, you can make mixing decisions on any decent system. However, training your ears on a good system first is where I would start, rather than trying to mix on many systems early on. Personally, I would trust your headphones more than your speakers if you have not done much to your room, because your speaker output is mainly influenced by the treatment of your room acoustics. Your headphone experience is not influenced by that.

Just wanted to agree with this and provide my take on what I ended up finding useful in my C++ programming class and applying to my quantum chemistry programming research: - Abstract Data Types (Classes, Structs, Public/Private variables, header files) - Arrays (declared in structs and dynamically allocated) - Pointers (such as for implementation of CBLAS and LAPACKE libraries) - Selective For loops (such as taking advantage of orbital point-group symmetry and class [core/active/virtual] or choosing only nonzero electron integrals and electron densities) - Functions (of course) - Other miscellaneous things Honestly, the specific functions I had to know how to write in that class weren't nearly as important as the concepts that I got out of it. I found some of the more memorable functions to be, "is this number prime?" (literally 5 lines or so), "alphabetize this", "check the balance of parentheses" (stacks and linked lists), and "find the largest/smallest number in this list", yet I didn't use any of them specifically. The most useful unit though was the last two or three months on Abstract Data Types, IMO, and that "large project" was an ADT calculator (nightmare to program with linked lists, stacks, command line input, and such; was pretty satisfied in the end though). Fun stuff.

AW YEAH!

You know, I don't really care enough to argue, so there's no point in my responding further than this post (with regards to argument).

Despite the absolute length being rather short, I didn't find this too short. I like how it initially evokes a feeling of solitude and preparation, followed at 1:07 by a moment of gaining one's footing, and then figuring out how to proceed. This really makes full use of the orchestra, especially the brass and percussion. Dem tubas!

Yeah, this is an improvement; the added lead helped differentiate from the original's dependency on groove, and the sidechaining helped reduce the muddiness a bit. Maybe I didn't hear it before, but now I'm hearing that the drums start and stop every now and then, perhaps a bit too frequently. Try paying close attention to the drums starting at 1:02 - 1:30, for example, and noting at what timestamps you have drums, and what timestamps you don't. To me, that kinda disrupts the flow of the track, and it feels "indecisive". I get 1:02 - 1:10 and 1:18 - 2:24 with drums, and 1:10 - 1:18 and 1:24 - 1:30 without, so you basically have drums for 8 seconds, and then you take them out, and then put them back in, and then take them out again. 2:32 - 3:00 is a similar situation.

I used it merely to illustrate the principle of updating the range of your guess so that you get a better guess each time. It wasn't so important, IMO, what the actual code was, but the logic behind it that makes it more efficient than lots of repetitive if conditionals in a row. Once you understand the logic, it's easier to write the code on your own rather than modifying from templates. Also, sidenote... it was an actual practice problem in the python text I used three years ago, just so you know. I didn't just think up something that was oddly redundant.

Busy being Waldo.

Ideally, if there is a condition you know of that would let you narrow the range in which you guess, that would make this simpler. For example, let's say you wanted the computer to guess what number you have just typed in, but without taking in the input and spitting that out as the output. You could write it so that if your guess is not right, but is above a certain floor, raise the floor by assigning the floor the value of the guess. If the guess is not right, but is below a certain ceiling, lower the ceiling by assigning the ceiling the value of the guess. Each time the guess is wrong, the guessing range narrows. I think you can analogize off of the code below; instead of using the condition "is this guess equal to myNumber?", replace it with the condition that fits your need. I wrote this one in C++, but I think you can understand it with the annotations I put (and C++ can import C libraries anyhow, meaning that you can incorporate C syntax as well as the newer C++ syntax): #include <iostream> // standard, necessary library for C++#include <cstdlib> // referenced to use rand() functionusing namespace std;int main(){ /* Task: There exists a number "myNumber" in the domain ("floor", "ceiling"). The computer will guess using variable "guess", lowering "ceiling" if "guess" is too high, and raising "floor" if "guess" is too low. */ srand(time(NULL)); // initialize randomizer seed int guess, myNumber, ceiling, floor; // Note that rand() only works with ints, but you get the intent cout << "Enter your number: " << endl; cin >> myNumber; // ask for input ceiling = 200; floor = 50; guess = rand() % ceiling + floor; // initialize the guess while(guess != myNumber){ if((guess > myNumber) && (guess < ceiling)){ // If the guess happens to be in the domain (myNumber, ceiling) ceiling = guess; cout << "My guess was " << guess << ", which was above your number. Lowering ceiling to " << ceiling << endl; } else if((guess < myNumber) && (guess > floor)){ // If the guess happens to be in the domain (floor, myNumber) floor = guess; cout << "My guess was " << guess << ", which was below your number. Raising floor to " << floor << endl; } else if(myNumber < floor){ cout << "Your number is too low. Sorry!" << endl; break; // get out of loop } guess = rand() % ceiling + floor; // make guess for as long as the guess is incorrect } if(guess == myNumber){ cout << "Your number must be " << guess << "!" << endl; }} Personally, I haven't used a while loop in a long time because you have to know all the conditions of your situation so you can give a condition in which it makes sense to escape the while loop; otherwise your code will continue to run until your computer slows down. Alternatively, if you want to simply increment little by little through a range, you could also try a for loop: #include <iostream> // standard, necessary library for C++#include <cstdlib> // referenced to use rand() functionusing namespace std;int main(){ double guess, myNumber, ceiling, floor; cout << "Your number is: " << endl; cin >> myNumber; ceiling = 200; floor = 50; for(guess = floor; guess < ceiling; guess += 1){ // for as long as the guess is // within the domain [floor, ceiling), // keep increasing by 1 cout << "My current guess for your number is: " << guess << endl; if(guess == myNumber){ cout << "AHA! Your number is " << myNumber << endl; break; // get out of loop once number is determined } }} Does that help? If you understand the logic, I think you can translate it back to your language of choice.

Well, the mixing is off to a good start, actually. My main complaint is that it sticks extremely closely to the source (you have very similar instrumentation, and you even have that loop point transition back to a kick-less reprieve at 1:32), not to mention that it's a dance remix of a classic-techno track, so unfortunately there's no genre-switch merit. So while the production is pretty good, the arrangement is just really conservative. For the production, I can't tell if you sidechained or not, but it would help to sidechain the kick with the bass so that the bass "ducks" for a short moment when the kick plays. That way it reduces the slight bass clash and muddiness, like at 2:06. (it doesn't have to be pumping or obvious)

I only said that because Metal Man said: "but I'll check Python for sure. I know C a little tho" My suggestion was not directed at scripting. I already know that C is a programming language.

If you can learn C, I really think that would be better. Python is very finicky about tabbing, so if you're not an organized person, I would say, opt for C. For example: for i in range(0, 3): print ("Hola") if i == 2: print ("We have an even number") else: print ("This number is odd") starts giving you errors if it looks like this: for i in range(0, 3): print ("Hola")if i == 2: print ("We have an even number") else: print ("This number is odd") If you write it in C, you write: for (int i = 0; i < 3; i++){ cout << "Hola" << endl; if(i == 2){ cout << "We have an even number" << endl; } else { cout << "This number is odd" << endl; }} which, if it looks like this (which is horrendously bad tabbing) for (int i = 0; i < 3; i++){ cout << "Hola" << endl; if(i == 2){cout << "We have an even number" << endl;} else { cout << "This number is odd" << endl; }} there is no error. Just my two cents. Plus, I know for sure that C is case-sensitive, so there is no need to change to ~^2 when going from a to A, for example. You can work with ASCII values like Neblix suggested, or you could even use the functions isupper or islower to check for capitalizations (granted, Python has that too, but that's not the point).

Makes sense to me. It's a compliment in other words; Mak's saying that what some of us wrote sounds fairly cohesive, despite our differing styles. *shrug*

This is from 2001?! Uh, alright then. This was actually one of the more memorable tracks that I listened to from OCR when I was a kid.

I agree with MP3 compression essentially masking the subtleties; although, since djnforce9 isn't necessarily asking about just MP3s, but OCR's remixes in general, I'll additionally suggest trying FLACs rather than MP3s when possible, such as on an OCR album, to get the best possible non-WAV fidelities so that if there are differences, there is still a decent chance you can hear them. @djnforce9: do tell us how this turns out for you.

Oh hey, Heavyocity Damage. I guess I would say to improve the sounds that aren't Damage, to get them to be up to par with Damage. Right now, I bet if you muted Damage, the soundscape would really feel empty, ,which would mean Damage is a very significant contributor. When you can do so and not have it feel empty, I think that would be optimal. Also, the intro before 0:11 feels rather narrow and lossy compared to the rest. I know you want contrast, but maybe make it wider and a bit less lossy.

Well, it is true that most OCR tracks are on "standard encodings" (some are still lower than 192 kbps or are not VBR1 because of project files being lost, for example), but the "lossiness" does vary from track to track (even those of similar encodings), so I think his request is still valid. It might be difficult to find something that isn't very subtle, but I would still try. What I mean is that some people's finalization techniques give a more pristine treble "sheen" to the overall soundscape, and sometimes bass "warmth," whereas the results of some other people's finalization techniques come off as "rough around the edges." Yet, they may all still, for example, use VBR1 encoding. It depends on the audio system and other similar factors with regards to whether or not a listener can hear the difference, but I'll try to pick some examples that I find especially noticeable. In order of lower/lossier to higher/more-polished (1 < 2 < 3), yet similar bitrates (VBR1 or 192): 1. http://ocremix.org/remix/OCR01221 (the recording) [192] 2. http://ocremix.org/remix/OCR03110 (EX: the guitar at 1:13) [VBR1] 3. http://ocremix.org/remix/OCR02653 [VBR1], http://ocremix.org/remix/OCR02687 [VBR1] (I'd recommend listening to them as downloaded MP3s, rather than on the YouTube Preview) Granted, I don't know what headphones or speakers you use, so I'm not saying you will necessarily hear a difference between using your old setup to your new one, but what I am saying is that if you do want to give yourself the best opportunity for hearing such a difference, I would try the tracks listed on "3". If you don't mind, I'll also put one non-OC ReMix that I think might be a good candidate for checking subtle fidelity contrasts. I would pay attention to the granular, watery, "metal-chain-like" sound around at 0:03 - 0:15, for example. It's subtle, but I have heard a difference before in the lossiness when comparing the MP3 vs. the FLAC. https://soundcloud.com/overclocked-records/5-oasis-epsilon

Verdanturf for Treecko evolutions? ;o

Just a quick nudge/reminder about this. So, if the people that are done can send me their WAVs, I can get going on getting them to sound consistent so the album flows well and is as polished as possible.

I love this kind of idea. I'd love to do something for Sceptile. Besides texture, would these necessarily build off of the "unevolved form" in style and structure, or can we simply write something that's just for mostly the same source(s), but potentially different style and/or structure (just to keep things from getting too rigid/same-y)?

Strangely enough, I like using compos to experiment *out* of my comfort zone sometimes. My Round 2 and Round 7 tracks were styles I don't usually write with. My Round 4 entry was more "me" in that it had dubstep, but even that one was mainly similar to the "me" you last heard -once- in late 2013 (metal + glitch in Gunstar Heroes), not the "me" today. TBH, the music I'm most comfortable writing is probably funky EDM, but I don't want to do that *all* the time, so I branch out into variations on dubstep, glitch, and cinematic sometimes too.

Mod Review is when an actual Moderator (who was appointed by the Judges) gives a review, rather than any random member. They have explicit credibility with regards to understanding what makes a ReMix a good fit for OC ReMix. You mark "Mod Review" on a topic to tell them you want one, or you can message one of them and ask. Someone like Rozovian, XPRTNovice, or Gario is more active these days and could give you a review. OCR submission is simply a process to get the ReMix on the site. It usually takes about 9 months to a year to get something posted on the site. You can find the guidelines here: http://ocremix.org/info/Submission_Standards_and_Instructions

This is a good start, but there are definitely some things to look into. If you listen more closely at 0:24 and 0:37 for example, notice how the notes on the violins and/or violas is detached. A real violinist would keep the bow on the strings when playing a long phrase. What you had at 0:30-0:31 was a good example of how I would recommend the notes at 0:24 and 0:37 be executed. Similarly, in other spots where such notes are detached, it's worth trying to overlap them. I mentioned these two spots because they were the most obvious, but there are probably other spots that you should check. At 0:41, the piano that comes in feels dry. In other words it sticks out too much. I can somewhat hear a midrange reflection indicating that you do have reverb on it, but having a touch of low-mids reflections in the reverb would help glue it into the mix better. You might be able to accomplish that by lowering the Low Cut on the reverb a bit. You can also improve this further by having the piano play actual chords. At 1:36, the piano is somewhat competing with the brass. The brass sounds like it's supposed to be "softly" leading (meaning without the "blatty" tone), so maybe you can slightly lower the velocities on the piano by the same amount at 1:36 - 1:57 and slightly raise the velocities on the brass. Good transition at 2:02 with the harp roll, and I like the textural development from 2:02 to 2:44. It helped accent the descending arp to use that xylophone/marimba and use some more-active low-end percussion. Cool chord progressions. At 2:44, I hear more of those detached violin+viola notes, so try overlapping them more to make a more natural phrasing. ----- Overall, you do have a pretty good understanding of using automation to add swells to your longer notes, and for the most part the reverb is pretty cohesive. Production-wise, the mixing is a little distant, but is on the right track IMO. Just some minor balance issues with the brass+piano, the piano sticking out of the mix a bit too much at 0:41 (maybe have it play chords, too?), and some more major issues with the detached high strings notes wherever they should be more overlapped, such as 0:24, 0:37, and right after 2:44. Arrangement-wise, this follows the original pretty closely, but you did add an original intro and expand on each section in the original. Based on the straightforward arrangement and good (but not great) mixing, I would definitely recommend getting a Mod Review before submitting this to OCR. It's getting there, but I do believe it's borderline. ----- As for "EBU128", I wouldn't worry too much about it. If your music currently sounds good to you, keep mixing the way you're doing it. I have never heard of "EBU128" until a few weeks ago, and I've never used it. I still turned out fine.