timaeus222

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.

Just fyi, "Slime" is the indicator of how many posts you've gotten. You meant brokenbirthday.

The arrangement here is actually really good. It's hampered by the production and samples, but compositionally it's got a +1 from me.

Hey guys, Kristina wanted me to start taking the reins for PvZ. I really want to see this finished, so I'm pushing for you guys to get going! Anyone with updates, send them to Kristina, me, and Brandon! I'm looking for updates from Brandon, djp, Sir Jordanius, WillRock, Rexy! Redg, you're so close --- I know you can finish your track up! Wizard of Lakmir --- how's your track going? I know you just gave an update recently, though, so keep it up! And ToN, wanna show us up with a wicked WIP and counter your moniker with some existence?

Hot damn, that's oozing with emotion!

Yeah, I did find the controller cord kinda odd, and perhaps the tattoo could seem unprofessional, but otherwise it's a great start IMO.

This amazing Final Fantasy tribute album. Arrangement by Stephen Anderson, and violin by Lindsey Stirling.