def L(*vargs):
return vargs
>>> stuff = ['c','d','e']
>>> L('a','b', *stuff)
('a', 'b', 'c', 'd', 'e')
1,083 karma · joined August 12, 2012
def L(*vargs):
return vargs
>>> stuff = ['c','d','e']
>>> L('a','b', *stuff)
('a', 'b', 'c', 'd', 'e')
I always wondered if it still sounded natural, or if there was some kind of comb-filtering to the vocals that just didn't matter due to the style and volume of the music.
I've played with multiple out of phase mics myself (to try and reduce drum bleed from the main vocalist mics) but never found it as effective as I'd hoped.
I think the problem was just how stinking loud the ambient drums just in general were to the room. Maybe outdoors with a bigger rig it would have worked.
Still pretty fun to play with though.
There's so much mad stuff you can do when you start playing with out of phase mics, delay, etc. As a party trick I occasionally pull a mic up to the point of feedback, whistle until I have a stable loop, and then can whistle in harmony with myself.
You can tell what kind of parties I go to...
You hardly ever pan main vocals anyway, so you're normally using your stereo pair to produce a mono sound. In other words, both speakers are producing the same sound at the same time. Since hardly anyone in the audience is an equal distance from both speakers, they'll hear a messy comb-filtered version of the main vocals, rather than them cleanly.
You can make a very good argument for not bothering with stereo at all for live sound (except for effect stuff, but then we're back into separate-pa-for-each-instrument grounds...). The trouble with that is how much harder that is to rig. If you're stacking stuff on the ground at all, then you can't really stack center stage, you need to stack to the sides. (Or behind the stage, with all the feedback issues that involves). If you do fly your PA, then you still need legs, usually. And a big PA is stinking heavy, and flying it near the legs is a lot easier than near the middle, due to lengths of truss, loading points, etc.
I've never tried it personally, but people who's ears I trust all say that besides all of that, just using a secondary sound system for vocals still makes them come through a lot clearer and everything sound better.
One possible reason for that is that a speaker is essentially just a paper cone with an electromagnet on it. There are physical limits on what that one bit of paper can do in terms of vibrations. We like to pretend the world is a lot more digital and measurable than it really is. By separating out the vocals from the other instruments, you allow the speakers to only move when the vocalist is singing. I can see why it could be cleaner. I believe the Chilli Peppers may be doing 2 PAs at the moment splitting off the vocals to their own mix...
You'll still always need a good sound guy, and you'll still need somehow to control the (vocals:instruments) ratio in the audience.
Ideally, bands would think of the sound guy as a member of the band. Kind of like the conductor of an orchestra is a vital member of the orchestra. A good sound guy is very similar. A bad sound guy has all of the same control, but none of the feeling.
Saying a PA system 'just sucks' is a bit of a blanket statement. Given how incredibly complex audio actually is, and how little people want to pay, it's sometimes surprising it works at all.
(I'm not trying to be defensive here, or argumentative, in case it sounds that way...)
Yes - a lot of PA systems are cheap, nasty, and stupidly designed, but quite often they're fine - just our expectations of what is possibly with them is somewhat against physics.
Bass is pretty unintuitive. Due to the very long wavelength (100hz is around 10ft give or take), if you try and use a stereo system to produce bass frequencies, you do get all kinds of troughs and peaks where the system ends up cancelling things out. Peak sound from one speaker reaches a point in the audience at exactly the same time as trough sound reaches that same spot, and the sound is cancelled out. Half a meter away in one direction, you get both peaks, and they add together, and half a meter in the other direction and you get something else weird. And this happens differently with every single frequency. Above 200-300hz or so you stop really noticing it, but below that it's horrible.
A lot of that can be solved by using a single point source for subs (bass), thus the 2.1, 5.1, etc systems. (The .1 means a separate bass subwoofer).
The trouble with doing that with a large enough system, is that you now have phase issues between the subwoofers, and the mains.
Say your subwoofer is set to only reproduce sounds up to 100hz, and your mains are set to only produce sounds above 100hz... You still have an area where both the mains and the subs are producing that sound. It isn't a binary state of producing or not producing sound.
So if the subs are (say) 20ft from the mains, (in a triangle configuration, with the subs on the floor) then you still will get phase issues with either full out cancellation in places, or else very messy comb filtering which also sounds crap.
Sound moves quite slowly (again, extremely roughly, 1130ft a second). So say a guitar is coming out of both mains, and because you're slightly to the right of stage you are 10ft closer to the R than L, you hear the sound twice, first from the R speaker, then 10ms later, from the L. 10ms is right on the border of you being able to tell it's a separate sound, so it doesn't sound like an echo, just a single slightly muddy sound, coming from slightly left of the main R speaker. (Wikipedia the Haas effect, if you're interested). This is one of the problems with stereo sound for a big live PA - only very few places in the audience will actually be able to experience the stereo effect - most will only get mono, realistically.
In a small domestic system where the mains are only a few feet from the sub, you don't notice it. In a big set up, you do.
You can get around a lot of that by flying your subwoofers. But then, as you don't get the 'floor carrying the bass' effect where the sound is literally moving along the ground, you need to use much more powerful bass amps and speakers to get the same kind of feeling.
My preferred solution is called 'aux fed' bass, where you send sound to the sub(s) from a separate mix than the main L/R speakers. Then I'll send the bass, kick drum and perhaps a few other things directly to the subs, and nothing else. This has many advantages, you get a lot less of the 'pop' sound from microphones when people are talking, the bass tends to sound a lot cleaner (as the speaker isn't vibrating along with every other sound), etc. However, it's a lot more complex to set up, and if you're playing back backing tracks or pre-recorded music that isn't mixed for it, it'll usually sound quite messy.
This is where the separate PA per instrument thing can help.
The trouble with that is how complex it is to control, how much space it all takes up, sight lines, and so on.
The article really didn't go into how hard it is to stop feedback when your speakers are behind the mics. That's why they had all that insane multiple mics out of phase stuff.
That's why we normally put the main speakers in front of the stage. You want them as far away and pointed as far away from the microphones as possible.
But if they're in front of the stage, then you want them as small and out of the way as possible, so as to not muck up people's sight of the stage / screens / lighting, etc.
At the end of the day, live sound is all about compromise. There are no perfect systems, rooms, bands, audiences, or engineers. If possible, we try to make as many people happy as we can. If that includes whoever is paying us, that's usually good. If it includes the band, that's even better. If it includes the audience, well, that's just a bonus, really. :-) (It'll probably never include the sound engineer. We're all grumpy old sods and never happy).
It's the editor which has frozen, not the whole computer. And the plugin in question is a fairly complex autocompletion / analysis plugin for python. There's a bug listed in that thread, to do with it scanning all the files millions of times, but the big problem actually isn't bloat, in this instance, it's the non-async nature of vim. neovim should, I hope, solve the 'totally unresponsive' problem, and hopefully someone fixes the rope/vim interaction re-scanning all the files bug.
But it's not bloat, per se.
If your whole computer is locking up due to this, then that's a scheduling issue, and you could try switching scheduler, or lowering the 'nice' priority of that program.
Not that we should have to care about such things - that's pretty terrible.
Write a production-ready library in a language you are interested in, complete with unit tests, follow best practices, write a set of good documentation, etc. for it. Put it on github, in the language's package management system, and see what happens.
Finishing stuff does really feel good.
John Carmack:
> >An imperative API makes functional abstraction harder. What are the main selling points for Scheme/Racket now?
> I am a big believer in functional programming (and static types) for large projects, but there is an undeniable bit of awkwardness compared to just imperatively poking things for small projects. That is one of the wins for Scheme -- I can make it super-easy to get easy things working, but it isn't just a "scripting language" unsuitable for large scale development. I am going to have to sort out my Racket / Chibi module strategy sometime soon, though.
> As far as language choice goes, I don't claim to have broadly evaluated every possibility and chosen the optimal one.
> Java or C# would have been more familiar to a broader base of game industry developers, but I really didn't want to drag in all the bulk of a JVM / .NET system, and a class focused world view seems less suited for the smaller scripting tasks.
> Javascript would have been more familiar to a broader base of web industry developers, but I have basically no experience with javascript, and little desire to explore it (which is admittedly a fault of mine).
> S-expression reading and writing is a strong factor for network communication, and I like the fact that there are available options for Scheme to interpret / compile / compile-to-C. I can see valid use cases for all of them, and I'm not sure how important each will be.
> The bottom line is that I have been enjoying myself working with Racket / Scheme this year, and I have evidence that it has been objectively productive for me, so I'm going out on a bit of a limb and placing a bet on it.
> >Initial impression: 7 years after starting to program in Racket, it still surprises me how easy it is to do something > >useful in just a few lines of code.
> A big goal here is to make the authored code very clear and simple. I may yet get to a single #lang vr <ip address> declaration that gets rid of the boilerplate at the top and bottom of the file and flips the right switches to make Racket closer to R7RS.
> There are sets of creative-types that are learning how to put things together in Unity to accomplish fairly simple media related tasks. I think I can make it easier for them with very domain specific helper libraries and a little bit of scheme.
We found European home educators are often much more "anarchist" in the sense of this article, liberal, free-thinking, non-conforming, often of non-traditional religion / spirituality, who think the state system is too narrow, limited, and structured. In the States it's much more right-wing religious exclusionists who think the system is too liberal, unstructured, and ungodly. A very very weird difference of culture.
My mum wrote a lot about home education, here's her site with all kinds of info about getting started, details about what we did, etc: http://home-ed.info/
I loved it, and it was perfect for me. My brother loves regime and structure, so would probably have done fine in school. I'm much less academic, and do a whole mixture of jobs (acting, teaching, programming, writing, A/V, electronics, etc.) in a non-profit organisation. Almost all stuff that I learned as a kid, with the oceans of free time that I had, and my friends in school didn't. I worked in a theatre company for 3 years, and did school-work in the evenings, or when I had time. I taught myself to code.
With our kids now, my wife (non-home-educated) is a bit skeptical of her ability to home-school. Our son is still too young (he's one). I certainly wouldn't object to him going to school - providing it doesn't interfere with his education too much. :-)
Segregation and discrimination are far away from any of the teachings of Jesus. He partied and hung out with prostitutes, tax collectors, and other social outcasts of the day. He was killed alongside thieves, and spoke to them without disparaging. He, as a Jew, travelled to the Samaritan towns (a people-group treated apartheid style by Israel back-then), stayed with them and treated them as equals. He spoke kindly to a woman caught in adultery that the community wanted to stone to death, and through his response to her, saved her life. He treated all sin (falling short of the intended perfect standard) as proving us all equally fallen.
His teaching boiled down to: All people are broken, and failed. No-one is better than anyone else, and any 'self-righteousness' you may think you have because of your religion, or background, race, whatever, is of no value in the end at all. But God still loves us, come back to him!
The Pharisees (essentially the fundamentalist evangelicals of the time) and other religious leaders slammed him for this, and it was because their power over the people being challenged by him that they ended up conspiring to murder him.
Please don't take the rude, abusive, hurtful, bigotted and unwelcoming attitudes of certain people who call themselves 'Christians' to actually be values originating in the teachings of Christ.
There's a huge difference between active and passive experience. Listening to a lecture is a passive experience. Asking questions is an active one. Watching TV is a passive experience. Playing a board game is an active one. The exact definitions can be a bit hazy, but the major concept should be fairly clear.
This is why in longer training courses / workshops run for a bunch of people from different communities, rather than from an already established one, there's often an 'icebreaker' game which is interactive and requires active participation, rather than just watching a funny cat video, or listening to a talk straight away. Even if the game is a little bit boring, or if you don't remember anyone's name, you have now all got at least one shared active experience, and a (slight) sense of community. If there's already a sense of community, then this is less needed, obviously. This sense of community is then useful for getting people to offer assistance to each other, be more likely to ask questions, make team discussions / activities later on much more interactive, and so on.
It's why there is a sense of community on slashdot, here, github, etc. and many many communities on reddit, youtube etc. but bbc, cnn, amazon, netflicks, etc. don't (much). Even if many many people watch BBC, or the same tv series on netflicks, and spend hours watching the same content as other people there, there's very little active participation. Often any active participation is lost amongst all the other noise, rather than becoming a shared active experience with other people. 30 people watch a glove and boots video, make their own responses, and watch each others videos, and maybe make responses to those responses. They will feel like a community. 300000 people watch it and 'like' it, and then go on to watch a video about kittens, and maybe like that too. They may enjoy their time, but won't feel like a community.
A sense of community is far more developed by the shared experiences together, rather than just the similarity of past culture. I always had a very strong sense of community with the people I did my initial training with, and the people I worked with every day. Much less so with the people from a similar culture.
I'm currently living in Carlisle, in the North of England. Very mono-cultural, very white, working class, etc. There's really not a lot of sense of community at all. After the flooding a few years (shared experiences) there was. But here now? No. Most people just sit at home in the evenings watching TV, and never do things together (much shared past / culture, they often watch the same shows, but no shared experiences, so little sense of community).
My wife and I work quite hard to deliberately develop community, inviting people over for meals, (board-)games evenings, barbecues, etc.
But the thing is now, you have to be deliberate about creating community. It's no longer automatic.
Personally, I blame TV hugely. It's far too easy these days to spend all ones free / down time disconnected from the people around you. The internet just continues the trend.
In our organisation, on board our ship(s) ( http://www.logoshope.org/ ) which doesn't have TV, when people started having their own laptops that were able to watch TV series and movies on, we saw a huge shift in community, from people in free time hanging out together and talking, playing games, exploring, etc, to people sitting on their own in their cabins playing computer games, watching TV / movies, etc. And the sense of community suffered.
[1] http://streetsign.org.uk/ [2] https://bitbucket.org/dfairhead/streetsign-server/src/5b359a...
My reinterpretation was to say how about factoring out the server part, and leave the command only understanding either flags or protobuf commands - which could be delivered to the command either as an arg, or as a file given to it by an arg.
You could go a stage further by having all commands only accept protobuf (or similar), and distribute a spec/human-mapping to go with it. Then your shell would parse the args that you give to the command using the spec, and actually call the command using protobuf.
This would allow very awesome shell completion / highlighting / etc. It should also allow much simpler end-point/commands, as they'd not have to do hardly any type checking / re-parsing, as it would arrive in protobuf.
I actually kind of like that idea. Hmm...
tape_robot start -tapeid=1
tape_robot --protobuf 'msg:start;tapeid:1'
tape_robot --protobuf_file filename
proto_serve tape_robot 127.0.0.1:8080
This (to me) is closer to the unix idea - one server program, one actual processing app. Why should my tape_robot program actually have a server embedded in it?
If in the future, I want to add authentication, I only have to add it (once) to the proto_serve program, rather than to every single application that is a 'server', for instance.
It would also allow a version which 'pre-forked' the processes, and left them waiting for the data on the socket/filehandle, or whatever.
You could do a bunch of this already using nc or similar, I suspect.
There's probably a plugin which lets you do this with a single toolbar button...
OK - now with a stack.yaml file it's busy getting me a ghci...
cabal hell was one of the first things that really put me off haskell. I was downloading and trying to get xmonad working, but within half an hour, had a completely unusable ghc / xmonad combination. I think I was on debian, and the version of ghc that was installed wasn't compatible with the correct versions of various libs that xmonad wanted to have installed... Very frustrating.
Well, looks like installing stack does at least allow me to get a ghci up and running. That's cool. The easier getting haskell up and running becomes, the better. It's a wacky and esoteric language enough without it being hard to get going...
Interesting how programming languages "need" their own package manager these days. A bit of a pain that there's no universal one for all languages, but I guess that would be just too convenient...
Purity is pretty awesome. I really like conceptual Haskell (actual real Haskell tends to become too abstract for my brain to remember important details when I come back to a project...).
The (sad) fact is that mutating a bit of state is actually often much faster, or a lot cleaner to read / understand than implementing a fully pure functional version. And by limiting access to state, you make sure you don't accidentally introduce dependencies.
Using closures like this, can end up being very similar to object-oriented code (in the best-case, strictly limited sense) whereby each area of concern in the code can only modify what you expect it to be able to modify, and you can be sure nowhere else in the code can access it.
function make_counter() {
var i = 0;
return (function() {
return i++;
});
}
var blah = make_counter();
And, as a human nature hack, marketing them as tools for world-peace, etc. makes them much more likely to be adopted by idealistic humans who may have the motivation to actually test them for a few decades...
Once a project is big enough, then sure, drop the language stuff down to page 3 or whatever. But until you've got a community of passionate developers, it's a key concern.
IMHO.
Already, anyone seriously using pylint or other "normal" python linting tools uses comments like that to give extra hints to the linter:
def blah(): # pylint: ignoresomething
check out rsync's "--link-dest" option. It's amazing.
Alternatively, this is one thing that version control could help with. Set up a cron job to check for changes every day and commit if needed.
1) Users want to be able to update site-name (etc) from the admin interface.
2) We therefore need to store it somewhere.
3) We have a database!
The alternatives are:
- Storing in wp-config.php (which is also done...), but then it's not user-editable from the admin interface.
- Storing in a INI or JSON or similar document, which has only marginal if any benefits over storing in the database.
For deployment, since the location of the database values is fixed, you can set the variables with your deployment scripts.
The one killer feature that would make me move almost straight away would be making it a lot faster.
But since I have pypy, I'm much more interested in installing that as my 'extra python version' than I am in going to 3.x straight away.
One could hope that with many of these utils they're mostly IO bound, and so a scripting language wouldn't change that much. I know at one point I actually had a python based md5sum that was faster than the regular gnu one for big files - as it loaded the data off the disk in huge chunks.
I believe ack-grep was written in perl? And that's pretty fast.
Also - how fast does it Actually need to be? It's not high-frequency-trading or a 60fps game... A computer these days can probably load perl, run a script, and display the output faster than a computer from 20 years ago could run the original c util... And if everything is written in it, then a lot will be already in memory. If your shell is written in it too, then you could just call the utils from within there, rather than having to fork/exec it anyway.
For most higher level scripting languages (such as perl, python, ruby, etc). Things like regexps and hash tables are written in c underneath anyway.
With a lot of shell scripting, you call many many utils many times - which would slow everything down hugely if you needed the scripting language startup costs each time. However, if you use the same higher-level scripting language to write all your scripts in - rather than writing SH scripts that call your utilities, then you might even get faster than SH calling external utils (possibly). (If that makes sense...)
It means you can modify any of them just as easily.
I remember one time when I needed information about how much CPU usage a program was using, I could see it in the output from `top`. So to figure out how `top` was getting that info, I had to download the source code, and grep through several .c files. If I could just `vim top`, and read the code, it would be very cool.
As an educational resource, being able to tell all your students "all binaries in /bin and /usr/bin are editable! Read them! Find out how they do what they do!" would be incredible.