Ideas for prototyping equations for ByteBeat

Development
1

Hello everyone!

I posted a long time ago about building a bytebeat equation player. Recently I got the basics working. I’ve been able to port 5 or 6 equations into VCV Rack and they work great. In order to make this happen, I had to create a few “safe” math functions for things like division to avoid exceptions. For example, my division function looks like this:


  uint32_t div(uint32_t a, uint32_t b)
  {
    if(b == 0) return(0);
    return(a / b);
  }

Nice and simple. The problem is that not all of my equations are porting over gracefully. It might be a difference in order of precedence. Or perhaps the app I used to explore the equations in the first place treats a few things differently.

Here’s my question: Does anyone have any clever ideas for testing equations in my module without having to:

  1. Modify an equation. A lot of time this is guess work.
  2. Recompile the module
  3. Start VCV Rack
  4. Repeat step #1.

When I first worked on these equations, it was a live-coding style environment which left me a lot of room to explore ideas.

I already tried using an equation parser / calculator in conjunction with a text input. I was so hopeful that this would work. But there were two issues: 1) It was super CPU intensive and 2) The output wasn’t the same output that I got when using compiled equations, so I couldn’t really use it for exploring equations.

Any ideas?

2

It’s a darned good question. I unit test all my code outside of the plugin, but it’s native c++ code. Don’t know how that applies to what you want to to do. But it only takes me about 10 seconds to update my unit test app and test again. Don’t know how that applies to your issues, but there are details here if any of this helps: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/unit-test.md

1 Like
3

I find very strange that parsing a simple grammar could be so cpu intensive. Maybe you are reparsing the string every process tick, instead of doing it only on text change?

Another option would be writing a much simple parser, for example for a minimal stack based language. This article describes the basics of stack based/concatenative languages

EDIT: ok seeing the github project you linked it seems that the only way to get answer is re-evaluating the string each time. This is extremely inefficient; if you still want a c-like grammar, you need something more like a compiler, that given a string returns an AST, and at the desired rate (f.e. 8kHz) you evaluate the AST with an enviroment (the t variable in the bytebeat language). I still think that a simpler language (a forth or a lisp) could be a solution.

1 Like