nutate

Interesting article, although the LC circuit (resonant low pass circuit) is something I would teach my students as a phys lab TA, I feel like the key is the inductor and the cap more than the pot. The issue with the MRB costing more was that the switch in the MRB was to switch between 3 different cap values: http://www.voxshowroom.com/ct/amp/us/features/mrb.jpg which would be expensive. The wah circuit changes the amperage (current) to the cap instead, making it act like a different value. (explained here: http://www.geofex.com/article_folders/wahpedl/wahped.htm#wha... )

Also a side note, if you want a variable wah without the footpedal you have a couple of options: http://diy.smallbearelec.com/Projects/WMouse/WMouse.html or build an envelope follower (which is neat because it triggers off of the amplitude of your signal, aka how hard you are strumming, which is nice for people w/ bad foot coordination) with a settable Q/freq: http://buildyourownclone.com/products/envelope-filter-fixed-...

Other neat innovations: zvex wah-probe (theremin circuit controlling the wah freq) and the zvex seek wah (a sequence of different wah settings you control). anyway, wah-wah's are fun and chances are if you did a set of physics electricity labs you built one already, just without the transistor choking the cap.

matlab was originally released as a fortran library (pre 1.0), so it keeps a lot of that heritage even though it's probably c/c++ now: http://www.mathworks.com/company/newsletters/articles/the-or...

Yea as someone with a PhD in Materials Science, I'd say nanotech rules everything around me. :D

This is somewhat similar to the streaming producer/consumer from another rust crate: https://github.com/Geal/nom perhaps they could be interoperable.

Interesting sub turing complete language:

https://github.com/ainfosec/crema

Missed in the media frenzy is that at least one company has offered a complete ECU upgrade for VW/Audi TDIs for a while: goapr.com ... plus homebrew. And VW never sicced DMCA on them.

The tie ins with the google dataflow paper are at least superficial (if not deeper on deeper reading) in that they mention: "latency, correctness and cost" as their drivers: http://blog.acolyer.org/2015/08/18/the-dataflow-model-a-prac...

Community Edition is still totally awesome for what it is right?

sooperlooper is such a solid program. Awesome use and smart to not reinvent the looping core of the system.

Unfortunately this article doesn't mention his books Mr Wizard's Supermarket Science, which I had as a kid and it was pretty awesome: http://www.amazon.com/Mr-Wizards-Supermarket-Science-Herbert...

He also authored a few more books:

Mr Wizards 400 Experiments in Science http://www.amazon.com/Mr-Wizards-400-Experiments-Science/dp/...

and http://www.amazon.com/Mr-Wizards-Experiments-Young-Scientist...

y'all are doing awesome work. can't wait for the official launch when it's ready. but it's clearly pretty darn ready now. :)

Definitely control flow not data flow, but the data is defined at each step of the graph in variables like normal. In Frank McSherry's Rust stuff and the Naiad stuff they seem to have a basic data structure of progress and "data to process". Where progress is handling the time step of the process. The dataflow isn't anything more than a variable being passed around and inputs and outputs. So the control structure is the important part.

This is sort of rambly, but in pd/max/msp you end up with at least 2 types of data flow rates (common in musical stuff like supercollider as well) for musical sample rates (aka 44.1khz or whatnot) and 'control flow' rates (like an LFO wub at 120bpm half notes). Those are all still wired up with the same "lines" in pd so it can end up being confusing if you put a control rate into a sample rate or vice versa. I'm sure current MaxMSP has ways to separate and handle those (along w/ "bangs" which are one off messages), but the beauty of something like drakon is that it is just control flow. The data is explicitly defined in the boxes. So even though dataflow is the phrase google and microsoft are throwing around, the real art is in the control flow. Look at the scopes and contexts from the naiad paper: http://www.frankmcsherry.org/dataflow/naiad/2014/12/29/TD_ti... I think that drakon would be an interesting way to draw that diagram out. Not one hundred percent sure, but it's a thought.

Interesting how this could tie into the diagrams coming out of the dataflow paradigm (flumejava, flink, millwheel, naiad, and Frank McSherry's rust timely-dataflow). All of which can be succinctly diagrammed out, but I like the rigor of this. People in this thread have mentioned Max/MSP (it's precursor puredata/pd) are really interesting visually, but they often feel write only. Some of the rules of drakon could be attempted in a max patch, but the shortest path nature and lack of jump labels could foil the idea.

At any rate, some food for thought when it comes to trying to ideate programs away from a computer or at least away from a repl or IDE.

tcomb-form is the most elegant solution I've seen to this problem in React. Really nice to use.

If people could invent better moderation over nntp... it looks like people were looking at it even in 2010: https://tools.ietf.org/html/rfc6048

I had made a comment on twitter that the ref: concept basically throws json off the indecidability cliff in terms of parsing. They opened an issue for it apparently, but you can see the graphql rfc has specific anti-cycle checks, which is super important.

I definitely support this sentiment w/r/t the single threaded mindset of node and their async all the things approach. The only question with Go is if we guarantee sync libs, then where is the good async example code? I agree libraries should be synchronous, but does it really hurt to not have some best practices "how to do it async" in the docs? or should it be... in the code?

Kind of a meta question, but an interesting one.

You're perhaps confusing polyamory with polygamy/polyandry? To put it in hacker terms, polygamy / polyandry is forcing an edge reduction creating a hub and spoke architecture when the arrangement has to be a 1 to n-1 mesh. The equality of a mesh is an easy mathematical argument to make, but it isn't the argument polygamy/polyandry is making. Polygamy/polyandry is inherently unequal. [edit] to get the math right a polygamous/polyandrous relationship maxes out at n-1 contracts. Polyamory would be (n*(n-1))/2 contracts and I would argue for equality that if n changed all contracts would have to be retermed. Polygamy / polyandry is unequal. Period. It's a mathematical fact. Polyamory I could be convinced of the possibility of legal equality, but not for polygamy/polyandry.

That's a polyamorous (group) marriage, not a polygamist one (at least as per my definition of those somewhat amorphous terms)

That said all of the legal agreements become far more complicated and likely null and void if one person drops out or is added. I think an argument could be made, but with the complication you're basically saying polymarriages would be like corporations, with their associated complexity.

Polygamy as practiced now is a "bring more childbearing women" into the flock type thing, which is by nature non-equitable. I doubt most folks in a polygamous marriage (by choice) would want to get involved in a polyamorous marriage and as such, I think you can't legally support a non-equal union of that sort.

How could it be consensual between all adults? The marriage "license" in polygamy is between man and women, yet by secondary effects the women are fully entangled with one another. Yet if you watch any show on polygamy you'll see that a guy will keep adding new, younger wives while holding their current wives hostage (due to their lack of another option in terms of housing, money, etc). It's absurd to think that any thinking person would get in on the wife side of the polygamy pact when in the end they have their equality divided by X wives.

Smart folks have said that the reason homosexual marriage even became a thought was because of the transformation of marriage from a bond of ownership of man over woman to a shared partnership. A polygamous arrangement (as per the mormon church, not the polyamorous relationships of the hippies, etc) ends up with a hierarchy of power with one man controlling multiple wives, with the power to divorce, ruin, etc the others if they don't allow him to wed again.

I think an argument for polyamorous marriage could be made, but polygamy is essentially a raw deal for whoever isn't the hub of the marriage wheel (one man in the case of traditional mormonism, islam, etc.).

Polygamy makes no sense from a power structure standpoint, it is inherently unequal. The man (generally) gets X women and each woman gets one man (the same man). If polygamy meant a web of relationships, where everyone was equally married to everyone else, that would be conceptually more fair, but as is, the power structure of polygamy as defined by the only religious sect with much influence in the US is an inherently less than equal partnership.

Not to mention most importantly JSON is firmly on one side of the undecidability cliff in terms of parsing limits. The nesting limits and length limits make parsing it safe, whereas a given binary protocol may have recursion or buffer size definitions which make for ripe security holes. (Even XML has parser bombs)

I always seem like a genius when I ctrl-q out of someone's inexplicably locked terminal. Lord knows I discovered it through some serious pain and wonderment.

Right now the fastest alternative to nltk is spaCy https://honnibal.github.io/spaCy/ definitely worth a look. I don't know what you're trying to do with the permutations part, but it seems like you can generate those on the fly through some reproducible algorithm (such that some integer seed describes the ordering in a reproducible way) then just keep track of the seeds, not the permuted data.

It does look pretty good on iPad. I guess we'll just have to wait for them to figure out how to release it for their... ya know, flagship e-reader.

Wow, looking at that it looks like my old (lost?) Peavey PC-1600 could send 14 bit messages. In the end I think a lot of the problem is also fixable with better interpolation and mapping, but I've definitely ended up sitting in the range I want on a synth mapping, but getting clicks when I touch a knob. Pretty interesting to think 14 bit midi has been around for so long but it hasn't really taken off. https://en.wikipedia.org/wiki/NRPN whenever I go into the midi standard I end up finding neat stuff. These days USB MIDI and bluetooth MIDI have also kept it alive while OSC is still lost in a web of standards all different, great for communicating when one dev is on the send and receive side, but bad for easy interop.

One could argue that it places necessary limitations on musical expression that allowed it to flourish. Defining scales, etc in the protocol left some issues w/ microtonal stuff. The timing protocol is a bit squidgy for beat matching, but if you look at OSC everyone creates their own namespace and instead of one protocol you have a bunch of devices with different mapping conventions.

I would say the 0-127 range of controls hurts midi more than anything, if someone just bumped midi to osc's range most people would be happy. HD MIDI does that and may end up usurping OSC before OSC even gets traction: http://www.midi.org/aboutus/news/hd.php

Heh. This is fun.

mild wub: http://resistorsings.com/106/#patch/mildwub?vca-level=0.4840...

Definitely want to check this out. Did they redo their site post F8? I had talked w/ some FB devs at the react conference and one said that the code review process at FB was the #1 thing that made him a better programmer day in day out.

Gogs is interesting but it doesn't have a full pull request workflow built in. It runs on super small hw requirements which makes it nice if you just want to use it for yourself.