Well I'm Interested in the Idea of Programming

:D

I did a little research into low-cost op amps for general low-to-mid-fi audio stuff.

Quick conclusions:

RC4558 is actually alright for general use.

Ye Olde TL07x works well as ever.  TL08x is fine, too. Can’t go wrong with a pile of these things. Both are popular, and at mic level audio more than serviceable even for single supply circuits. They will work well enough for things like guitar effects, though don’t have enough lower-rail headroom to use in 5V single supply circuits at line level.  They do work at mic level at 5V SS, at least.  I’ve tested them.  They could be considered a reference point.

The TL07x and TL08x are very hard to beat for slew rate at this price point and GBW, but when it comes to single supply circuits that hardly matters since you only have about 4 Vp-p to work with anyway, and that’s already twice line level. In dual supply, though, they are hard to beat as general purpose op amps.

MCP628x and MCP60x would have been better single supply chips to start with for my project.

Dual supply chips usually eat around 2~4 mA per amp circuit.  Single supply, mostly from Microchip, seem to eat around 0.4~1.4 mA per amp circuit.  Use single supply if possible. (And don’t connect your virtual ground to ground.)

Not so quick conclusions:

For mic level audio, basically any op amp with a sufficient GBW will work, though some may be noisier than others.

Most op amps work well enough for line level even on a 5V single supply.

Prototype power regulator (5V, 2.5V Virtual Ground, and Ground) and Mic Pre-amp.  Still need to test for continuity and shorts...  The wiring on the power side got a bit wonky because Fritzing’s 5V regulator has the ground and input pins swapped.  I’ll have to fix that some time.

I made a simple baxandall tone processor.  I didn’t have a 47 nF cap on hand, nor a second 100k pot.

One of the (many) reasons for a huge delay between posts has been various cases of having to relearn how to achieve certain ends in a functional language versus in an imperative one.

I wrote a little demo in order to learn how to actually wire things together and execute Tasks, as well as how I might create a Service that could be used through out an app. I learned a few things during this process.

Although Native implementations are attractive from a re-use stand point, they're really fragile since they depend on compiler details.

It would be better to simply have a JS portion of the app that subscribes to a port and reacts to it.

A second exploration, forthcoming, will delve into how to use this, how it differs from a more Task oriented set up, and integration thereinto.

Thereinto is an officially listed word, albeit archaic.

How to actually wire user events through Tasks, into the evaluation pipeline, and finally take the results back into updates to the model.

The first item isn't really all that important, more just something to consider when creating services your own app will make use of. Elm-http makes use of a Native module to take care of actually performing the side-effect of trying to make an HTTP connection.

The second wasn't originally in this, just something which surprised me.

The third, however, will take up the bulk of this.

Digging into actual examples

Since I'd wanted to have some sort of Service which reacts to User Input and couldn't make heads nor tails of how to connect a signal of user Actions to services and back into updates, I decided to really dig into the examples of such interaction that were provided and rewrite them until I could understand them.

One of the examples provided is a simple ZIP code searcher which takes a valid ZIP code the user enters and sends a search request to api.zippopotam.us. Looking just at the imports didn't show anything particularly interesting, not that I'd expected anything there, but this was a close-grain search so I had to check anyway. The rest of the app was split into View and Wiring.

The view itself didn't show much aside from using the more generic on rather than on{Event} thing, perhaps due to listening for input DOM events. Upon the event firing, a message would be sent to query.address, so looking at query (which presumably is a mailbox) would be a natural place to start in the following section, the Wiring.

The first part of Wiring is simply the main function, which of course has the usual type of Signal Html and although the use of Signal.map2 is odd, it's not too far out. The view, it should be noted, takes as arguments a String named value and a Result String (List String) named result, rather than the address and model seen in fuller App examples.

The second part is where we will start in, since that's actually the thing we were looking for: the query mailbox. We can see it's a mailbox of strings, which makes sense if it's receiving the values of the text input. We also see just below it the results mailbox, but we'll mostly ignore at the moment, merely noting it's there. The thing after that is the interesting part, since it's a port.

The port here is annotated port requests : Signal (Task x ()) and given the definition of port requests = Signal.map lookupZipCode query.signal |> Signal.map (\task -> Task.toResult task `andThen` Signal.send results.address)... Oy vey. Even rewriting the |> out of there doesn't clear anything up. What the hell are any of the types?

One thing that will save you some confusion is to note that Task.toResult has the type Task error value-> Task x (Result error value) and it's not some magical Task to Result converter, just a re-wrapper, thus allowing the use of andThen as-is rather than with any additional functions around its use.

At any rate, I'd tried dissecting that port line for awhile and couldn't make any headway, so decided to just start rewriting parts to make it clearer using what I knew to transform its current form into something more verbose, but more understandable, mostly by breaking the parts out into temporary values in a let in statement, resulting in this fatter port definition. This has the same end result, all of the same processing, but lacks the confusing all-in-one-ness of the original.

Now it's easier, not necessarily obvious but still easier, to see that we're starting out with the query.signal from earlier and mapping a function lookupZipCode across it, which thus becoming a Signal of Task String (List String) (or whatever lookupZipCode returns, it doesn't really matter to us here.) Then, the lookup zip code Tasks are turned into Results and sent off the results mailbox. While this is eventually apparent when looking back at the original, it's not initially clear to a newbie how it works, leading to this sort of rewriting becoming necessary.

And while we're on the topic of rewriting, let's rewrite the above description to be more "functional" in nature, because functional programming deals with "things" not "commands", or "nouns" and not "verbs".

We start with query.signal, a Signal of query Strings, then get a Signal of Tasks by getting a Task representing the zip-code lookup request for each query String, from there get a Result of that lookup Task, and finally get a Task representing the process of sending that result to the results mailbox.

Reading a bit more deeply through Dreamwriter, only its UI is written in Elm while the rest (App Logic) is written in CoffeeScript. it has numerous ports, one for each possible thing that may have to be performed by the App Logic. Thus only the App Logic itself actually does any interactions with the outside world while the UI merely manages the sundry inputs to draw the UI. This doesn't answer everything, but I do think it will at least prove useful in the background melange.

I decided to finally look at the mailing list because presumably I'm not the only person having trouble with this. Someone named Sridhar wrote up a long and winding (in a helpful way) post which itself iterates upon the very important concept of modeling things as data flow, not as commands, and on the fact that because of Elm's Pure, Mostly nature, it does not actually do anything that is sent to a mailbox.

Anything which affects, triggers effects in, or handles effects of the outside world most eventually flow through a port. That annoying thing which I didn't understand until now. I probably still don't understand it, yet, but I'm in a better place thanks to Sridhar.

A port which is a Signal of Tasks will actually have those tasks executed by the Elm run time. Even the Http library works this way.

Although I didn't notice this at first, looking in the module Native.Http, I see now that the send function doesn't actually do anything immediately, rather it returns a Task.asyncFunction, which itself actually executes the HTTP Request when it flows into a port.

Thus, even using the established libraries, and even those with Native parts, Tasks are only ever actually executed when they flow through a port.

As stated in Sridhar's post (and numerous times on the mailing list by various people trying to help nubs like me) a Task, as defined in Elmland, is not an actual execution unit that is happening, but rather the it is the description of an action that will happen at some point. Even the native JS side of a Task is a mere statement of what will happen, not what happens immediately. This was actually stated in the Reactivity tutorial, too, but I think that the tutorial is written from the standpoint of someone who's been in Functional land for a long time. Sridhar's post went a very long way to helping me begin reorienting my brain by providing a lot of useful background information and a bit more repetition of basic facts.

Edit: Thinking about it, there's one case in Elm where you don't use ports: Reaction to DOM Events. These seem to magically occur, but then they already have premade signals so I suppose that's fine. Or perhaps it should be stated that as Elm's primary purpose is to be a UI language, not a general purpose language, the implicit creation of Signals of various UI properties is something we can live with. Or are just assumed to be a given of the language environment. Something like that.