Audio Programming Environment 0.5.0: C++ DSP directly in your DAW!

[camsr]

Pruning NaNs / infinities will happen on outputs automatically, with red flashing light.

Optional idea to extend this information, is to add a counter to be able to determine the rate of these invalid calculations. This could help determine if it is an unstable equation, or conversely just a part of an algo hitting it's limits.

[mystran]

Pruning NaNs / infinities will happen on outputs automatically, with red flashing light.

Optional idea to extend this information, is to add a counter to be able to determine the rate of these invalid calculations. This could help determine if it is an unstable equation, or conversely just a part of an algo hitting it's limits.

This sounds great in theory, until you realize that when you put a simple DC blocker (or whatever) at output, the first NaN is going to cause every subsequent sample to also be NaN. With APE already have a concept of "probe points" it'd make a whole lot more sense to check these signals for NaNs and show a warning in the scope if any NaNs are detected (on per-trace basis and sticky, so a single NaN causes a message to show until you dismiss it).

[Architeuthis]

Do you provide any antialiased oscillators, oversampling, antialiasing filters?

[liqih]

Check it out, hopefully it can be useful or provide some fun!
- Janus

Lot of fun! Amazing work, I love that it recompiles on the fly while keeping the parameters setting.

[Architeuthis]

Is there a button somewhere that makes it compile on the fly or are you hitting the recompile button?

[liqih]

Yes, the recompile button when it's a circular arrow.

[Mayae]

I think a raw list of events should be available, as there are other potential ways to use MIDI (including note data) beyond standard voice allocation (which seems more like a candidate for a library utility).

I think that's a good place to start, for sure - it's probably the least I can do just to enable playing around with midi.

Good job, integrating clang/LLVM is a very complex and annoying tasks with lots of platform dependent issues (I made one, and just gave up after too many macOS updates and LLM updates that kept on destroying ABIs and header paths)! Happy to see someone else making this work

Thanks!! It was brutal, to be honest. At least when you consider only having spare time here and there to put into a project, and inbetween everything just changed in LLVM. Unfortunately I had to upgrade quite a few times during initial development as there were quite some bugs/issues in the JIT and integration - I dread the day I have to do it again

At the end I had to control the entire pipeline to keep my sanity; that's why I bundle libcxx and a C library as well. Trying to use system headers would be a compability nightmare.

Optional idea to extend this information, is to add a counter to be able to determine the rate of these invalid calculations. This could help determine if it is an unstable equation, or conversely just a part of an algo hitting it's limits.

I'll see what makes sense, but in my experience once a single NaN materializes, everything is poisoned beyond recovery.

Do you provide any antialiased oscillators, oversampling, antialiasing filters?

Hey!

No I don't, but it's a great question and IMO is a glaring omission from this framework. I think it could be cool to be able to automatically oversample X times on the fly just from the UI without changing the code, but you would probably need some library intrinsics for certain DSP algorithms regardless.

Lot of fun! Amazing work, I love that it recompiles on the fly while keeping the parameters setting.

Great!! Happy that it's getting some use

Is there a button somewhere that makes it compile on the fly or are you hitting the recompile button?

This could be added (like, let's say after a line break and some seconds of inactivity). Just in case it was missed, you can press F5 in the editor to recompile and hot reload.

[Architeuthis]

Next task: Create a visual programming environment on top of this one.

Robin Schmidt was working on such a thing, it only lacked real-time compiling (the program itself was realtime but you couldn't write code). Wonder if RS-MET and this could somehow be combined so you could code visual modules in JIT then wire it up in realtime.

[Architeuthis]

So, this APE is kinda impractical for me at the moment because the things I need to test is all in RS-MET and my personal libraries. Will APE need to be recompiled to include some of this stuff?

I need multipole filters, node-based envelopes and functions for example.

[mystran]

So, this APE is kinda impractical for me at the moment because the things I need to test is all in RS-MET and my personal libraries. Will APE need to be recompiled to include some of this stuff?

You are asking whether APE will include your personal libraries, because you don't understand them well enough to just port them yourself? Are you serious?

[Music Engineer]

So, this APE is kinda impractical for me at the moment because the things I need to test is all in RS-MET and my personal libraries. Will APE need to be recompiled to include some of this stuff?

I need multipole filters, node-based envelopes and functions for example.

hey elan, check out this:

https://github.com/RobinSchmidt/RS-MET/ ... Filter.hpp

it actually uses a dsp class from my rapt library and works. you may like it - because it produces chaos ...but sure, it can currently use only the core dsp stuff and nothing gui related (which you would certainly need for node-based envelopes) - i wouldn't expect such a thing anyway, because gui stuff tends to be framework'ish code (i.e. code that calls functions, you implement) whereas dsp stuff tends to be toolkit'ish code (i.e. code that provides functions, you can call)

[Mayae]

I need multipole filters, node-based envelopes and functions for example.

APE currently includes pretty much none of that (there are some building blocks for filters, but not so reusable). But probably more importantly, it doesn't function as a synth yet - there's no midi input / output. I will be adding that in next version. Sounds like Robin has you covered for a lot of stuff though! so -;

hey elan, check out this:

<span class="skimlinks-unlinked">https://github.com/RobinSchmidt/RS-MET/ ... .hpp</span>

it actually uses a dsp class from my rapt library and works. ...

Woah, I didn't anticipate someone integrating existing libs so tightly - that's really cool, it all just seems to work?

For sure I should add user header search paths, seems like that would benefit you. Took at quite look at the comments you sprinkled here and there.

I see you're adding a healthy amount of .cpp files, if you're finding compilation times atrocious you can hardcode your stuff into the precompiled library and runtime here:

https://bitbucket.org/Mayae/ape/src/mas ... untime.cpp

Then it will link instead of compiling everytime. Perhaps I should add a better user entry point for that...

[Music Engineer]

Woah, I didn't anticipate someone integrating existing libs so tightly - that's really cool, it all just seems to work?

yes. compiles cleanly (no warnings) and works. i was actually positively surprised because up to then, i did not yet compile my library with clang

For sure I should add user header search paths, seems like that would benefit you. Took at quite look at the comments you sprinkled here and there.

yes, that would be nice.

I see you're adding a healthy amount of .cpp files, if you're finding compilation times atrocious you can hardcode your stuff into the precompiled library and runtime here:

https://bitbucket.org/Mayae/ape/src/mas ... untime.cpp

Then it will link instead of compiling everytime. Perhaps I should add a better user entry point for that...

ok, good to know. but actually, compilation time is fine. couple of seconds. i'm very pleased with all of this

[Architeuthis]

You are asking whether APE will include your personal libraries, because you don't understand them well enough to just port them yourself? Are you serious?

Some of my library depends on the giant library that is RS-MET.

hey elan, check out this:

https://github.com/RobinSchmidt/RS-MET/ ... Filter.hpp

it actually uses a dsp class from my rapt library and works.

Woah, so this rapt_for_ape.cpp has basically everything I need?

Yes, I checked out the filter, very interesting! I would add a DC filter on the output, otherwise it seems to be a useful a flexible chaotic filter for screams and growls. I don't particularly like the sound of the decay knobs, but I'll just leave those at their lowest setting. Keep experimenting!

[Music Engineer]

Some of my library depends on the giant library that is RS-MET.

well, that's the name of the whole repo (and my company) and my library is actually just a part of it and is compartementalized, so you don't need to pull in everything, if you just want the dsp stuff

Woah, so this rapt_for_ape.cpp has basically everything I need?

if you only need some dsp classes from rapt, then yes - this should be all you need. however, due to the templatized nature of this library, some compiler errors may pop only when you instantiate a particular class and i apparently just tried it with one class. if you also need dsp classes from rosic, then i think, i would need to make a similar include file for this. the regular ("juce-module") inlcude files don't work, so this little bit of "glue" has to written. and if you need to pull in code from your own dsp library, you can do the same. it's sometimes a bit of tweaking and trial and error, but if it goes wrong, the compiler error messages are usually helpful enough to guide the way to make it work. i had surprisingly little to tweak to make rapt work in ape - a couple of syntax issues here or there that msc and gcc accept but clang doesn't

Yes, I checked out the filter, very interesting! I would add a DC filter on the output, otherwise it seems to be a useful a flexible chaotic filter for screams and growls. I don't particularly like the sound of the decay knobs, but I'll just leave those at their lowest setting. Keep experimenting!

i just wanted to experiment a little bit with the mode-locking phenomenon that occurs when two (or more) modes interact via a nonlinear feedback. the idea is to derive a spikey feedback signal from the output and use this to sort of "retrigger" the modal filters (i.e. feed in an impulse-like signal) once (or twice) per detected cycle where cycle detection is based on zero crossings...something along those lines...just some ad-hoc ideas

I don't particularly like the sound of the decay knobs, but I'll just leave those at their lowest setting.

edit: i actually just discovered and fixed a bug - i had their scaling wrong by a factor of 10 (how embarrassing ). ...it's all just very raw...be also careful - there's no safeguarding against instability explosions