Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Faust: A Programming Language For Sound (with Romain Michon)
3.1k Plays3 months ago
I’m always interested in what factors shape the design of a programming language. This week we’re taking a look at a language that’s wholly shaped by its need to support a very specific kind of program - audio processing. Anything from creating a simple echo sound effect, to building an entire digital instrument based on a 17th-century harpsichord.
The language in question is Faust, and this week we’re joined by Romain Michon, who works on and teaches Faust, as we look at how it’s designed, what kind of programmers it's for, and how it does the job of turning audio-pipeline definitions into executable code.
And one of the surprising parts of that compilation strategy is the decision to have it compile to multiple targets, from the expected ones like C and Rust, to the exotic destination of FPGAs (Field Programmable Gate Arrays). FPGAs are like reprogrammable circuit boards, and Romain dives into Faust’s attempts to go from a high-level description of an audio program, all the way down to instructions that tell a chip exactly how it should wire itself.
So rather aptly for a technology podcast, we start this week with what your ear can hear and go all the way down to logic gates and circuit boards…
–
Try Faust in the Browser: https://faustide.grame.fr/
Faust Online Course: https://www.kadenze.com/courses/real-time-audio-signal-processing-in-faust/info
FPGAs: https://en.wikipedia.org/wiki/Field-programmable_gate_array
VHDL: https://en.wikipedia.org/wiki/VHDL
Verilog: https://en.wikipedia.org/wiki/Verilog
Grame: https://www.grame.fr/
The (Strawberry Jam) Gramophone: https://www.grame.fr/articles/gramophone
Gramophone Workshops: https://www.grame.fr/evenements/atelier-gramophones-65ca16b19fec4
Support Developer Voices on Patreon: https://patreon.com/DeveloperVoices
Support Developer Voices on YouTube: https://www.youtube.com/@developervoices/join
Kris on Mastodon: http://mastodon.social/@krisajenkins
Kris on LinkedIn: https://www.linkedin.com/in/krisjenkins/
Kris on Twitter: https://twitter.com/krisajenkins
Recommended
Transcript
Introduction to Primitive Types in Programming
00:00:00
Speaker
Every programming language ships with a bunch of primitive types, and they're nearly always the same ones, the same building blocks. You've got int and float, boolean, struct or record, and then char, and provided your language was written after about 1995, string. Here's a rare primitive to add to that collection, sound. This week we can look at a programming language where the most important built-in type is audio.
Introduction to Faust Programming Language
00:00:29
Speaker
The language is called Faust, and it's been designed for writing audio processing programs, like digital instruments, software instruments, sound effect generators. And the language that comes out of that design requirement is a really curious one. It's kind of like functional programming meets music studio full of boxes and cables.
Interview with Faust Developer Romain Michel
00:00:51
Speaker
And to talk us through what it is and how it works, we've got Faust developer, researcher and educator, Romain Michel. He comes to us fresh from the National Centre for Music Creation in France.
00:01:03
Speaker
And he's going to take us through what Faust is and how it works. And I thought we'd spend this entire conversation talking about programming audio pipelines.
Faust's Real-Time Audio Processing Capabilities
00:01:14
Speaker
But as we start to go down into it, we managed to go all the way down the stack right into programmable hardware. Because Faust is a language that compiles to C and compiles to Rust and JavaScript and Wasm, and very soon to instructions that configure logic gates directly on a chip. We managed in this episode to go from functional programming right down to ones and zeros, with audio all the way through.
Backgrounds of Chris Jenkins and Romain Michon
00:01:42
Speaker
That's quite a lot to cover, so let's get going. I'm your host, Chris Jenkins. This is Developer Voices, and today's voice is from Anne Michant.
00:02:02
Speaker
I'm joined today by Roman Michon. Roman, how are you? I'm doing great, Chris, and you? Yeah, I'm good, I'm good. You're looking relaxed after your vacation, which I've dragged you back from. um Yes, vacations were great. They were a little bit too short to my taste, but ah but yeah it's ah it is good to be back to work, though. not Good, good. And work for you is working on this very curious language of Faust.
00:02:28
Speaker
Yes. So start there. What is Faust? What's the reason for another programming language? So Faust is a programming language for real-time signal processing applications. So it means that it's what we call a domain-specific language.
Challenges in Real-Time Audio Processing
00:02:46
Speaker
So Faust is not a general purpose. Faust was designed to do one kind of task, and it's real-time audio signal processing.
00:02:56
Speaker
Okay, so let me think, whats what makes that tricky? Real time is the thing that makes that difficult, I assume. Yes, so so the reason why FAIRS was created ah was to provide a higher level way to deal with audio programming for real-time applications. So if you want to implement a program that's doing real-time audio signal processing, in general, you have to use ah C or a C++. plus plus
00:03:34
Speaker
or Rust now, but basically you have to use compiled languages. Because only with this kind of programming languages can you achieve ah real-time performances that you need to do, like low latency audio processing or things like this. So say you want to make an audio plug-in, or you want to make a standalone application for your desktop computer that's doing real-time audio processing.
00:04:00
Speaker
Then you have to use C, C++, plus plus or Rust, which is kind of a new way of of doing this. but But basically, you have to use compiled programming languages. The problem with those languages, as you probably know, is that they are hard to use, and they are not necessarily very accessible to ah people who have a limited background in computer science. so The reason why files was created is to provide a solution
Who Uses Faust?
00:04:30
Speaker
to this problem. So it's basically a higher level ah programming paradigm, but ah providing the same kind of performances than the ones that you would have with a compiled language. OK, so give me an example. of someone So someone who's writing, ah when I'm recording this podcast, sometimes I use software that removes the reverb from the room.
00:04:54
Speaker
yeah right Would it be someone who's writing that kind of application that's trying to detach reverb sounds from audio? Exactly. yeah so so There are many, many examples of audio processing. and and As you say, right now there's probably a fair amount of audio processing happening in the background of this recording ah to remove echo or to remove the natural reverberation of the room.
00:05:23
Speaker
or ah to apply dynamic French compression, ah or any kind of filtering, or even sound synthesis in some ah in some cases. so ah So for example, if you want to do speech synthesis, or things like this, you you have to synthesize sound. and ah And that's another use case for real-time audio processing. Are we also talking things like synthesizers?
00:05:48
Speaker
Yes. so So if you have a synthesizer at home, like ah a keyboard synthesizer, where when you press a key, you get a sound. So ah so that's the kind of things that you can do with Faust. OK. So is most of the users of
Faust's Language Support and Transpilation
00:06:06
Speaker
Faust would be kind of programmers, but not like low level C engineering programmers, but maybe like Hybrid programmers come music designers.
00:06:20
Speaker
Yeah, so that's ah that's a good question because usually when you work in a company that's ah making audio plugins, for example, or that's doing this kind of stuff, you have two kinds of ah engineers in the company working in this. ah You have the the people who are developing the algorithms and and who are ah basically what do we call DSP engineers. so So they basically work on the math that's processing sound, right? yeah and And then you have ah the software programmers who basically take what those people are doing and implementing it ah so that it can work in real time on a computer or a smartphone or something like this, right?
00:07:10
Speaker
and And usually those two people, ah they don't use the same softwares to do this. So so the DSP engineers will use tools like MATLAB or Python for ah prototyping their algorithms. And and then ah the software developers who will implement ah the ah the the finished product, they will use C++ c plus plus Rust, JavaScript, maybe WebAssembly if you're using the web, ah but ah but you really sort of need these two steps, basically, in the in the process. So, what first is providing is ah the same ah level of accessibility than ah you would get with Python or with MATLAB for DSP engineers, ah but
00:07:58
Speaker
ah you directly get something which is lower level ah when you go to the implementation stage and so so so you get kind of the best of both worlds in a way. Okay, right. So if we came up with a language that was both expressive for music specifically,
00:08:24
Speaker
but then compiled down to something that ran with the performance of C. That's where this is going. Yes. So one thing that I haven't said yet, ah and which is very important to sort of get the global understanding of this, is that Faust is what do we call a transpiler. So basically, ah it compiles code, which is written in Faust, to lower level programming languages. So it means that what Faust does ah is that ah it generates ah code in lower level languages. So basically, you write something in Faust, and then you can export it to C++, plus plus ah potentially Rust, as I said earlier, or WebAssembly, Java, JavaScript. ah There are a lot of targets for Faust. So so basically,
00:09:15
Speaker
ah you can export whatever you write in Faust to lower-level programming languages. so ah so Faust itself doesn't necessarily generate binary code, but Faust will generate code in lower-level programming languages ah that themselves can generate binary code. Okay, so you yeah so you use Faust to generate the C that you would then have a number compile step until it became the final product? Yeah.
00:09:45
Speaker
i I want to explore the management of that because I know given that you export to so many languages, that must be a problem. But before we get there, you surprised me by saying Java because I can see that this domain requires a compiled language, but I would have thought it also requires a language that doesn't use a garbage collector because you can't afford the pauses. Yeah. So, I mean, um.
00:10:10
Speaker
When the false compiler was designed, it was really designed to be able to export to different languages. So it's easy for us to add new backends to the false compiler. So it means that um if a new language comes up, ah it's not that complicated for us to provide support for this language.
00:10:34
Speaker
and ah And so so Java ah was just added as a target for the first compiler at some point, okay because someone probably asked for it. And um and then from a practical standpoint, ah you know exporting code to Java is actually not that different from exporting codes ah to C++. plus plus you know It goes ah syntactically speaking, Java and C++ plus plus are not that different when it comes to ah expressing a DSP algorithm. And and so so so the reason why we're supporting Java is because someone asked for it at some point, but ah but It's definitely not the most used target for Faust. You know what? In fact, I think the latest version of the Faust compiler doesn't even have support for
Functional Programming in Faust
00:11:28
Speaker
Java anymore. So so so maybe we should just forget about this. okay yeah But you're kind of if you're doing JavaScript as well, that's the same thing which WebAssembly doesn't have. So you're kind of saying, we can support it easily enough. That may not be the best choice of runtime, but we can support it.
00:11:45
Speaker
yeah i mean ah you know If you want to get ah the best performances ah in terms of ah runtime, there are not that many options. thats That's what I said earlier. you know like so so If you're using a web browser, then you should use WebAssembly. and and then If you are using a desktop application, ah then ah you should use any compiled language that exists. And there are not that many compiled languages that people still use nowadays. you want so So basically, your options are C, C++, plus plus or Rust. And that's pretty much that's pretty much it. so I'm going to have to ask, because I know there's the language Zig, which was created almost by accident when the author was trying to create an audio workstation.
00:12:35
Speaker
So do you support Zig yet? No, we yeah we are we don't. and To be honest, I heard of i heard of this language before, but ah but I'm not really exactly sure how it works or what it does. OK, well, in that case, let's step back into Faust itself. How do you design a language suited for audio processing? How is it different? How does it look different?
00:13:06
Speaker
Okay, ah that's a tough question and ah and it probably deserves a very long ah answer, so which I'm going to try not to give. okay I'm going to try to make my answer as small as as possible. but so the The first thing that you have to know about Faust is that it's a functional programming language. ah so So it's not an imperative language. So it's very different than C or C++, plus plus which are imperative languages. And REST is also an imperative language. so So Faust is very different in that in that regard.
00:13:45
Speaker
So um another thing that I want to say is that Faust was created originally by someone called Jan Oraj. And Jan is still working actively on Faust. In fact, we're part of the same ah team here in Niel, so we we do see each other quite ah quite often.
00:14:06
Speaker
so Yana is someone who's always been working on functional languages and and someone who's also very much interested in the concepts behind what we call lambda calculus. and so so So basically Yana tried to create um ah and program language specifically designed for audio applications that combines ah these principles. okay so So Faust ah borrows principles from Lemdak calculus and is very much a functional language. And the main conviction of Jan when he created the language was that functional programming languages provide a better um paradigm for ah coding audio algorithms.
00:14:58
Speaker
and then imperative programming language than imperative program languages. and so so the the Part of the answer to your question is here. Foust is functional, and it's functional because ah the creator of Foust initially thought that functional ah programming languages are better programming languages for expressing audio DSP algorithms. Why is that? ah so um so you know In the old days, ah when when people were doing audio processing, they were not necessarily using digital technology, they were using analog circuits.
00:15:41
Speaker
right right yeah so ah So you know you would connect ah resistors and transistors, and well, not necessarily transistors, but capacitors and different components together to implement a filter or a sound synthesizer or something like this. you know And ah and so ah so to express this, you would draw a block diagram of your circuit.
00:16:06
Speaker
right and the and so If you think of a block diagram of a circuit, um in a way, ah it's kind of closer to a functional programming paradigm than what do you would get with an imperative programming language where operations happen sequentially.
Visual Representation in Faust
00:16:27
Speaker
right so um So basically, Faust was designed with that in mind. So basically, Faust is also a programming language that we can see as a dataflow programming language. You basically connect a block to a block to a block, and by combining blocks together, then you can implement your algorithm.
00:16:53
Speaker
ah With imperative languages, ah you don't really do that. Well, you can create data flow connections, but it's not as deeply embedded in the language as ah with Terce, basically. so so ah so So I don't know if that completely answers your question, but but it gives me this sense that like we're, instead of iterating over bite arrays and then calling the next function in the chain with a chunk of bites, you're doing a more kind of, um, map stream processing style programming.
00:17:32
Speaker
So Faust ah as a language is basically a language that allows you to build a block diagram. you know And and so ah so basically when you write a Faust program, what do you what you do is that you design a block diagram. And in fact, it's so ah embedded in the semantic of the language that ah you can export a Faust program, which is a ah scripted a language. You can export it to a block diagram. in the okay so If you use the the Faust ah Web ID, ah which you can find at FaustID.gram dot.fr, ah when you write your Faust program,
00:18:21
Speaker
ah At the bottom of the page, you can automatically see the corresponding blog diagram to the the program that you're writing. so so There is always a graphical correspondence to what you're writing in FELC, basically. and ah and so so so I think that's probably one of the biggest difference between Faust and ah other languages that you might use for audio processing.
Applications of Faust Beyond Music
00:18:47
Speaker
you know or likeq ah In Faust, you build a block diagram. ada And so so if you want to create an audio process, you will connect ah some kind of operation to another operation and then to another operation. And then there is always a block diagram corresponds to that.
00:19:06
Speaker
So it puts me a little bit in mind of over-architected guitar pedal boards. We take the guitar into an echo, into a compressor, into whatever.
00:19:17
Speaker
Yeah, that's exactly what you do. so so um And basically, you know like in general, when you implement audio DSP algorithms, that's what you do. you know like i mean ah A filter is basically a combination of ah basic mathematical operations, so additions, subtractions, sometimes multiplications, and delays.
00:19:44
Speaker
Basically, right? so ah So if you want to code a filter in Faust, all you have to do is to ah put together the right block diagram, ah combining additions, subtractions, multiplications, and delays, basically. you know like and the Yeah, because I guess in a way, there's an analog there to like the physical circuits that we would do these things with.
00:20:08
Speaker
Where your capacitor introduces a delay, a resistor is like a multiplication or a division. You can build these things up. Yeah. Okay. So does, does this, let me ask this, does this just get used for music stuff or are there other kinds of audio signal processing in the world that I'm not aware of? I mean, um, so.
00:20:36
Speaker
I think it depends. There are there are multiple answers to to to this question. so um ah Traditionally, audio DSP has always been very much connected to to music because for some historical reasons,
00:20:53
Speaker
The people who worked ah on music technology ah during the second half of the twentieth century ah were also kind of the same people that developed all the audio, digital audio infrastructure that we're using now in computers, ah in cars, in speakers, technologies, or things like this. But ah music is not the only kind of application. And and so so it's always connected to sound, of course. right ah but ah But if you think about it, ah we do have sound ah in our ah smartphones. ah We do have sounds in our headphones. ah We do have sound in our speakers. And as you mentioned earlier,
00:21:38
Speaker
ah When ah we do ah video ah conferences like we're doing now, ah we're also using sound. but and and There is obviously sound processing happening ah right now as we're speaking ah and ah and doing this video recording.
00:21:56
Speaker
so so Basically, wherever you have sound, you need some kind of processing.
Faust's Type Safety and Memory Management
00:22:03
Speaker
Foust is not limited to musical applications, but it can also be used for any kind of applications that require processing sound, which is basically everywhere around us nowadays. so yeah yeah yeah and it's I remember a few years back trying to work with the Objective-C Audio library for ios yeah and that was terribly low-level and it was basically invisible experience yeah yeah i think we've all been through through that at some point yeah okay i'm sold on the idea of having something higher level so that makes me wonder is this is is it as a language is it memory safe is it type safe do you worry about those kinds of issues
00:22:47
Speaker
ah Not really because, well, it is very safe. I'm not saying that Faust is is not safe memory-wise. So type-wise, Faust only has one type, ah which is an audio signal. So so basically, ah the only thing that you can express in Faust is an audio signal.
00:23:12
Speaker
then the Faust compiler takes care of automatically deciding at a lower level what is going to be an int, what is going to be a float, or ah you know like this kind of thing. So so basically, faust ah the Faust compiler automatically optimizes what you write in Faust to deliver ah the most optimized ah code in C,
00:23:39
Speaker
and C++ plus plus or in any other programming languages so so type wise fast is very safe because it only has one ah type and memory management happens at a lower level so okay.
00:23:55
Speaker
so So basically, ah again, the first compiler is in charge of delivering delivering the most optimized code in C or in C++ plus but or any language supported by first. And in theory, ah the first compiler never makes wrong decisions as far as memory management is concerned. So usually in first, you don't really have to worry about that kind of stuff.
00:24:22
Speaker
I suppose this is a unique case where you can do automatic memory management, not because you've got a garbage collector, but because you know that by the time you've passed the audio signal down the chain, you won't have to worry about it anymore. Yeah, exactly. yeah like there There is not really a need for a garbage collector in this case. And also, you know ah if you think about it, ah if you're considering real-time audio applications,
00:24:51
Speaker
Everything is kind of running all the time. you know and ah and so so like If you take again the the paradigm of an electronic circuit, ah so ah so if you have something coming on the left side of your circuits, there is always something coming out on the right side.
00:25:10
Speaker
And ah whatever you have in between is always kind of ah working. So so in in audio processing, ah there are many, many, many cases where you don't necessarily need to do that much garbage collecting, because ah things are kind of always running all the time, right?
Parallel Processing in Faust
00:25:29
Speaker
Yeah, yeah, yeah. You've got this live running process, and then it's just stuff comes in and stuff gets shipped out. Yes, exactly, yeah. yeah so I want to get into the architecture of how this is done under the hood but that does bring up one more question is this quite do you have parallelization because it sounds like you ought to be able to parallelize this across multiple cores quite easily. Yeah ah well the answer is it's kind of yes and no okay so.
00:26:01
Speaker
you know like the The first thing that you have to consider is that usually for real-time audio processing, ah people try not to do too much parallelization. or Traditionally, people didn't use to do that too much because ah it wasn't necessarily like super-thread safe to do this for real-time audio applications.
00:26:22
Speaker
Again, real-time audio is a very, very specific case in programming in general because ah the real-time constraints are very, very, very high when you do audio processing in real-time.
00:26:38
Speaker
um With image processing or if you're doing video processing or something like this, you normally have to deliver a new image every 30 times per second, sometimes 60 times per second. But the real-time constraints are not that high in that case. For audio processing in real-time,
00:27:07
Speaker
ah You have to pretty much deliver a new sample every 48,000 times per second. you know yeah but And if you miss one sample, or if your sample is not delivered at the right time, if it's a little bit late, then you will hear it. ah the ah The impact on sound is immediate and people people can hear it ah very well. you know and so yeah so When you do audio processing, the real-time constraints are are very high. and ah and so ah so so That's why we use ah low-level programming languages in general ah that compile directly to binary because of that.
00:27:52
Speaker
ah But um I forgot what your question was. So I'm wondering, if because i've got this I've got this metaphor of like a pedal board for guitars. yeah You're plugging things into things, you've got a pipeline. How hard is it to take one of those pedals and put it on a different CPU? Oh yeah. so Sorry, ah now I remember your question.
00:28:16
Speaker
ah So FALS can automatically parallelize ah something that you will write in FALS. So the FALS compiler comes ah with a series of ah compilation flags that you can use and that allow you to configure various options in terms of the code that's going to be generated by the FALS compiler. and And so one thing that you can do is that you can ask the FALS compiler to automatically
00:28:48
Speaker
vectorize ah ah the the code that's generated by the false compiler and to automatically parallelize ah that code. And and so ah so this is something that was implemented in the false compiler about 10 years ago, and ah it was kind of an experimental ah thing. and ah and so so Some people have been trying to use that in various scenarios, ah notably ah trying to use GPUs because you can obviously parallelize things so heavily on ah on a GPU.
00:29:26
Speaker
But um in practice, ah this is not something that people have been using much, ah like that that feature in Faust to automatically parallelize the code that's generated by the the Faust compiler. So it's not something that's supported on the main branch of the language currently. and and but you know As I was trying to say earlier, ah usually when you do real-time audio signal processing, ah
00:29:58
Speaker
People don't do that much parallelization. you know like so So typically, what do you will do is that you're going to use a digital audio workstation. In that digital audio workstation, you're going to run multiple plugins in parallel, and usually your dog will try to run um a plugin on one core and then another plugin on another core.
00:30:21
Speaker
ah and But usually it's not so common when you have one plugin ah that's running different things on different cores, basically, because it's not super thread safe to do that.
Compiling Faust for DSP Graphs
00:30:36
Speaker
And and so so typically, you will do this kind of patching directly in your digital audio workstation, ah but it's not something that you necessarily want to try to do directly in the plugin that you're that you're writing. so so ah So because of that, ah that feature in the first compiler that I just told you about was not necessarily used ah that ah much.
00:31:03
Speaker
OK, so it's it's technically possible, but there's not much user demand for it because you tend to run one instrument per core. Yeah, usually that's what you do. OK, I think it's done time to dive under the hood and see how this is actually architected. So I write some Faust code, which presumably is looking vaguely familiar as a kind of functional programming pipeline of interesting stuff. And I give it to you, you being the compiler in this case,
00:31:32
Speaker
yeah What do you do with it next? So ah the first thing that the Faust compiler is going to do is that ah it's going to sort of break down ah your Faust program to build a DSP graph out of it.
00:31:50
Speaker
okay So basically, ah it takes the fast program and then it tries to build a flat ah block diagram ah of all the mathematical operations that are happening ah within your DSP code. So in fast, just like in many other programming languages, you can use libraries. And and so it means that not everything is ah written directly in your first program right so so you can import libraries and these libraries give you access to functions and then you can call these functions in the first language well in the in the first program that you're that you're writing right
00:32:33
Speaker
ah So the first thing that the first compiler is going to do is that it's basically going to import all the functions that it needs into one big file ah to ah have basically an inline fast program with everything in it.
00:32:49
Speaker
After that step, ah the Fels compiler will build the DSP graph that I just talked about. So basically, it's going to flatten everything and and it's going to construct a ah tree basically, you right ah where ah you're going to have an input at the top and the output at the bottom with all the mathematical operations that you're going to need in between know memory accesses and everything that you need basically to implement your Audio DSP algorithm once ah we reach that stage and we have access to this low level representation of your DSP algorithm ah then ah depending on what the user wanted the files compiler
Faust and FPGA Programming
00:33:35
Speaker
will. ah
00:33:36
Speaker
generate code in different programming languages, ah depending on ah that DSP graph that was just ah built from your Faust code, basically.
00:33:50
Speaker
and okay and so ah so Basically, after that, you say, I want to generate C or C++ plus plus or WebAssembly or ah any ah backend any program language that's supported by the first compiler. The first compiler will do that from ah that low-level representation of your DSP tree, basically. It's very much like a lot of other languages where you you parse it into What might be seen as an abstract syntax tree or might be seen as an abstract audio processing tree. yeah And then you've got a bunch of different, read that low level tree and turn it into C, C plus plus. Exactly. yeah yeah yeah How modular is that out of curiosity? ah Sorry. How modular is that? how Like, do you need to hack the main code base if I wanted to add in Zig? Or would I just supply a program that is separate?
00:34:47
Speaker
Yeah, so, you know, audio DSP programs ah in the end are not that complicated. ah You know, audio DSP algorithms are, as I said earlier, they're basically just simple, basic mathematical operations, right? So, so as long as you can do ah math,
00:35:11
Speaker
you know so like addition subtractions multiplication divisions and trigonometric operations and and then store things in memory. ah Then you can probably implement pretty much every ah audio algorithm that exists in the world. Right? ah And so so so for that reason, then ah exporting ah that low-level DSP representation of your audio DSP algorithm algorithm to another language is actually not that complicated, right? so And so all that to say that if you want to add new um ah backends to FAST, so if you want to provide support for other programming languages,
00:36:00
Speaker
then it's actually not that complicated because ah what do you generate in the end but is not that different from one language to to another. um So there are a couple of exceptions to that.
00:36:14
Speaker
and came And so ah so maybe I can talk about them because they're potentially kind of kind of interesting. So so recently, we yeah we've been working on a new project where we tried to use Faust ah to ah program FPGAs. ah So FPGAs are ah field program programmable gate arrays. And so so for those of you who've never heard of of FPGAs or heard of FPGAs but don't really know exactly what they are. FPGAs are a very specific kind of ah processor where ah instead of having a static architecture for your processor, the way you program your processor is by reconfiguring ah its internal electronic circuit. so Basically, ah with an FPGA to implement to implement a program,
00:37:10
Speaker
ah what you do is that you ah basically design your own processor in a way, right? So so it means that if PGAs are used to carry out only one task, and that's the task that they were programmed for, ah and ah and then ah as opposed to CPU, they are not ah generic. ah They only do one thing, and that's the thing that yeah you haven'lin you implemented them for, that they're doing basically. This is like um I get a CPU from Intel and I decide, I wish it worked slightly differently. I can flash an FGPA to behave as my slightly different silicon architect. Absolutely, yeah. So on an FPGA, ah the kind of resources that you have access to are logic gates, block of RAM, ah um multiplicators or things like this. So FPGAs are extremely extremely low level ah in nature, basically. right right and so so Usually, if you want to program an FPGA, what you use is what do we call a hardware description language. and and so ah so Hardware description languages are basically programming languages that allow you to describe the way your electronic circuits is going to look like ah once it's ah ah placed
00:38:34
Speaker
on the FPGA. So in a hardware description language, you say, I'm connecting this logic gate to this logic gate. ah And I'm taking this input. And this input is probably a stream of 1 and 0. And this is the kind of operations that I'm trying to do on this stream of 1 and 0, basically. So it's a very, very, very low level.
00:38:59
Speaker
and there are only ah well There are not that many hardware description languages in the in the world. you know and the The two main ones are Verilog and VHDL.
00:39:12
Speaker
and and so ah so ah so The goal of the project that I'm telling you about is that we're trying basically to generate a VHDL code or Verilog code directly from Fast.
00:39:26
Speaker
but And um it's really, really complicated. it okay And it's really, really hard. And that's why I'm saying that ah there are exceptions to what I told you earlier. you know like so ah So if you want to add a new backend for a normal um standard language to Faust, it's easy. But if you want to add a backend for something that is as low level as ah the HDL or very log, then it's potentially more complicated.
00:39:59
Speaker
and ah And so ah so we're we're kind of still struggling with this. ah in And so so so it depends on the language that you're targeting, basically. Okay, I've got to ask it because I like this idea that I could write my dream synthesizer in Faust and then not just compile it to a running program, but actually burn it into hardware that was my hardware synth. Yeah.
00:40:24
Speaker
but why is I can see that it would be weird to describe it in terms of ah logic gates, but why is it much harder than describing it in terms of ad operators?
00:40:40
Speaker
ah yeah art ah This also deserves a very long answer. but I'm sorry about this. but um okay so the The first thing that is hard is ah dealing with fixed-point arithmetic. so okay so so that's ah That's one ah primary ah difficulty when you when you're doing this kind of stuff. cool um you know Usually when you do real-time audio signal processing and you want to express an audio DSP algorithm, you do want to have ah floating points. Because we're talking about signals, so we're talking about ah potentially um of variation in a voltage. you know like If you think again about an analog circuit, ah it's easy to be able to express ah the kind of operations that you're going to carry out on those signals using floating point operations.
00:41:40
Speaker
right see And fixed point is complicated. So in you know in the old days and even nowadays, ah there are DSP engineers ah that know how to write um audio DSP algorithms using fixed points. And the reason for that is because there are still some ah chips for audio signal processing, like DSPs, so digital signal processors, ah that only work in fixed points. and And usually those chips are either cheap or ah they're optimized for
00:42:21
Speaker
ah using as little energy as possible. right and okay yeahs you know like it's ah It doesn't consume the same amount of energy to ah ah to do floating point operations than fixed point operations. right So ah so the the first answer to your question is this basically you know and ah and so in Faust you can express your audio DSP algorithm using floating points of course because well and you don't even have to think about it about them in terms of floating points but you want to use decimal numbers basically. right
00:42:57
Speaker
ah And and so ah so this is something that you can do in Faust, and it's really much it's very much part of the Faust syntax, you like like being able to express decimal numbers. On an FPGA, there is no such a thing as decimal numbers because it's very low level. you know ada and You're literally down to the binary.
00:43:22
Speaker
Yeah, exactly. you know and ah And so when you're talking about logic gates, of course, you're not talking about floating point numbers. So ah so it means that ah in order to generate VHDL code, which is reasonably well optimized for an FPGA, ah then we have to support ah the automatic conversion from floating points to fixed points directly internally within the first compiler. And this is something which is not simple to do.
00:43:49
Speaker
um Yeah, I can see that being a chunk of extra work. So so that's the that's the the first reason. And then ah there's ah many other reasons. And the other reasons are pretty much related to the kind of optimizations that you normally do when you use an FPGA. So when you use an FPGA, typically, ah the Two main kind of optimizations that you can do when you're designing your ah electronic circuits ah is to parallelize computation, right ah which is not something that you can do that easily when you're using a CPU or a DSP. Well, you can do it, but ah but again, ah it's not ah necessarily designed for that.
00:44:36
Speaker
so You can do ah heavy parallelization on an FPGA, which is not the case with other kind of platforms. and Then the other thing that you can do is what do we call pipelining. Pipelining is basically when you reuse resources that you're already allocated on your FPGA to carry out ah the same task, but over and over again. so so For example,
00:45:05
Speaker
Say that in your algorithm ah you have a series of operations that are the same ah and that you need to run multiple times in parallel. okay so ah So if the clock of your FPGA is fast enough, then potentially you can reuse that chunk of operations multiple times to carry out the same operation.
00:45:31
Speaker
okay so Say, for example, you have multiple filters running in parallel and all these filters are the same. okay so ah so If time allows it, you can potentially reuse the same filter to compute ah the the the result of all the other filters that are running in parallel.
00:45:53
Speaker
and ah And this is what we call pipelining. And and so so typically on an FPGA, if you want to get good performances, you need to do parallelization and pipelining. And these kind of operations are absolutely not natural when you're dealing with a CPU. And and so ah so it means that ah the kind of optimizations that we normally do um ah in Faust ah when we're targeting C, C++, or more standard program languages, those optimizations don't apply anymore when we're targeting VHDL or Verilog. This is why it's complicated. you knowing so So pipelining, parallelization, and ah dealing with fixed point numbers ah is ah are the reasons why we're struggling supporting those but specific languages.
Rewriting Faust Compiler for FPGA Support
00:46:53
Speaker
Okay, yeah, that makes sense. Does that mean you're like, you've got this intermediate representation? Does that mean you're going back earlier in the chain and say, I've got the unoptimized version?
00:47:05
Speaker
we adopt And there are now two code paths, optimize that tree towards traditional languages, or optimize the tree in another direction towards um hardware. yeah Unfortunately, we can't really do that, and we really, really hope we could do that.
00:47:23
Speaker
ah ah But we can't. ah And and so so for that very specific project, ah Jan, a lared the the guy who created FAST, he's basically trying to rewrite the FAST compiler, because that internal representation that we have is not necessarily compatible with all the things that I just ah mentioned.
00:47:47
Speaker
and so And again, you know like this is a new kind of application because ah people didn't use FPGAs for real-time audio applications until kind of recently. ah so So this is kind of something something new in a way. And and so so we never really thought about this kind of applications, and we never really thought that way in terms of signal processing. yeah and ah And when you deal with FPGAs and when you deal with hardware description languages, um in many respects, you kind of have to forget everything that you know. And it's very, very daunting as a software programmer.
00:48:32
Speaker
And and so ah so in order to do this project, we kind of all had to learn ah how to deal with hardware description languages. and and ah And it was really, really tough for all of us. You can't believe. Because ah again, you know like you're as a software programmer, you're very tempted to write software code for an FPGA. And and this is something that's completely possible in a way, you know like because hardware description languages are high level enough so that ah you can potentially write code that's going to look like C or C++ plus plus code, like very low c C code, basically. But if you try to do that, ah then um it's so unoptimized that ah there are very high chances that ah your program is just not going to
00:49:26
Speaker
not going to run. you know and And if you want your program to run, you have to carry out so many optimizations that are so not natural for software ah that ah for all these reasons, ah we kind of had to rewrite a part of the Faust compiler.
00:49:46
Speaker
Yeah,
Advantages of FPGAs in Audio DSP
00:49:47
Speaker
that makes sense. It's kind of like, um seems like as an industry, we spent maybe the 40s and 50s trying to hide away from the fact that we're dealing with logic gates. Yeah. And now you have no choice but to re-embrace that if you want to deal with.
00:50:02
Speaker
this kind of hardware. Exactly. yeah Which, you know, in a way ah is what ah the people who design the C or the C++ compiler are used to deal with, you know, goes ah because at the very bottom, that's what's happening, right? ah but ah But, you know, as a software programmer, you kind of forget about all those things, you know, because And even the C people, they're like, maybe ah there are a lot of times they're thinking about turning it into machine code, not necessarily AND gates and not gates. Yeah, it's true, yes. Right. Absolutely. It's actually quite breathtaking if you step back and think you're trying to go from abstract enough for a musician to write down to ones and zeros. Yeah. This is perhaps the broadest project we've ever covered. Yeah. And again, for us, it's not easy.
00:50:58
Speaker
is Fair enough. There are a lot of things to know for for sure, you know, and and so so just to ah sort of wrap up on this, ah like we so for writing ah those programs and then running them on FPGA. Currently, the the approach that we're taking is to use this thing which is called high-level synthesis. um Synthesis is not in the sense of sound synthesis. and In fact, ah those two things are completely different. but ah
00:51:35
Speaker
but um Yeah, like 20 or 30 years ago, a group of people thought that maybe there is a way to program if PGA is using C or C++. plus plus you know elder And so ah so most FPGA vendors ah provide what they call HLS, so hi high-level synthesis tools, ah which basically allow you to program with PGAs using higher-level languages, ah which are not ah hardware-description languages. and And so those languages are typically C, C++, plus plus and in some cases, Python, MATLAB can be used in some cases as well. really yeah and ah But the problem is that ah
00:52:18
Speaker
ah You run into the same kind of issues than the one you run into when you're using hardware description languages, ah which are dealing with fixed points, operations, ah pipelining, and ah heavy parallelization.
00:52:34
Speaker
and And so it means that ah you can't just take a C code and run it on an FPGA. ah You have to write a C code which is specifically designed for an FPGA. And that C code is probably going to use ah pragmas, ah which are provided by ah the high-level synthesis tool to carry out the right optimizations for your code ah to run.
00:53:01
Speaker
so So currently, what we're doing with Faust in this context, ah because again, um generating the HDL code directly from Faust is complicated. ah So a sort of alternative approach that we have been using so far, in which is kind of working very well, ah is to use ah those high-level synthesis tools ah and to generate a C code from Faust ah which is optimized for high-level synthesis, okay? So basically what we do is that you write files programs. Files generates a specific C code which is ah optimized for high-level synthesis. Then ah we take the C code, put it into the HLS tool provided by the FPGA vendor,
00:53:56
Speaker
And then you get um an FPGA program which is reasonably well optimized for an FPGA. It's probably not as good as something that would have been written by hand in VHDL or in Verilog. But it's good enough so that ah it's still better than something that it would have done if you used a CPU, for example. right yeah yeah If you can't make the journey in one step, then make it in two.
00:54:24
Speaker
Yeah, but doing that is hard. Anyway, still, you know why feel it means that you have to deal you still have to deal with pipelining ah and ah parallelization directly ah in the first compiler because ah even though there are tools provided by HLS that facilitate dealing with pipelining and parallelization,
00:54:48
Speaker
you still have to embed that directly in the code that's ah generated by the first compiler, and it's not that easy. so Right. so Do you think this will become elegant once Jan has got the next version out, or is it always going to be thorny?
00:55:07
Speaker
so That's a good question. So so we yeah we've been really intrigued by FPGAs here in the team for for many years now because they provide ah much more computational power than what you would get with the CPU. And and the performances ah in all respects of the FPGAs are better than the ones you get with a more traditional
Teaching Faust to Different Disciplines
00:55:35
Speaker
platform. you know like so so For example, audio latency is a big one. FPGAs basically have almost no latency. well they they They do have a little bit of latency, but it's much smaller than what you would get with ah with a CPU.
00:55:51
Speaker
so ah so it means that The time it takes to get ah a sound in an FPGA and then out of an FPGA is very, very short ah compared to what you get ah with a CPU or a digital signal processor or any other kind of ah processing system.
00:56:10
Speaker
Another reason for using FPGAs is that potentially if you want to run ah audio DSP algorithms at a very high sampling rate, say in the megahertz w range as opposed to the kilohertz w range, which is traditionally used, you can do that with an FPGA. So so if you want to run your audio DSP algorithm at 20 megahertz, ah You can do it with an FPGA, and it's actually not that much more expensive computationally speaking ah compared to running it at a lower sampling rate. so That's curious. I've got to ask, is that because that can't just be for the extreme audio files who want the highest sample rate they can get. Is that for radio signal processing or something?
00:56:57
Speaker
so um You know, like, ah it's really for very niche and specific kind of applications, but um but ah say that, for example, ah you want to um make a virtual analog DSV algorithm. so So you want to ah have a sound synthesizer ah which behaves like and an analog electronic circuit ah or a filter that behaves like an analog electronic circuit.
00:57:41
Speaker
so ah so Typically, when you ah try to do that in the DSP world, you're running to aliasing issues because of discontinuities you're going to potentially create in the signal. you know and ah and so Sharp changes in your signal will result Into ldasing basically right so ldasing is something that's as DSP engineer you always have to deal with right and one way to get rid of ldasing is to increase the sampling rate
00:58:21
Speaker
you know ni Because if you increase the sampling rates, then you're pushing ah what we call Nyquist frequency, which is the the highest frequency that you can sample with your ah with your ah with your system.
00:58:36
Speaker
right and And this is already something that's done ah in the audio industry, so ah so typically ah if you are a very fancy ah audio ah re recording studio,
00:58:53
Speaker
usually you will run ah your audio DSP workstation at a much higher something than what you're ah here can actually take. So basically... Yeah, because there's a hardware limitation in our heads, right?
00:59:09
Speaker
Yeah, like the hardware limitation in our head is ah that basically anything that's above 40 kilohertz in terms of sampling rate is kind of pointless for our gears, right? ah but yeah ah But not for aliasing, right? And so ah so ah you always have the risk to get aliasing if your sampling rate is not high enough.
00:59:34
Speaker
right and so ah so The best way to get rid of aliasing is to increase the the sampling rates. and and Even though usually audio DSP algorithms are optimized for not having aliasing, there are some audio DSP algorithms that do have a little bit of aliasing. Virtual analog is typically ah some of them. right and so so If you want to ah not have a liaising, the only thing that you can do is to increase the sampling rates. and ah And there are some ah digital ah keyboards that are available on the market that are taking advantage of this property of FPGAs. And I'm thinking, for example, of the Novation Summit ah keyboard. The Novation Summit keyboard uses an FPGA internally to run some of its oscillators, which are digital oscillators ah at 20 megahertz or something like this. and And the reason why they are doing this is to guarantee that their digital oscillators are completely aliasing free, basically. like
01:00:47
Speaker
Right, so you've got a sample rate so high that it is almost identical to what nature would provide in an analog circuit. Yeah, pretty much so yeah so. I can see that alms race going through audio audio worlds for decades, so yeah.
01:01:04
Speaker
and yeah And so so for all these reasons, FPGAs are ah very ah appealing. you And and so so this is why we really want to try to um ah provide support for this kind of platform. And ah as I mentioned earlier, currently the only way that we can do this in a way that makes sense is by using HLS. And and maybe in the future we'll be able to ah provide support for Verilog or the HDL, but currently we still have to depend on ah HLS tools, which is not necessarily a good thing ah because ah these tools are proprietary because they are provided by ah FPGA ah vendors and and and they only work ah with a specific brand of FPGA. So it means that ah if you generate
01:02:07
Speaker
optimized C code without for ah an HLS tool, ah it will only work well ah with a specific brand of FPGA. And so so it means that if you want to support multiple brands of FPGA, say Xilings versus ah Intel or you know like things like this, ah then you probably have to reinvent the wheel every time.
01:02:34
Speaker
Whereas ah if you can generate VHDL code or very large code directly from Faust, then you don't have to worry about this. Because VHDL code works the same way from one FPGA to another. And and VHDL code of works the same way from one brand of FPGA to another brand of FPGA. OK. Is that because it's a long established standard rather than something that's been invented by the manufacturer?
01:03:04
Speaker
Yeah, exactly. yeah yeah like you and ah And again, like if you want to program an FPGA, then usually you want to use ah those ah hardware description languages, which are supposed to be generic and work the same way ah across ah FPGAs. so It's funny, there's a definite parallel here between this and like the the evolution of graphics cards, their dedicated hardware, their dedicated languages, so that people can call them from say, yeah, yeah, I can totally say that. Maybe we should zoom back out because we've been right down in the binary. If we zoom back out to the language itself, I'm just,
01:03:50
Speaker
it's It's so wide, right? that the From writing this high-level, functional-ish language to generate audio right down to burning a temporary piece of firmware. Now, I know you teach this stuff as part of your job. How much of that do you dive into? And how do you teach people that aren't traditionally programmers how this thing works?
01:04:18
Speaker
honestly i i don't like i you know it's a i mean Audio DSP itself is a very big field. you know and and Even if you take a very good students in the top-level universities or whatever, usually you can only scratch the surface of all the things that I talked about here. I don't.
01:04:47
Speaker
Because usually, and also, you know, like, it's not necessarily the same students who are interested ah in ah compilation, designing programming languages, e etc. Then the students who are interested in doing audio signal processing, right? ah yeah Usually, students who who are doing audio DSP are electrical engineering students, ah and students who are interested in making compilers and creating programming languages, and there are actually not many students who are interested in that anymore. ah Usually those students are ah computer science students, right? So and when I ah teach ah those things, um
01:05:33
Speaker
I very rarely not to say never teach them all together in one big class you know it because it's impossible. you know and ah and so ah so I do teach classes ah sometimes in computer science and the and then we have to focus on ah maybe like the the language design aspects of things, you know but ah but ah but it's very rare when you can combine all those things together as i just ah as we as we do in Foust basically. you and yeah and
01:06:06
Speaker
and so so yeah I do teach classes where I use Foust as a tool for teaching signal processing ah audio signal processing.
01:06:18
Speaker
ah but um It's very rare when we ah delve into ah the details of how Faust actually works, because learning audio signal processing itself already takes a lot of time. and Usually, ah you know like ah this already targets students who are master students ah in their last or you know like ah year before last year or something like this. you know i kind ah and so um
01:06:51
Speaker
So yeah so the yeah the the audience for the kind of things that we do is actually not that broad. I can see that. they Your students are going to be just in that stage of specialization, and what we've talked about probably covers four different career paths. Yeah, pretty much.
Learning Resources for Faust
01:07:11
Speaker
um So so you know we we do have students ah who end up working on those things, ah but usually they're PhD students.
01:07:19
Speaker
you know and and and There are students who basically have the time to learn all those extra things that they need to know to to actually be able to do things like this. you know like but ah but ah but yeah In the end, like it's really hard just to teach a class on something like this.
01:07:38
Speaker
Yeah, yeah, I can totally believe. I guess possibly I'm going to guess that the way you do it is start by being hands-on because it's a terrifically hands-on language. You can type some code and you can literally hear what the results are.
01:07:53
Speaker
yeah you know what's so What's cool about FOUST is that ah it just works pretty much right away out of the box. you know and ah and With just one line of code ah written in a web browser, ah you can't actually get a sound.
01:08:07
Speaker
you know and ah so So I personally don't do that because I don't necessarily have the time to do things like this. you know like but ah But I have some colleagues here ah whose ah job is to actually do this in middle schools. and ah and Okay. in ah in high school because it's very much accessible to ah middle school students, ah even though they don't necessarily have any background in in programming or even in audio signal processing. of course you know like the
01:08:43
Speaker
the The language is easy enough to learn ah that ah you can write ah code for a simple musical instrument or an audio effect processor ah just with one or two lines of code.
01:08:59
Speaker
el So this takes me to maybe a something something else here. So a couple of years ago, we had ah we had a project called Amsterdam Gram. okay And the goal of Amsterdam Gram is basically to ah teach um ah sciences ah for middle school students through the programming of musical instruments, which are programmable musical instruments.
01:09:31
Speaker
and and so you know ah all right so It's probably not going to be ah easy for those of you who are listening to this, you know like but for those of you who aren't watching, I can actually show you this musical instrument that I'm talking about, and then I can describe it for those of you who aren't listening. The combination video podcast come radio podcast now emerges in full.
01:09:58
Speaker
So this is ah this is the gramophone. And the gramophone basically looks like a Bluetooth speaker in a way, right? It looks like a jar of strawberry jam with knobs on. Yes, pretty much. And ah and then ah you can just ah put it in your hand like this. So there is there is a strap in the back. and The strap allows you to hold the strawberry jam a jar ah de directly in your hand, which gives you access to the different buttons and knobs which are placed on it. And so this device is basically programmable and fast. And it's battery powered, so it's completely standalone. And alone and and the the battery can last for about 20 hours, so so it means you can jam with it for for for quite a lot of time. Right. and
01:10:54
Speaker
And so ah so basically that thing is programmable with Faust. And so what those um students do is that they they learn how to program those things to make a sound but and then to map the different sensors that you're going to have on this instrument to a given Faust ah program.
01:11:13
Speaker
And so there are physical sensors that are mounted on the body of the instrument, so you have knobs, potentiometers, and things like this. But there is also ah motion sensors that are built-in in these instruments, so so like accelerometers, gyroscope, compass, and etc.
01:11:32
Speaker
and ah And all those sensors can be mapped to sound synthesis parameters. So, for example, say that ah you want to run a sine wave oscillator on this instrument, and you won yeah you want to map the frequency parameter of that sine wave oscillator ah to the x-axis of the accelerometer, then It's very easy to do this. You only need one line of code and fast to do that. and And then you can export that instrument to to the gramophone, which I'm holding in my hand. And then you can potentially control the the frequency using the x-axis of the x-arimeter, which would probably sound like, ah you know depending on yeah how you ah ah orient ah the the gramophone in space. so
01:12:24
Speaker
That sounds like it would be an incredibly fun school lesson and an absolute din. Well, and a huge mess, too.
01:12:34
Speaker
you know Usually, kids love this ah because you know it's very ah tangible in a way. you like and ah and But like ah when you have 30 middle school students um manipulating the frequency of a sine wave all together with those very loud speakers ah like in the same room, and yeah it's it's rough. like ah It's probably one of the reasons why I'm not the guy doing this. you know like so yeah
01:13:05
Speaker
My sister-in-law is a teacher and she's done harder things to try and get the kids inspired, but I don't envy the job at all. oh yeah no no i mean I totally respect it. you know and ah and I think it's great that there are ah ah colleagues ah who are patient enough to do this, you know like but ah but like ah yeah it's it's kind of it's kind of crazy. so yeah All that to say that if you want to learn fast or if you want to use fast you don't have to be an expert in anything you know you can ah you can write very low level code if you want to ah if you're like a dsp engineer but if you're a middle school student and ah you just want to ah
01:13:45
Speaker
use objects which are already implemented in fast and then ah map ah them to potentiometers or things like this, you know like then it's really, really easy to do. you know And ah and so ah so it's really open to a lot of people, not just experts.
01:14:04
Speaker
Nice, nice. Okay, well that that perhaps leads into the final question then for the audience of this podcast. If someone is an experienced programmer looking to experiment with this very unusual programming language in a new domain, where should we go first? Where do we start?
01:14:23
Speaker
I think the the first thing that you want to do is to visit the Faust website which is ah Faust. so f a u s t dot gram G-R-A-M-E.F-R.
01:14:37
Speaker
ah Link in the show notes. Yeah, and so ah so on that website ah you'll get all the information to to get started ah with Faust. Then if you want to do something a little bit more advanced, ah so a couple of years ago with Jan, so the the the guy who created Faust, we recorded um we recorded ah an online class about Faust on the Cadenze platform, Cadenze, which is spelled K-A-N-D-E-N-Z-E. and It's a platform based in in the US. And and Stanford University, ah where I used to teach at the time, was collaborating with this platform to do ah yeah like online courses. And so you you can take an online course for free on fast. On this platform, the course is about five, six years old now. So it's starting to be a little bit ah old, but ah but it's still
01:15:42
Speaker
Fairly up to date, so so I think that's kind of the ah the next step after going on the first website for our learning fast. Okay, start there and then maybe in a few years time, your ah your unique physical hardware instrument will be used on the next Taylor Swift tour.
01:16:02
Speaker
Yeah, who knows? Who knows? That's what the real money is. Yeah, well, yeah like yeah yeah well if one of you knows Taylor is Swift in person and you think she'd be interested in collaborating with us, where we're definitely yeah up into suggestions. Awesome. Taylor, I know you're a huge fan of the show, so get in touch. Until then. Roman, thanks very much. that was That was broader and more fascinating than I could have possibly guessed. Thank you.
01:16:31
Speaker
Okay. Well, thank you very much. And yeah, thanks for inviting me to this. That was super, super fun. Yeah. Thank you, Romare. So take a look in the show notes for all the links. We covered a lot of ground this week. I'll make sure the first link is to that fast environment that runs in your browser. And you can literally go and code some audio pipelines right now. It's tremendous fun. And given that most of us work from home these days, you can play with it right now and program some weird noises and be sure that you won't bother anyone else in the office. So take five minutes to play.
01:17:06
Speaker
I've used it actually myself to program an echo effect for one of my synthesizers, and it was really easy. So give it a try. If you've enjoyed this episode before you go, please do take a moment to like it, rate it, maybe share it with a friend. If you want to support future episodes of Developer Voices, consider signing up to our Patreon. And Taylor, I'm looking at you. I know you can afford it. As soon as you're off the eras tour, I want you to sign up.
01:17:32
Speaker
And on that note, it's probably time to go. I've been your host, Chris Jenkins. This has been Developer Voices with Romain Michel. Thanks for listening.