CppCast - Elements GUI Library

Episode Date: May 5, 2022

Joel de Guzman joins Rob and Jason. They first talk about new features in GCC 12 and the latest ISO papers. Then they talk to Joel de Guzman about his history with Open Source and the Boost community, the Elements GUI library and his work with audio software and hardware. News New C++ features in GCC 12 April 2022 Mailing Core C++ Call For Papers NDC TechTown Call for Papers Links Elements C++ GUI Library Artist 2D Canvas Libray Cycfi Research Boost Spirit Patreon CppCast Patreon

Episode 348 of CppCast with guest Joel de Guzman recorded May 3rd, 2022. This episode of CppCast, we're thanking all of our patrons on Patreon. Thank you so much for your ongoing support of the show, and if you'd like to support the show too, please check us out at patreon.com slash cppcast. In this episode, we talk about new features in GCC. Then we talk to Joel de Guzman. Joel talks to us about the Elements GUI library, his contributions to Boost, and much more. Welcome to episode 348 of CppCast, the first podcast for C++ developers by C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? All right, Rob, how are you doing? Doing good. Had a chance to go by a conference the other day, I heard. Well, yeah, so I'm not speaking at C++ now, but I took a couple of hitchhikers from Denver International Airport up to Aspen and hung out for one night and crashed the opening ceremonies and gave away a few puzzle books and it was fun.

Very nice. And the conference is going on, what, like Monday to Thursday this week? Monday or Thursday or Friday. I think they usually have a half day on Friday. I don't know. I didn't look at the schedule. It's something like that. And of course, it snowed on the first day because that's what it does in Aspen

when we're in C++ now for May. It wasn't sticking on the ground in Aspen, but on my way back as I was coming near Vale Pass for people who know the area, it was like a picture book, like winter wonderland painting. All of the pine trees were heavy laden with several inches of fresh, heavy spring snow. And it was really, it was made for a pleasant drive, except I kept getting a little nervous that i might hit icy patches on the highway but that part's not fun yeah i mean it had been warm enough and enough cars on the road that there was no actual ice it was fun all right

well at the top of every episode i like to read a piece of feedback we got this from christabella asking us to promote this tweet he sent out saying, got a moment to say how Clang's diagnostics can be improved. Our team wants to address users' biggest pain points with Clang's diagnostics and your feedback directly help us figure out what these are. Compilers should be helpful, not combative. And there's a link in here to a Google form doc where they're looking for feedback, Chris's team, on improving Clang diagnostics.

So it definitely seems like something that would be interesting to a lot of our listeners. And I'll put this link right at the top of the show notes. That's pretty cool. I mean, you know, Clang pretty much already has the best diagnostics at the moment, I think. I mean, GCC, they're pretty close, but always good to see better reporting.

Yeah, definitely. All right. Well, we'd love to hear your thoughts about the show. You can always reach out to us on Facebook, Twitter, or email us at feedback at cppcast.com. And don't forget to leave us a review on iTunes or subscribe on YouTube. Joining us today is Joel de Guzman.

Joel got into electronics and programming in the 80s because almost everything in music, his first love, is becoming electronic and digital. Back then, he used to build his own guitars, effect boxes, and synths. He enjoys playing distortion-laden rock guitar, composes and produces his own music in his home studio. Joel's the main author of the Boost.Spirit parser library, the Boost Fusion library, and the Boost Phoenix library. He's been a professional sound software architect and engineer since 1987. Joel specializes in high-quality cross-platform libraries, particularly but not limited to those written in C and C++. Joel's an expert practitioner

of modern C++ techniques, template metaprogramming, and functional programming with a focus on generic programming and library-centric design. Joel, welcome to the show. Hi, nice to be here. Thanks for coming on. So when I was just in Aspen yesterday talking to a mutual friend, he told me that I had to ask you about how you specifically got into programming. Like, what was the thing that drew you into programming to start with? I started doing electronics. So I think that short biography gives you a hint on how it started. So my father was an electrical engineer and I got amazed with what he's doing and he's doing really cool stuff back then. So I started with analog electronics, actually. And so I got interested with doing effects, distortion, and all that kind of stuff.

And then the 80s came, and this shift towards analog to digital started to happen in the 80s. So, okay, I've got to learn this thing. So that's how I started when I started doing C++ so before it was Pascal it was nice but then later in the 90s I moved on to C++ and that's specifically for like making guitar pedals is that what you're saying oh no okay so in the 90s on the most of the 90s i went to japan i worked there as an engineer so we did kind of cool stuff like we started doing the graphical user interfaces and a whole operating environment on top of operating systems. So that includes the whole thing for rapid application development. That was a huge endeavor at the time.

So it took us a lot of time in doing that. And so we got funding for doing research from the Japanese government at the time. So that was the time when I actually started writing graphical user interfaces and got involved with, well, more in-depth into C++. So that's the time when I got into open source. I got interested with open source. I remember meeting up with Michael Tieman. So he's one of the original G++ authors, if I remember correctly. And I'm not sure what he's doing now, but he was

with Red Hat, one of the VPs, I guess. I'm not sure about the details, though. I've got to meet some cool people over the internet through Andre Alexandrescu. So we corresponded a bit through email. And so I got hooked into this template metaprogramming thing. That was before the dark ages of C++, you know? So that was a time where things didn't really work the way they're supposed to work. We didn't have the features that we have now. We take for granted now.

We have to work around all those things at the time. And we have to contend with lots and lots of internal compiler errors and incompatibilities with different compilers, especially MSVC, which was the most difficult compiler I had to deal with at the time. Right. All right. Well, Joel, we'll get more into your bio and some of the work you've done in open source in just a few minutes, I think.

But we do have a couple news articles to talk about, so feel free to comment on any of these, okay? Okay. Okay, so this first one is a post on Red Hat developer blog. And this is new C++ features in GCC 12, which looks like it's coming out in, or did come out April 2022. Yeah, and lots of new features in here.

Some C++ 23 features coming out in this, like if const eval, or am I reading that wrong? No, that's, yeah, C++ 17 was if const x were const evals of C++ 23, right? What else do you want to highlight in here, either of you? The main thing that stands out to me personally is the possibility that they allied standard move, standard forward, address of,

and as const even in debug builds because this is something I brought up in a talk several years ago and Corentin I know was working on doing this kind of elision of these calls and debug builds and clang I think I don't recall if Corentin was involved in the GCC version or not if I have that story backward. But in a debug build, it's kind of ridiculous to see effectively casts inserted into your code. So you have function calls that are just casts, but they have the ability to align them now in debug builds. I find that interesting.

I got to read some of the stuff, so I'm interested with multiple arguments for the array subscript operator. So I got interested with that, particularly because I used23 to use comma operator inside of the subscript call, GCC does specifically say that if they detect that there's a comma operator overload, they will still allow it and emit a warning instead of going to the multi-argument subscript operator. An aspect of this that I actually recorded a C++ Weekly episode on this, but an aspect of it that I had never considered, that means that you could have multiple subscript operator overloads. You could have one that takes one argument, two arguments, three arguments, if you were so inclined. I don't really know what the full use case is, but yeah. You'll never know, right? Next thing, we have another ISO mailing. This is for April 2022. Not the biggest one, but I'm recognizing plenty of the papers in here. We obviously were just talking about the linear

algebra libraries and MDRA, MDSPAN last week. Those are all getting updates in this. We obviously were just talking about the linear algebra libraries and MDRA, MDSPAN last week. Those are all getting updates in this. There's also an update to NBED, Jean-Huidh Manid's paper. Release five of that one. Yeah, I didn't check to see what was actually different in it, but I'm glad to see it's still being updated, still being worked on. Yeah, I also didn't read it. Anything either of you want to highlight in this? I think it's kind of, I don't know, maybe slightly humorous or something to just point out that Victor's updates to format are now at revision 14. I don't know when that paper will finally fully get accepted and merged. I think it's, you know, to give things like format colon colon print

instead of having to do cout of a formatted string or whatever. There's another one in here. Oh, yeah. First revision of a paper to give a description to equals delete. So if you explicitly delete an overload to be able to describe why so that the user of your library knows, hey, you called a deleted function. This is the one you should call instead.

This is why this was an error. Yeah, that makes sense. I don't know if the syntax is going to apply, though, just looking at it myself, but I'm not in evolution, so. Right, and then the last thing we have is a couple call for papers for coming conferences. This first one is for Core C++ 2022. That conference is going to be in September,

and the call for speakers deadline is June 15th. So those errors you will have right at a month. Yeah, just about a month. And then we also have one for NDC TechTown, and this one has a deadline. Is that May 1st? Oh, no. That's my fault.

I put it in there. So, yes, the deadline has already passed. I didn't submit a talk. I debated it. It's too late now. Okay. Well, so, Joel, we were already talking a little bit about how you first got involved with C++.

Could you maybe tell us about how you got involved in the Boost community? So after Japan, we went back home. But that meeting with Michael Chim and got me thinking about open source. So I know that you can build a career on open source at the time. But I couldn't explain that to my boss. So there's no way for me to articulate how that'll work. So how will that happen if you give your software for free? So that's a basic question there. I still got thinking about open source and I was still emailing and joining the news groups and C++ news groups at that time. And there's when

I got involved with Boost. So I was thinking maybe I could take a portion of the library that we created in the 90s and rewrite that using what we called at the time the modern C++, which was coined by Andre. So it's not the modern C++ that we know now with the features that we have now that we take for granted, you know. That's a time when I thought, okay, so a part of the framework that we wrote was the parser library. And so I rewrote that part using template metaprogramming and that became Boost Spirit. So that's how I got involved into Boost. So there were lots of interest when I introduced BOOST Spirit into BOOST, and it got accepted. There was an article at the time I wrote along with Don Nuffer. That was not C++.

No, that's Dr. Dobbs, if you remember these magazines at the time. So the C++ report was a big thing at the time. And so I got to, these were the source of information for current C++ at the time. And so we wrote an article about Spirit, which kind of catapulted it to the C++ community at the time.

It got accepted into Boost. And that's how it started. I'm just out of curiosity. When approximately was that, that spirit was added? 2001. Okay. I got involved with Boost. So initially I was in a lurk mode.

So that was in the late 90s and I was still in Japan. So I was following the late 90s when I was still in Japan. So I was following what's happening. There were Dave Abrahams and Beam and Dose. And then I got to introduce Booth Spirit out of nowhere. So people got interested with what I was doing. So are you still involved in the maintenance of Spirit today? Well, there's a lot of things to do.

So I have lots of libraries. Someone else is maintaining it for me, but I'm still involved with reviewing pull requests and stuff like that and taking part in the conversation. I wish I had more time than I have right now to do more of the boost libraries that I authored. That's a long history, 20 some odd years to still be involved. I can't do that. I give up after 10 years or so. Hey, everyone, quick interruption to let you know that CppCast is on Patreon. I want to thank all of our patrons for their ongoing support of the show. And thanks to our patrons, we recently started using a professional editor for CppCast episodes.

If you'd like to support the show, too, please check us out at patreon.com slash CppCast. Let's talk a little bit about a newer library you're working on, you know, a listener suggested we talk to you about, and that's Elements. Can you tell us about Elements? 2016, I was looking for a graphical user interface library that I need to write GUIs for, set of audio plug-in software that I've been writing for the projects that I'm involved with. But for a long time, I was searching for the projects that I'm involved with. But for a long time, I was searching for

the library that I was looking for, but nothing really clicked. So I thought that it might be a good idea to modernize the concepts of the graphical user interface libraries that I wrote in the 90s and modernized into C++ 17, at least at the time. So that was 2016. And so that became Elements. So it has to be modern C++. So I'm a proponent of modern C++. So the 90s style virtual functions and all that stuff. But I still do that, though, but not in the way that there's a modern twist with it. And so it has to be lightweight, modular. I think the main thing that necessitated me to write this library is that, first, it must have a liberal license. I don't like viral licenses. And that leaves me with only one option at a time, which was Jews.

But it has a viral license. And so that's out of the question. So that's why I started Element. So it has to be modular because the library that I need cannot have control over the event loop, for example, because it has to coexist with other libraries and frameworks. Right. So you said audio plugins. Yes, audio plugins. Exactly. So at the time, the only option at the time for doing that was Boost and this thing called iPlug.

But those are kind of monolithic things. And I'm not really quite happy with the way C++ was implemented or how everything is structured. So that's how it started. So when writing audio plugins, you don't even have control over creating the window yourself. Most of the time you'll be given a handle to the window and you draw your interfaces with that. So that's the modular part of the elements. It has to coexist as it is and be able to be transplanted into other frameworks and libraries and the operating system. So just out of curiosity, you said not having a viral license

was very important to you. What license did you end up choosing for Elements? MIT. Okay. But I think I'm going to switch back to Boost license. And you said you've been working on it since 2016 and the screenshots you have on the GitHub page do look really beautiful.

So it sounds like the library's come a long way. Is anyone using it in production? I only implement what I need for my specific use cases. So I've been working on it on and off. And there are other contributors working on it, implementing other features. So I'm going to take this opportunity. So it'll be great if I get help from other people who's interested with writing graphically user interface widgets and all this stuff. There's still a lot of things that needs to be done.

I'm not even considering it to be 1.0 at this point. I'm already using it in the applications and plugins that I've been writing. And other people are using it for other plugin libraries, I guess. Some more applications here and there. But I don't know yet of the application that's using it at this point. for other plugin libraries, I guess. Some more applications here and there. But I don't know yet of the application that's using it at this point. So it's kind of still new. Although I wrote it in 2016,

I only officially introduced it in, I think, 2019. That already involved lots of evolution from the original implementation. And that's where artists came in. So at one point, I thought it's a good idea to separate graphics, part of the library into its own and target graph 2D libraries like Skia and make it more suitable for more higher performance applications. So graphical user interface applications. Recently I've been having help from Benjamin Aldenberg. He's doing metal on Mac and D3D on Windows.

And I know you'll be asking about package support, so he's also working on VC package. You mentioned at the start of the description that you were trying to avoid things like virtual and the design, if I heard you right. And GUI frameworks is like a classical use case for virtual because you've got your button widget, your slider widget. They both need a draw method. They need a whatever. So I'm curious, did you manage to avoid virtual in those cases? Okay. It's not that I'm avoiding virtual.

It's just that I'm trying not to think of the abstract class using virtual functions as the one and only means for writing graphical user interfaces, writing classes for widgets and all this stuff. And so you can, at some point, manage to do it without virtual functions. One of the design objectives of Elements is that it has to have a declarative API using modern C++. So I'm a proponent of declarative C++. And declarative C++ essentially tells you, the code tells you what rather than how imperative. So the GUI is actually declared in C++ code

instead of having an external code generator or graphical interface builder to build it. So everything is self-contained in the C++ code. I really like that because I have control over everything in C++. And so at some point with declarative C++ where everything is defined declaratively, you are able to use more of the modern C++ mechanisms instead of abstract classes and virtual functions. So I have a mix of the two worlds. I still need virtual functions and type erasure in general to store widgets into vectors, but for a large portion of how you're using the library, you're able to capture the essence of the elements composition without having to go to virtual functions, without having to use this kind of stuff. So you can actually have a compile time representation of the GUI interface

without having to call virtual functions necessarily. Exactly, yes. Or at the very least, the compiler will give you the freedom to choose which ones you want to have as dynamic and which ones you want to have static parts. You'll have highly optimized parts of the graphical user interface. Not that it's needed, right? Because with graphical user interfaces, the bottleneck is, of course, the screen. So it has to be drawn on the screen.

And so it's not like what you do with really high performance computing, for example. But it's there and it's tight and it's nice. Well, it seems like that it's the kind of concepts that would go nicely with, like I'm wearing my Garmin watch here, where if you know certain components on a small embedded platform with its user interface, certain components are compile time known static, then you can take advantage of it there.

And in the small cases where the user needs to be able to drag a widget around on their watch, there could be dynamic use cases. So I could see those things working nicely in small platforms. Right, yes. And one of the reasons is that it has to be simple and small. So I tend to avoid the temptation of having all the features crammed into the library. You talked about how you're mostly using this to target audio plugins, but you can make your own full GUI application with this library, right? Oh, yes, absolutely, yes. What platforms does it support currently?

Currently, it supports Windows, Mac, and Linux. That covers most devices. I still have to look into, you know, iOS and Android. So that's one thing that I really want to get into. Maybe I don't have an actual need for it right now, but some people do. And if you're one of that, so it's open source, so you're welcome to contribute to the code. Another thing that caught my attention was you said in the audio plugin world, sometimes you're simply given just a handle to a window, and that's what you have to draw into. Does that mean that the way I'm envisioning this, you must have had to have designed it to be very portable to be able to say, well, here's some pixel array that you have to work with, now go do your job or something like that? Yes, exactly. So there are only a couple of files that needs to be

implemented. It's very portable. Only a few handful of files that needs to be implemented to have it running on other platforms. In fact, it's not just other platforms. For example, it's very doable to have it transplanted into, for example, Qt. Okay. So if you had a canvas in Qt, you could draw. Yes, exactly. So anything that I give in the handle to a view, a window, a sub-window, you can draw into. You can have elements running there. So it can run on top of traditional and graphical user interfaces, for example.

Sounds like then porting to WebAssembly or Emscripten or whatever should also be pretty easy because then you can just draw into an HTML canvas. Oh, that too so oh well the 2d graphics part was inspired by the html5 canvas actually oh that's the artist library referring to the artist library yes okay i implemented that it's not so thin abstraction layer on top of Quartz 2D and Amskia and Cairo. So there's that layer and then the abstraction of that is that the interface is more like W3C canvas. There's been a couple of times that I thought

it would be cool to make an interface that was just drawn with all SVG elements or all like vector-based elements. And then I found myself looking at like the Cairo API and saying, nevermind. So if you've given like a C++ higher level view of being able to do this kind of scalable graphics, is that what you're saying?

Yes. view of being able to do this kind of scalable graphics is that what you're saying yes so essentially it's a superset of the w3c canvas interface with a modern c++ twist so i didn't like aesthetics like instead of camel case i have you have lowercase and underscores, things like that. Are artists and elements directly related to each other at all? Are they completely independent projects? Those are independent projects. So they have their own GitHub repository. Artist is independent from Elements, but Elements uses Artist as the 2D drawing layer. So that's the layering there. So if I just want to draw some high resolution vector graphics, I can grab Artist and render that to some frame buffer of some sort? Absolutely,

yes. And like pull out the alpha channel support all the normal things that you would need for this kind of thing yep that sounds pretty cool i might have to play with that it looks like it's gotten less visibility than elements so far not quite as many people contributing in such moments maybe that'll get some visibility as well oh yes so i love that well the thing is that elements started before i decoupled the graphics part it was monolithic the artists and elements was one and so around 2020 if i remember correct that's when i started decoupling the graphics part from elements and that became artist. Before it was just Cairo. I was kind of worried because I'm not sure what's happening with Cairo at the time and I'm not sure about the future of Cairo. And so I thought it's a good idea to also decouple the artist library from the underlying 2D engine such that I can target, for example, on the macOS, you can have it running under Quartz 2D and as well as Skia right now.

So you can do that in Windows, that's Skia, and Linux is Skia. But I'm considering backporting Cairo to Artist. Right now, the Artist doesn't have the Cairo port because of the API, Cairo doesn't have modern features like being able to blur images and stuff like that. So more of the advanced features of Ski, Cairo doesn't have that. So Cairo is kind of old in terms of features. All of this work is under a GitHub organization called Sykfy. I don't know how to pronounce that. It's pronounced Sykfy.

Sykfy, okay. It's the cycle of fifths. Okay, so I went to Sykfy's website. This is your company? Yes, it is. It looks like you're doing all kinds of crazy like guitar pickups, hardware, hacking, audio, things that I feel like a lot of our listeners would be interested in. If you want to just brag about your company for a few minutes, please do that. Okay.

Well, PsychFi was my baby from 2014. My main work at the time, I was consulting for Chiara, Michael Casey. And before that, it was consulting. So I've been doing C++ consulting for two decades now. And so that's still my main preferred line of work. But recently things evolved and sci-fi is kind of taking off. So with that, I'm still able to apply my love for C++ in doing this, as Jason says, some crazy stuff. I've been doing multi-channel processing where if you see that guitar behind me, that's... The one in the middle, the black one there? The middle one, yes.

Okay. That's made out of carbon fiber. And there's a microcontroller inside that. And it's running using modern C++. And it's doing multi-channel processing. So it's processing each of the strings individually. So the traditional way of doing thing is that you have your guitar, it's a monophonic instrument, and you have your effects

line. You have line of effects from distortion, compressors, and all that stuff. So you have that mono signal going through all those effects. But what we do is multi-channel processing such that each of the strings can have its own stream of effects. So we have, for example, with that six string there, you have six streams of effects, six streams of digital signal processing going on at the same time. And what's interesting with that guitar is that it has multi-channel sustain. So you can form chords and it won't die out. It'll sustain as long as you hold the chord. So there's a feedback loop, magnetic transducer,

that's sensing each of the strings and balancing out the levels of each of the strings such that it'll sustain as long as you want it to sustain and then after that there's stream of processors going on for each of the channels so that one is doing multi-channel sustain and then you get instead of the monophonic jack that you plug into an amplifier, I connect that to an audio interface, multi-channel audio interface with all of the six channels. It's capable up to 12 channels of audio. The interface is capable of that and then with a digital audio workstation, you can set up multiple effects for each of the channels individually.

So you have really awesome control over that. You can do lots of cool processing there. It sounds like you'd be capable of making some very unique music that you just could not have with a normal guitar plugged into an amp with this, right? Absolutely, yes. So is it possible for someone to just go to your website and buy one of these multi-channel pickups and retrofit their current guitar with it? Yes.

The multi-channel pickup can be retrofitted into a standard pickup slot, so it's the same footprint. Okay. I think what I want to see personally I mean guitars are awesome I don't play any musical instruments I'm not inclined that way but if someone were to take your multi-channel pickup and just make the world's most awesome input device for their computer so they're like jamming on their guitar and instead like programming, typing on it. I mean, like maybe someone will do that.

I'm not sure how that will work, but that's interesting. I mean, you've got all the frets, you've got all of the strings. I mean, arguably you've got like a 60 key keyboard, right? I mean, arguably, you've got like a 60-key keyboard, right? Yeah, that too.

That's another thing, though, because to do that, you need to do pitch tracking. That's one of the things that I've been involved with as well. Pitch detection. So it's difficult. Pitch detection is difficult. So especially low lat. Pitch detection is difficult. So especially low latency speech detection. So it involves autocorrelation of the signals and determining the fundamental and being able to determine which is noise and which is not, things like that. And being able to detect the onsets of when you start picking, that's also difficult.

So I thought it was a rabbit hole at the time when I thought, okay, I want to detect the pitch. When I have the pitch, I have the pitch information. I can do lots of really cool stuff with that. So you know that you have G2 or G3 or E5, you know, being able to determine the pitch. You can do lots of cool processing, but easy said than done. So it's still an ongoing process. But I do have really cool algorithms for detecting pitch and detecting the onsets. All right.

Well, Joel, is there anything else you want to plug before we let you go? Or anything we didn't ask you about elements or artists that you want to tell us about before we let you go? Yeah. that you want to tell us about before we let you go? Yeah, I'd probably just reinforce that, reiterate that. It's elements, it's not yet 1.0, and I need your help to have that into a state that can be production ready. I've been involved with Boost for a long time and interaction with the Boost community was awesome.

After Boost and Elements is not part of Boost. I'm not sure if it's suitable for Boost in the first place. I'm not sure about that. If there's interest, I'm not sure. But I crave for that kind of interaction that I'm not getting right now outside of Boost. So I will welcome anyone who's interested with the library. Have a look at the library. Have a look at the GitHub pages introduction and the examples. Try to run the examples.

And if you find it interesting, I'm very welcome to have you be part and contribute into the code. Definitely encourage our listeners to go check it out. Like I said, it's a beautiful library and it's good to see that you're interested in having more contributors. All right, Joel, thank you so much for coming on the show today. Thank you. And thank you for having me. Thanks a lot. Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too.

You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like CppCast on Facebook and follow CppCast on Twitter. You can also follow me at Rob W. Irving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.