- Use a condenser microphone with a pop filter for vocals
- Use 2 matched condenser mics for acoustic instruments, separated by twice the distance to the instrument, pan them left and right
- Use a dozen cheap foam panels to reduce unwanted room sound (placed closer to the vocals/instrument depending on situation). I tacked mine to a sheet of plywood so that it could be moved around.
- Eat a banana before singing to help improve vocal quality
- It will never sound as good as you want, but the most important thing is the performance. People will put up with imperfect recordings if the performance is good.
> - Use a condenser microphone with a pop filter for vocals
As an old engineer and record label owner I actually say NEVER use a condenser microphone unless you have great acoustics in your room and specific reason for using them. Use a dynamic mic instead. They are great sounding used on millions of songs and they are forgiving for bad acoustic areas. People just assume that condenser are better for all vocals. My 1" condensers that cost thousands sound amazing but a lot of times I just use a SM58 instead because it was a better sound for it. SM7B is my go to mic for vocals but that would be out of most people's budgets. Also no need for phantom power is also a plus.
SM7B from Shure $399
Sennheiser e945 $219
SM58 from Shure $99 (This is a tank of a mic that just rocks)
Sm57 all the way for me. $150 condenser mic I got at Guitar Center was terrible.
As a back in the day old time recording engineer, I had access to Neumanns and AKG mics worth thousands of dollars. But 60% of the time, a sure 57 ended up sounding better.
Hi, sorry for hijacking. I'm a bedroom producer noob and I'm currently using an NT1-A for vocal stuff although I've recently been working with a female vocalist who's got a very strong (and pretty bright-sounding) voice. Would you recommend giving the Sm57 a go for this sort of thing?
Absolutely. Condenser mics often don't work well with the kind of voice you're describing. They end up sounding shrill and a bit clippy even if they don't officially hit the clip level.
Mics like the 57, or the old re20 that you used to see in studios have a warmer, analog sound that's more forgiving and softens the harshness that you can hear in condenser mics.
As a bedroom producer, I’ll have to disagree. My $300 Rhodes condenser mic sounds way better for vocals than my e906 Sennheiser dynamic mic. I don’t have an optimal space, and haven’t even looked into the acoustics of the room.
Your e906 is designed primarily to be stuck in front of guitar amps, I'm not surprised that a Rode LDC would beat it. That does not mean that everyone recording in their bedroom will do better with a condenser microphone vs a good dynamic.
Using two mics for recording acoustic instruments (in this case, guitar) and mixing two sources later in the DAW is explained here: https://www.youtube.com/watch?v=ww-cH29IGeM
> Use a dozen cheap foam panels to reduce unwanted room sound (placed closer to the vocals/instrument depending on situation). I tacked mine to a sheet of plywood so that it could be moved around.
This is a good suggestion. Acoustic panels can be made really cheaply and simply. Here's a couple of examples.
I like the first video because he does a bit of minimal testing with a tone generator. I'd be interested to see more testing, using more realistic frequencies, in a room.
> Use a dozen cheap foam panels to reduce unwanted room sound (placed closer to the vocals/instrument depending on situation). I tacked mine to a sheet of plywood so that it could be moved around.
You're talking about bass traps. They're an essential for recording in most every room. Here's a great video for how to build some quite effective ones for cheap. (I'm not affiliated w/ this guy or his channel). https://www.youtube.com/watch?v=dZV-gxVpkGk
If you want to eat a banana before you singing go for it.
Things you eat or drink don't touch your vocal folds, so they aren't going to coat or otherwise mess with them.
My recommendations are drink plenty of water, avoid alcohol, and practice.
Another thing to avoid is extensive speaking. Normal speaking is surprisingly detrimental to ones singing voice.
Other folk remedies for voice include flat, room temperature Coca-Cola. I don't think anyone has demonstrated efficacy of any of these techniques, but another big factor in effective singing is mental state. If a placebo ritual helps get you in the correct frame of mind to sing, then it might just be worth doing. The destructive alternative is to get intoxicated before a performance.
While eating a banana should most certainly not result in a banana-grease coat on your vocal cords, it will be all over your throat. Might just be a little bit like hand lotion for it.
This is where it can be helpful to have some folks on your team whose primary focus is user satisfaction (and/or sales). They can help guide issue prioritization in a way that code-oriented team members may not.
Sometimes it can be frustrating to ignore a bunch of easy-to-fix issues, but often those issues have the lowest impact on the perceived quality of the software.
The article notes that the Nature Conservancy has helped them purchase lands for the project. I’ve been a fan of that organization for a while, they do a lot of really great environmental projects around the world. It’s nice to see them helping out with another important one.
Agreed. I've never had much difficulty finding software development work at smaller companies. If I have the required skills that they are looking for, I'm usually confident that I'll get an interview. An interview at a smaller company is likely to be much shorter and easier than the algorithm-based interviews at larger companies. The chance of an offer is also much higher.
The pay at smaller companies is still good enough for you to live comfortably, even at the entry-level. I worked a software development internship half-time while going to college, and it was easier and more enjoyable than all of the non-programming jobs that I did before that.
If you can't get a job at the companies that you want, you have no choice but to settle for something else until you have the experience and knowledge that is required.
Thinking some more on it, there is another (long shot) way to get hired at a large company: start your own software company that is eventually acquired by a large company.
> start your own software company that is eventually acquired by a large company
Just a heads up, that isn't how it works. If you've built a product that's good enough to be turned into a company and be bought by google/ms/etc, they don't want to hire you. They want your product. If they hired you, you'd steal away their workers to make another startup. At least that's the usual line of thinking.
Source: this happened to 3 friends of mine, whose companies were purchased by Google, Amazon, and Microsoft. Working around startup folk, this is a common story.
Too quick to generalize from your exp; brother founded a company w product good enough to get noticed, but it was an aquihire situation; FB wanted him and his cofounder, not the product/IP.
I paid twice as much for mine when it was the latest model (I got few upgrades, though). I'm pretty happy with the T480 overall, but if Lenovo releases another T-series with a significantly better CPU then I'll probably get it. I didn't think that I needed the dedicated graphics card, but now I think that having the additional cooling would help.
Functional Programming fundamentally changed the way that I solve problems. It also changed my expectations for how code should be designed.
The concepts that influenced me the most were immutability and the power of mapping+filtering. Whenever I read a for/while loop now, I’ll attempt to convert it to the FP equivalent in my head so that I can understand it better.
map and filter are not concepts of FP - they are just syntactic sugar around for loops. fully evident if you check any native source code. many languages (such as go which I currently use) do not even have these functions but can apply FP. this is by design of simplicity and visibility: it does not get much easier to read than a simple for loop and know the exact iterations count at runtime.
They are not equivalent - for loop prescribes the ordering of processing, but map and filter can work in any order. They are often associated with FP because to define these operators, you need to be able to pass functions as parameter to other functions, which is a thing that surprisingly many languages struggle with.
Which part of the "bad code?" The actual line that failed? The code that called it which didn't check a return value? The code below it that always returned the same value regardless of success or failure? The fault in the OS that allowed a race condition because it didn't lock processes properly?
Or did the failure happen because the code that was written for an 8-bit controller is now run on a 32-bit controller and no one realized that?
Perhaps you'd want to bring in the Test Engineer who verified that the particular feature passed? Why didn't they do their job? How about the Senior QA Engineer who wrote the test cases?
Do you also want to know who wrote the Requirement that the code met? Maybe the code did exactly what the Requirements said, but the Requirement was poorly written.
Point is, failures have to be analyzed on a Systems basis. Simply looking at a line of code can be completely meaningless and miss the big picture. And yes, each of the above failures is something I've come across in my career.
There are a few reasons to not rely on unofficial forks. The chance of malicious code is one. Also: unwanted changes, missing updates, maintenance confusion...
These issues already exist in the world of open source, as you note, and the only way that I know of to stop it would be to have a more restrictive license (and to pursue any violations).
