Funky Music from Functional Programming - Computerphile 

Reference

11/10 reference

wohdin +

I'm interested with functional programming (Haskell) but still don't have time to learn it (and I'm still struggling learning with Python and Fortran though lol). I hope someday I can learn a thing or two about functional programming.

Yeah, I have to agree. The software he shows is nice but it can obviously also be programmed in most other (non-functional) languages as well and I would have instead really liked to hear a - maybe more technical - explanation on what the concept of FRP really is. If I didn't already know what a perfect fifth and a major third are I would have learned more about music than about functional programming in this video - but as it is I don't think I learned much.

I agree. However, it's unfair to assume he doesn't have a great understanding of it.

The purpose of this video wasn't to explain what frp is, they have a few other videos on function programming. This video, as the description explains, is simply to show a more hands-on example of something that could be done with it, as opposed to videos that just explain what it is without really demonstrating ways of applying it.

phiefer3 You can do anything with it. It's just one approach to solving problems. This video didn't even tie the concept to the demonstration well. But, my main complaint was that they specifically mentioned FRP and asked for an explanation of it in the video but that request was not met.

I'm not a native english-speaker but have no problem with understanding this video

we do.

Me too! I'm not a native speaker, so I can't understand a lot

thats racist

His accent is fine, clean the mud out of your ears.

put the video on 0.5 speed

He just has a very hard to understand accent.

Not yet, but it's a feature we're willing to implement ;)

Indeed. Meanwhile, as the application is MIDI-based, the generated MIDI data could simply be recorded using any kind of MIDI recorder capable of saving the data as e.g. a standard MIDI file.

Where is the source code?

Youness Amr knowing Henrik, probably Yampa.

second life lol

I guess you could use STG (from GHC) to generate assembly for the actual logic, but you'd still need a layer for VST/AU plugin that you can run it on. Shouldn't be impossible, but certainly more complicated than writing it in pure C/C++.

Not sure how feasible it is to actually turn the application into a real VST plugin. Would certainly require a fair bit of work in terms of library bindings etc. if it is feasible. That said, it communicates over MIDI, so it can be interfaced to any software/hardware that "speaks" MIDI, including pretty much any DAW. RIght now, it uses JACK for MIDI.

It's actually about the program, not about the sound. If you want to hear the sound, download the program and use it yourself. This video is direct at program interested people, to see the some RFP in use and that it can do more than calculate some formula.

I get it. I really do. As a programmer who's also a musician, I'm interested in both. Presumably the purpose of this video was to a) explain what functional reactive programming is, and b) to demonstrate something cool that was built using it. When it came to (b), the video ruined the demonstration by talking over the sound the cool thing was making. Also, suggesting that someone - whose computer literacy you cannot assume is very high - download source code and set up a Haskell SDK to run it in order to enjoy a sound that was supposedly a central feature of a video is simply ridiculous.

I suggest that any person, who is interested in RFP, can setup a Haskell SDK to run it. If the person can't do so, he will learn it. Learning to read the doc is important, if you can't read the doc, you will have a hard time on stackoverflow.

+Jay Young It wasn't specifically about what FRP is, but rather a showcase on how it could be used. It was also not to demonstrate how it makes sound, but just the application itself in general.

Yes, we know getting it up and running unfortunately at present requires a fair bit of knowledge. We definitely want to make installation a lot easier, and we want the application to run on major platforms, but the time we have to work on those aspects is limited. That said, we are very happy to know you find the program interesting: such feedback will certainly encourage us to take this further.

It doesn't yet synch to MIDI, but that is high up on our list of priorities to add. Would indeed open up for a lot more applications for people interested in experimental music. But it is also interesting to see how to best express synchronization in FRP.

There are two aspects to this. Firstly, all the usual benefits of functional programming applies. Such as clear and concise code, fewer bugs, etc. Of course, opinions vary, but at least in my opinion, the accumulated evidence is by now compelling. Secondly, Functional Reactive Programming (FRP), like other similar paradigms such as synchronous dataflow, lets you express aspects specific application domains where time is central (such as music) more directly, which also translates to easier-to-write, clearer code with fewer errors. In particular, one can program with time-varying entities directly and as a whole (such as the hexagonal grid with the tokens that is allowed to be changed, even while the Arpeggigon is running), rather than having to express this through a framework of events and call-backs leading to the dreaded "call-back soup" and inversion of control. Additionally, the particular flavour of FRP used here (Yampa) allows you to program directly with both discrete and continous time, which is helpful for musical applications. For example, notes being played happen at discrete points in time, while a crescendo is a gradual change over time. Now, it is of course possible to implement FRP or FRP-like frameworks in pretty much any general-purpose langauge. This has been done successfully a number of times (ReactiveX and Cycle.js spring to mind). And that is the whole point: one should strive to use a language that is appropriate for the problem at hand, and if the language that one is using isn't quite there, then strive to adapt it to the extent possible. Which is the idea of Embedded Domain-Specific Languages (EDSL). And this last point brings another strength of functional languages to the fore, and then perhaps Haskell in particular: they are truly excellent host languages for EDSLs.

TG-33.

There's a couple of examples of other programs I made with more advanced algorithms. If you PM me, I can send you a link to my latest one.

It's a thingy to play around with, a project somebody build for fun. At least in my circle of friends there aren't many people that enjoy programming functional, we are mostly a bunch of object oriented jerks and it's a joy to see some other approach to a program like this. The music part is a neat thing, playing around with the code and maybe thinking about it, is the actual practical thing here.

The harmonic table is not a new invention. Though not as common as the piano keyboard, It's been around for a long time. It's often used on accordions.

Patrick Abraham I can see some applications where the functional programming paradigm might be beneficial in contrast with OOP, especially if the correctness of a system needs stronger guarantees, and so on, but the video looks like it's about the professor's research area, which just happens to be using the functional approach as a matter of preference. (He did admit that other languages could've been used, the difference being that they would've had to create an external library or framework to express their concepts instead of building it directly into the language itself.) Research is usually funded by grants, and if its a public institution, grant money may in fact be taxpayer money. In any case, it seems rather pointless to have a funded research-level project (the professor does get a salary) where the aim is to have what boils down to a "fun toy" with no apparent, or intended, practical application. Now, I understand that the point of the video (based on some of the questions asked) is to show one "practical" (i.e. real-world) application of the functional programming paradigm, which his project aims to show, but the lack of a real-world problem being addressed by using that paradigm ends up coming across like a self-inflicted shot in the foot :c I would've liked to see an application where a real world problem is being solved or at least addressed in some way, but either the video does not focus on that enough to make it justice, or the project itself is as pointless as I thought it was based on my initial impression and the professor's description, or I just didn't get why that project is worth the formal research effort at that level.. :/

+Alan Hunter Thanks for responding. I'm getting the impression that you might be mixing different concepts due to (admittedly) easy-to-confuse terminology. Please see what I mean below, and I'll try to be explicit to avoid further confusion and ambiguity. >> The graphics card in your computer is a highly efficient machine built specifically for functional programming approaches. GPUs are built mainly to exploit the benefits of parallelism and have high throughput. Yes, you can write functions, but writing a function (i.e. a procedure) is *not* the same as using a language that supports the functional *programming paradigm*. The OpenGL Shading Language (GLSL) supports a procedural (aka: imperative) programming paradigm, like C. It's does not support the functional programming paradigm such as Standard ML and Racket (formerly Scheme) do, where functions (i.e. procedures) are considered "first-class citizens" and also never produce any side-effects (e.g. modify variables, because in purely functional languages, there're no "variables"; see later). My guess is that you might be getting confused with the term "functional". >> In the functional approach there you do still have stored and cached variables. They are however static to the iteration they are used in and usually the result becomes the value of that variable for the next pass. Hence, why I said there were no "variables" above, but I'd use the term "constant" rather than "static", as they mean different things. For example, if you write a program in Racket, the "changes" in the "variables" occur when you invoke functions with modified values passed in, *but the original "variables" remain unchanged like constants*, because, as mentioned, direct assignments are not allowed; loops are implemented by means of recursion (you have to, otherwise, you'd need to make direct variable assignments and produce side-effects, which is a no-no in functional programming paradigms) But ultimately, all of these approaches are forced to compromise somewhere because all of our machines are based on Turing Machines. >> Then a vertex shader is ran for every vertex in the geometry. Inside the vertex shader you can't look up one of the other vertices in the geometry. The entire vertex shader is just a mathematical transform converting the programmer's representation of the geometry into screen coordinate representation That is true, though unrelated. The vertex shader is simply one stage of several in the modern graphics pipeline. (I'll be using OpenGL for the purposes of discussion.) Vertex shaders are written in GLSL, and GLSL is not a functional language; it's a procedural/imperative language. In fact, you can quickly notice this because variable assignments are possible in GLSL. For example, at a minimum, a vertex shader must assign a result to the built-in variable called gl_Position. A pure functional language is not supposed to allow assignments to variables; those are the "side-effects" I mentioned previously. >> and possibly passing some data along to the pixel shaders that will run later. In the case of GLSL, both vertex and fragment shaders are the required minimum, so you *always* pass something from one to the other. (The fragment shader is the equivalent of a pixel shader in HLSL.) >> the GPU will mix those colors for you avoiding the need to know about neighbors. We leverage this function for a lot of really cool dirty tricks. [...] It's all highly functional in nature. Yes it's "functional" in the sense that it has a lot of functionality (i.e. lots of built-in features that we don't have to re-code, like a library), but the fact that the graphics pipeline has "functions" is *not* the same as saying that it's "functional" in the programming paradigm sense. This is the main reason I think you're likely confused with the terminology. By your reasoning, the C language would also be "functional", when this is really not the case. In fact, C does not even support the object-oriented programming paradigm (and I'm not suggesting this is somehow a "bad" thing), even though you can use structs *as if* they were "classes" with public members. >> You are crafting a mathmetical function to run across every element for a given stage of the pipeline. Yes, but writing a function can be done in any language regardless of whether it supports the functional paradigm. You can write functions in C, C++, Python, Perl, Bash, and so on, none of which support the paradigm. In the functional paradigm, you have to think about the problems you're trying to solve in fundamentally different ways, relative to other paradigms such as object-oriented, imperative, or logical (e.g. Prolog), whereas the purpose of a "function" in any program/language is to encapsulate a reusable portion of logic. You can implement functions in all of the above languages, even though they support different paradigms. >> Your data and functions absolutely have to be able to stand independently but yet also work cooperatively without any real team work involved. Yes, but as I've (hopefully) clarified by now, this has nothing to do with functional programming languages, in the paradigm sense. >> The crazy thing is, this approach has turned out to be game changing for fields that have to deal with a lot of data or a lot of computations. The reason the programmable gfx pipeline is such an improvement is that it gave more control and power to developers, which used to be constrained by the fixed/non-programmable immediate-mode pipeline, which in addition to being very inflexible (i.e. you couldn't change it), was also a bottleneck... with the modern programmable pipeline, developers could now write their own set of custom shaders in a C-like high level language (i.e. not GPU-specific assembly instructions) and were no longer constrained like before. In fact, OpenGL is modeled after a Finite State Machine (FSM), and pretty much everything you do with an OpenGL function call (e.g. glFrontFace) is change the internal state of the FSM. In short, the modern graphics pipeline is really not "functional" at all in the sense of the programming paradigms.

Sari Masu nuh uh

+Sari Masu :*

Search for songs played on launchpads, they seem to be quite similar (and much more colorful ^_^).

+Gordon Chin I may have misunderstood what the program is for, but it appears only to produce more or less complex patterns, at least as demonstrated. To create something people would recognize as a song or classical piece would require some very contrived and inefficient 'programming'.

We are the robots...

:-)

It's so easy to start coding, making it any easier would make a lot of low level IT jobs vanish.

When you increase ease of use, you decrease how powerful it is. Things like Scratch are very easy to use, but they don't do much.

it is easy already - depending on what you want to do and what language you want to use. But there is nothing for free - if you want a really simple solution, than it won't be flexible. You could look at processing - a java-based environment with a graphical interface already build in. really easy to get going, but as soon as you try anything bigger you notice the performance is horrendous. drawing just a few simple cubes the easy way, like 100 of them, can already drop you below 30 fps. You can then switch the render-mode and use a bit better structured program to go past 100 again, or you go all the way and write correct shaders and you can draw a couple hundred or even thousand boxes and still have over 100 fps.

Programming isn't made for the user. Programming creates a program that is made for users.

I mean you managed to learn english and mathematics right? well programming is for the most part pretty much jus baby-talk english with high school math strewn in every so often.

That it is written in a purely functional language, Haskell.

Yeah I guess that must have been hard haha but still

So what? Does it make the music better?

The point is not to make the music better, but to showcase how Functional (Reactive) Programming can be used to write applications. Since OOP is still the most wildly used paradigm, it's nice to have a video on how FRP can take small and simple things and put them together like bricks without a massive amount of glue (interfaces, classes, etc.) by using functions.