3 ms·

"All my engine is in C++, and I’m really sick of SDL_DoThatThing(&options, pointer_to_void, size_in_magical_units, &callback, user_data, legacy_value) (sorry fo

"All my engine is in C++, and I’m really sick of SDL_DoThatThing(&options, pointer_to_void, size_in_magical_units, &callback, user_data, legacy_value) (sorry for all C admirers, I do respect you, it’s just that I’m not one of you)." How about Rust audio (https://github.com/RustAudio https://github.com/RustAudio) and then FFI? I am developing the audio lib for the music live coding language I design in Rust and I think the experience of Rust is really good, because of `cargo` (the package management), the community, the syntax and compiler, the ergonomics, and so on. For one of my usages, the audio lib in Rust compiles to wasm and runs in browsers smoothly. I can also write VST plugins with the same audio library in Rust: https://github.com/chaosprint/glicol https://github.com/chaosprint/glicol There are also many other Rust audio libs such as dasp, fundsp and hexosynth, all worth checking out. Before I became addicted to Rust audio, I had checked some C++ audio project, such as the Maximillian lib especially the JS bindings, the source code of SuperCollider and the JUCE for VST. But apparently I have made my decision for the reasons abovementioned.

lisyarus 4y ago
Adding a whole new language (meaning compiler, packaging, libs, ecosystem) into my engine just for the audio lib which I _wanted_ to implement myself in the first place? No, thanks.
- secondcoming 4y ago
  You insensitive clod!
- UncleEntity 4y ago
  I think you’re meant to rewrite your whole game engine in rust to make it easier.
Narew 4y ago
Doesn't you will have the same issue, a C-like interface. Maybe I missed something, but Rust and ffi mean you use a C interface from C++ ? The only C++<->Rust I know is either using C intermediate code or using cxx.rs but the support is limited ?
- chaosprint 4y ago
  Yes. But we can do it in the last step, right? #[no_mangle] pub extern "C" fn process( in_ptr: *mut f32, out_ptr: *mut f32, size: usize, result_ptr: \*mut u8 ) { let _in_buf: &mut [f32] = unsafe { std::slice::from_raw_parts_mut(in_ptr, size) }; }
pjmlp 4y ago
One does the same approach as Rust, wrap the unsafe C stuff into type safe C++ wrappers. Which the author did quite alright, minus the issue I discussed on separate comment. You will have better luck moving the audio industry from bad C practices into modern C++, than making most learn a complete new language. JUCE rules in the audio industry for example.
- chaosprint 4y ago
  This argument can apply to every application scene of Rust: no need to learn a new language. Yet the fact is that the Rust community is growing rapidly, from audio to embedded devices. I think the key is how much you can get from the investment, and I totally understand if people want to stick to the ecosystem they are already familiar with, a completely different story compared with a beginner. Also, I don't think the JUCE "rules in the audio industry". First, the most typical use case for JUCE is to write VST plugins. Second, the company ROLI was trying to develop another language called SOUL. Although its progress seems to stop now, it somehow shows that they are trying to provide something different from C++.
  - pjmlp 4y ago
    It is growing, it is like going through the C++ adoption as I did 30 years ago, and still there are domains it could never take over from C. So while it is nice for the security of the IT stack, we also need to keep things in perspective.

lisyarus 4y ago

Adding a whole new language (meaning compiler, packaging, libs, ecosystem) into my engine just for the audio lib which I _wanted_ to implement myself in the first place? No, thanks.

secondcoming 4y ago
You insensitive clod!
UncleEntity 4y ago
I think you’re meant to rewrite your whole game engine in rust to make it easier.

Narew 4y ago

Doesn't you will have the same issue, a C-like interface. Maybe I missed something, but Rust and ffi mean you use a C interface from C++ ? The only C++<->Rust I know is either using C intermediate code or using cxx.rs but the support is limited ?

chaosprint 4y ago
Yes. But we can do it in the last step, right? #[no_mangle] pub extern "C" fn process( in_ptr: *mut f32, out_ptr: *mut f32, size: usize, result_ptr: \*mut u8 ) { let _in_buf: &mut [f32] = unsafe { std::slice::from_raw_parts_mut(in_ptr, size) }; }

pjmlp 4y ago

One does the same approach as Rust, wrap the unsafe C stuff into type safe C++ wrappers. Which the author did quite alright, minus the issue I discussed on separate comment. You will have better luck moving the audio industry from bad C practices into modern C++, than making most learn a complete new language. JUCE rules in the audio industry for example.

chaosprint 4y ago
This argument can apply to every application scene of Rust: no need to learn a new language. Yet the fact is that the Rust community is growing rapidly, from audio to embedded devices. I think the key is how much you can get from the investment, and I totally understand if people want to stick to the ecosystem they are already familiar with, a completely different story compared with a beginner. Also, I don't think the JUCE "rules in the audio industry". First, the most typical use case for JUCE is to write VST plugins. Second, the company ROLI was trying to develop another language called SOUL. Although its progress seems to stop now, it somehow shows that they are trying to provide something different from C++.
- pjmlp 4y ago
  It is growing, it is like going through the C++ adoption as I did 30 years ago, and still there are domains it could never take over from C. So while it is nice for the security of the IT stack, we also need to keep things in perspective.