WolfSound enables everybody to learn about audio programming.
My name is Jan Wilczek and I am an audio programmer and researcher. Welcome to WolfSound!
WolfSound's mission is to provide high-quality, informative, and entertaining videos, articles, and courses on how to process sound by exploring mathematics, applying algorithms, and creating code in various programming languages.
How's the market for audio programming? I mean salary wise and number of opportunities wise. Just came across your videos, and I am kind of mesmerized by the whole thing!
Cześć Jan! Masz może na kanale odcinek jak zacząć działać w audio programmingu? Jakieś pierwsze projekty, które warto robić na początku? Albo, polecasz jakieś książki, które są wartę uwagi? Bardzo by mi pomogły odpowiedzi na te.pytania :D
Speaking from experience - doing stuff on the audio thread is a dantean experience in rust. It's definitely not for beginners. So you know like in C/C++ you can prealloc an arena or maybe an object pool and just use it? In rust custom allocators are unstable and prepare yourself for wrapping every single one of your objects in MaybeUninit. Shared mutable state is kinda unavoidable in audio - hence you will end up using RefCell or UnsafeCell more than a healthy amount. Slice accesses are bound checked unless the compiler can prove that it's impossible to get out of bounds, So you either go with processing every sample in a foreach loop using maps and zips or have to agree to making a wrapper type around a raw pointer that overloads the [] operator which is a footgun waiting to fire (rust is way more strict about aliasing than c++). And the solution is to actually place asserts that will be present in your release build as well, which check if your input and output buffers have the same length - how would one guess that?
Regarding what you say at the 42:00 minute mark, I don't seem to actually get that much aliasing for the square and saw on my physical devices. Maybe I need to listen more carefully :)) Anyway, great tutorial series! It was really rewarding to me and I learned a lot of C++, Kotlin and design patterns in general. It's really helpful to someone who's still in college and feeling like college isn't helping enough on the software engineering side.
C++ is tying to do all and exceeds in none. I agree and there is even more like 'never use new and delete in modern C++' , obfuscated templates that literally do nothing but mask your code, RVO and copy elision are not guaranteed by many, you can still mix C and C++ code in C++ projects. C has a standard and is easy to use without obfuscation. Also I'd not advice boost on modern C++, it's a mess, boost must go, there are Juce, Qt and Poco nowadays for big projects. I am not familiar with Rust or Carbon but C++ is becoming the new COBOL. I am professionally programming in C++ and it's just not good anymore.
At 47:44, the fact that you said "please don't do anything right now" in such a professorial way was really cool. Leaving in the "mistakes" done when coding (rather than editing them out) really makes this a more genuine experience. Thank you for that!
Haha thanks! I sometimes like to leave code that does not compile in to show compiler error messages; otherwise people may be unsure why we write things the way we write them. Cheers!
Thanks for your detailed analysis for C++ ( mostly bad side) . When I see the Juce sponsorship in the end of the video , it comes to my mind that maybe you can give detailed information about Juce's license management in another video.
When you use C++ frameworks you don't have full control over which source files are built with your custom target. JUCE is an example of this: you can run into compilation errors of JUCE's source files when you set the warnings too high for your JUCE app or plugin. That's what I meant with setting warnings just for your project's source files.
@@WolfSoundAudio, have you changed the warning flags of third-party software? Why are you doing it? Or do you speak about the header files from the third-party software? Here, the system includes paths are helping because it suppresses the warnings that originate from this header. Or maybe you speak about your build system? Do you use CMake?
my beef with C++ is less with the language itself than the culture surrounding it. too many devs I've worked with treat C++ as ersatz Java, over-relying on virtual functions and dynamic polymorphism as the first and only solution to any given problem. next is the lack of a good dependency management and build system, as you say. I want the build system to be an afterthought, like it is in rust. it downloads, installs, and links all dependencies, no problem. I don't have to munge my way around header files to get templated code to compile, it just works, out of the box, on every platform it is supported on. on that point, I would like true pattern matching to be built in to C++. no, std::variant doesn't cut it, not nearly. it's a pale imitation of what pattern matching is in languages like prolog, ocaml, haskell, i.e. declarative and recursive syntactical destructuring of values. variant just matches on the outermost type, missing most of the expressive power of proper pattern matching.
@@WolfSoundAudio hope so! stroustrup presented a pattern matcher at cppcon several years ago but TMK it was patched together from C macros. I hoped it might at least become the basis for a new standards proposal but I haven't heard anything about it since.
To me, the ugliest ugliness in the language is macros. It's an extraordinary mess. There's a reason why Stroustrup doesn't recommend it. While it's great flexibility, it can also be a big problem. It also becomes very difficult when you want to use libraries that were created with different build systems. The "Import Export" in modules is also very funny.
What really can a compiler to do offer defaults and the most fully-featured standard library possible? Even if they recommend defaults and provide a standard library that doesn't mean 3rd party options aren't better and should be used instead. In fact people often complain about the standard library in C++ and recommend other alternatives. Not saying your points aren't problems but I don't think C++ can help you here more than other language. Btw, I'm not a C++ programmer by any means and these problems you mention seem to exist with all compilers, just some more than others.
Sometimes???? Cpp always sucks. We just put up with it because of the control over the code and speed of the final program. Compile time really kills it.
@@chocolatezt A lot of people are complaining about compile times in the Reddit thread: www.reddit.com/r/cpp/comments/1dvdhtu/opinion_which_parts_of_c_i_find_difficultannoying/ I have experienced it myself in that it can be really demotivating and defocusing 😉
I've used pascal for years which has declaration/definition split in modules where you need to modify the declaration in 2 locations. It's annoying but I like it creates ledgers for the type at least. In other languages I've used like Swift/C# there are no modules or forward declarations and it's all just dumped into files and the compiler figures out how to link it together. The downsides to this are it's slower to compiler since the compiler needs to resolve types and it's kind of messy to have all the code and types mixed together, although practically this hasn't been a problem it's just not as orderly I would say. Hard to say which is best for me personally.
I know about nothing about C++ but here on RU-vid i saw at least few very good presentations(most from some C++ conferences) about co-routines, which even i understood (with code examples)
I love synthesis, have had multiple attempts at writing a synth, and have some experience with C++ and Kotlin, but I'm only a poor undergrad who has no experience writing cool software projects by himself. Needless to say, I had to pinch myself when I saw that this video series existed. Thank you for making this content!
Slow compile time, difficult to set up modern environment, have to learn another language for cross-compilation (CMake), too many ways to do the same thing, etc.
Otherwise the community will create different solutions anyways and you end up with different dependency management software and the hell that is c++ and java dependency management
That is like saying standard library should not be a part of a language it makes no sense, people are going to need it so you might as well create a central and stable one
@@foxwhite25 Agreed on the point that 3rd party package managers can either evolve too fast in their API (like Conan) or can stop being developed. With standard stuff it's less likely to happen.
I really don't understand the anger with header/source split. I get it only when the objection revolves around using the preprocessor. But the split is beneficial in 2 areas that I find helpful in practice: 1. The header gives you a helpful summary/overview of the class. It helps with readability because you are onboarded quickly when you understand the shape of the class at once glance. It also helps with maintainability because it outlines the shape of the class and lets you better think about refactoring it when looking only at the outline. 2. Sometimes definitions can be lengthy. You might need to split the definition of methods into two source files to help with maintainability. Also this might be a code smell if you have many methods are too long. PS: Modules are heralded as the bane of headers but in actuality modules also support the split between declaration and definition. However, they get rid of the preprocessor which is the actual bad thing about headers.
Split has sense only when it is used as binary blob later mostly for libraries (way to save compilation time/space in the past). Even TurboPascal had it in one file without problem, C++ should support old C ways but should have something better (modules?) decades ago.
Thanks for your feedback, I definitely agree with point 2 😉 I'm not sure if modules will fix things because there are still too few projects supporting them unfortunately...
Having to update declarations in multiple places is annoying I think we can all agree. I've used pascal for ages now which has modules but you still have the duplicate function declarations. It's not a big problem in the scheme of the things but it's a point of friction for sure. What you gain though is a nice ledger of types and clear separation between code and types which is easy to browse.
Linting problem is a compile languages problem. Can't be fixed. If Rust lives long enough it too is gonna have a pile of style guides from all the lovely ends of the universe. It seems your mic picks up some background or side crackling events. Which is very confusing at moments.
Thanks, that's interesting: are there alternative style guides for Rust besides the official one? Thanks for the mic remark, I’ll fix it the next time 😉
@@WolfSoundAudio IDK about Rust standards. But I mean it's still a baby. When it's a mastodon like C++ some decades from now most probably it'll have a ton of different standards just the same.
