deckiedan

A drum kit may well have 3 or more mics able to "hear" each drum. The direct mic on the drum, possibly a phase reverse mic on the opposite side of the drum, and any overhead mics. Also, any nearby vocal and other instrument mics (if the drums aren't inside a massive isolation box), etc...

And then the speaker distance and direction come into play. Any stage monitors ("foldbacks" in UK English) are usually pointed back at the drum kit - but aren't silent in their reverse (eg towards the audience) and so their sound will be out of phase with at least something. Then the distances - the sound from the drum will be (given a stage size of a few metres) several ms delayed actually getting to the audience. How far are the speakers (and subs) from the audience too? And since subs are almost omnidirectional, what about spill from them back into mics on stage?

Also, if you're working with digital mixing, you have a few fixed ms implicit extra delay everywhere... So getting the mic and drum head to "actually" move in sync is... Unlikely. But then again, with digital you usually have delays available on every channel and can guddle around with that until it's sounds good enough...

Messsssy. In-ear-monitors can help a lot keeping the stage sound cleaner - but all IEMs I've used introduce some more delay, due to processing, analogue-digital-analogue conversion, etc. Which is only a few ms, but for a vocalist, can give the unnerving experience of feeling like their voice is coming from a couple metres away. (Technically the same as coming from a stage monitor, but when the sound is right inside your ears, it can freak some people out).

Live sound is fun! It's all compromise, all fighting the tensions of time against perfectionism against theory against budget against the show must go on, and keeping the musicians and audience happy.

That all said, in my experience, often phase things can be fixed by either flipping phase, or moving a speaker or mic around until it magically works...

It's a convenient collection of a whole bunch of short books.

I'd think reading individual books would be a better approach.

Story books: (written as narrative, can pretty much be read as is, just with lots of historical context need for some "wtf?" And "why is that a good thing?" Moments) Ruth, Esther, Jonah, possibly Mark and Acts.

poetic stories: ( narrative content, but expressed in Hebrew poems, so form and patterns etc more than just reading for the story) parts of Genesis, Job, parts of John, and Revelation.

History (biased, but still intended to be read as history, contains lots of individual short stories): Parts of Genesis, Exodus, Joshua, Judges, The Samuels, Kings and chronicles collection, some of the prophets, Luke, Acts...

"Wisdom literature" / poetry: Psalms, Proverbs, Ecclesiastes, song of Solomon...

And a whole bunch of prophecy, laws, other stories, collected letters to people, and a whole bucket of misc.

Genesis & exodus, as a "ancient Israel primary establishing narrative" maybe a good start if you want to read a whole bunch of the Bible. But then skip and read some stories from later on in Jewish history, try reading some of the more famous Psalms, perhaps with some of the commentaries about them, to see what people believe the meanings behind them are, etc. Checking out some "Bible history timelines" may be helpful too, to get a grasp of when and why different bits were written, and to whom.

Reading about Jesus' life, the four gospels basically cover the same stuff, but written to different audiences, with slightly different emphasis (writing to Jews who knew their religious history, compared to writing to non-Jews living in Roman context who were still investigating this new thing, etc). John is kinda poetic, Mark is all about the action, Luke is trying to be methodical, and Matthew brings in a lot of expected past knowledge of things)... Reading them and comparing them can be interesting to see the different perspectives, but any one of them is enough to get the basic idea.

After Jesus, Acts gives the continued story, what the early church did. And then most after that is letters addressing specific people and circumstances. Reading them as "blanket rules for all ages" without knowing who and why they were written, knowing about the context, what was already the culture at the time, etc, makes them really easy to misread parts as endorsing things our culture does differently, compared to critiquing the situation at the time... I guess that's true of all ancient literature.

It has image loading / blitting on screen, etc, input, etc, and you can do a lot with it, but it will be all pretty manual. Which can be a lot of fun. But it's not a "framework" like django is a web-framework. It doesn't give you any higher abstractions at all (sprites, animations, objects, maps / levels, etc...)

I like it, for teaching my son to code, having fun hacking easy oldschool 2d games in it.

Another more "modern" alternative might be https://love2d.org/ - I've played with it a few years ago briefly, and may well look at it again some day. It certainly seems to have a more active community than pygame - but is `lua` not `python`.

Neither have the greatest distribution / mobile story in the world, there are... options... worth checking that stuff before choosing a system to build in if that's important to you.

100% yes.

Idiomatic would be (to me):

1. things which python does naturally - for instance list expressions rather than manual creation:

    managers = [
        person for person in get_all_staff()
        if person.has_direct_reports()
    ]

    managers = []
    for person in get_all_staff():
        if person.has_direct_reports():
            managers.append(person)

2. Things that Python makes natural / or less so - by the way it works.

For instance, because of the important whitespace, and no end brackets or `end` keywords or whatever at the end of `if` or function definitions, large nesting inside functions becomes very klunky to follow the logic. So idiomatic would be to use small named functions, and split things into smaller pieces once they become too nested.

3. Common patterns that many people do, or common functions. See the itertools recipies, for instance: https://docs.python.org/3.5/library/itertools.html#itertools...

Of course, one has to mention this:

> >>> import this > The Zen of Python, by Tim Peters > > Beautiful is better than ugly. > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > Flat is better than nested. > Sparse is better than dense. > Readability counts. > Special cases aren't special enough to break the rules. > Although practicality beats purity. > Errors should never pass silently. > Unless explicitly silenced. > In the face of ambiguity, refuse the temptation to guess. > There should be one-- and preferably only one --obvious way to do it. > Although that way may not be obvious at first unless you're Dutch. > Now is better than never. > Although never is often better than right now. > If the implementation is hard to explain, it's a bad idea. > If the implementation is easy to explain, it may be a good idea. > Namespaces are one honking great idea -- let's do more of those!

So things like readability beats conciseness, so a huuuuge complex list expression is less pythonic than a manual loop when it becomes too complex.

That's locally on a fast (ish) laptop. GH CI takes 10 minutes to run tests, so I'm a little hesitant to see how long mypy takes to run.

I feel like in 100 years time we'll have all these loopy pipe arrays all over the place being a pain to clean up...

I suspect you're trolling, but in case you're not:

As a European, I do have a lot of community centric philosophy - but given the government (local and country) incompetence in virtually all matters of education and the universally awful opinion all teachers I know hold of the government and their interference and policies regarding education and child care - I do not think that wanting the best for your kids that you love and wanting to be able to raise them yourself with individual attention and perspective is really that strange.

If there are good schools, I have no problem with my kids going to them, as long as it doesn't interfere with their growth and education.

(My kids go to local state schools, fwiw).

At least having another pair of eyes check text-only changes has caught so many typos, etc, and only takes a couple minutes.

I (wildly) speculate that once the ORM is async too, and all the rest of the bits fall into place (maybe django 5?), maybe django 6 will drop the `a` prefixes and integrate it all back together somehow?

Is there a "top 5 features" of 0.6? Seems like a million bugfixes and lsp/tree sitter tweaks... But what new things will come from here?

Often smaller installs / live events people want simple non-smart screens for all kinds of things (on stage, in waiting areas, musician cues, info to crew, signage, etc), and although it's possible to buy expensive "monitors" that do it - being able to use cheap and large domestic kit with much faster startup and no extra crap, and no logos being displayed while booting or if it loses signal or whatever would be very desirable.

They're really aware of the complexity of this - where they see the value of coaching as a tool, and know it's not a medical industry with the need for such high qualification time as eg. councellors or therapists, but that anyone calling themselves a coach means people do a lot of advice / self-help / general fluff without it being what they understand coaching to be. Getting accredited means having training, having certain number of logged hours doing coaching, recording sessions for assessment, passing an exam on ethics, limitations, confidentiality, methods, etc...

In the ICF understanding of coaching, a coach doesn't need to be a domain expert (although domain familiarity helps), as the coach's job is to help the coachee (client) be the expert / get unstuck / manage themselves. No matter how good a business leader I am, I'll never know your company and the individuals involved as well as you do. But if I'm good at asking you questions that help you see where you're stuck and see things in a different perspective, you'll come up with better solutions than I ever will. If I give you good advice, you'll see me as a guru or authority, and not build your own answers. And if you need a mentor, or advice, then in coaching that would come up and we could talk through ways you could find that.

(Disclaimer: I've completed an ICF accredited course, and am slowly working on my 100+ hours of coaching others and exams to be accredited).

    > The term hamburger originally derives from Hamburg,
    > Germany's second-largest city. Hamburger in German is
    > the demonym of Hamburg, similar to frankfurter and wiener,
    > names for other meat-based foods and demonyms of the cities 
    > of Frankfurt and Vienna (in German Wien) respectively.

It's not as quick as access to get up and running - but you get the benefit of it being a very well known and supported platform - any bells and whistles you want can be pulled in, you can deploy it online or on a raspberry pi easily enough...

It's really interesting to check out if you want something really powerful and able to hack stuff up quickly / differently.

And all the perl languages definitely have some of that "we code in C for boring stuff, but need something fun and powerful for what we enjoy" ethic.

There was a blog post at one point somewhere talking about a supposed divide between "East coast" and "West coast" languages, which I can't find right now...

[1] It was called "Perl 6" once upon a time...

Of course philosophy wants to argue it's purpose. Musicians could write a symphony to explain music, if they felt the need, and astronomers could draw a detailed map of astronomy and explain how fast the different sub fields were diverging based on their red shift and parallax calculations?

It took a while to get fast enough to be productive - it's a pain switching layouts.

The nice thing about using a kinesis advantage is that as it re-maps the keys in the keyboard, the computer isn't aware of keyboard mapping at all.

When I was trying out things like the typematrix or a MS keyboard that required drivers etc, it was always a pain getting things like BIOS passwords, login screens, etc. to work reliably.

react is a compiles-to-plain-js framework for building data heavy complex applications in the web browser.

React has its own template language built into your functions, quite opinionated data flow paradigms, and tries to abstract all of the direct attacking the DOM away into passing pure data around.

JQuery gives you better tools for hitting the DOM, but still is just a set of tools, not a development methodology.

This is simplified, obviously, but trying. :-)

Might help? Clojurescript, but fast start up at least...

I was thinking about using layers like you suggest for movements, but outside of vim where you need to shift+move to select text, isn't that going to be quite awkward?