1
0
Fork
You've already forked jsfx2cpp
0
Transpiler to aid in porting Cockos Reaper JSFX to C++
Python 100%
2021年10月24日 16:16:40 +02:00
jsfx-samples generate access specifiers 2021年05月16日 20:46:16 +02:00
generator.py generate access specifiers 2021年05月16日 20:46:16 +02:00
jsfx2cpp.py Don't add "this" to function variables names. 2021年04月23日 19:02:47 +02:00
jsfx_default_library_functions.json add invsqrt 2021年05月03日 15:23:29 +02:00
jsfx_special_variables.json initial Github dump 2021年02月02日 16:19:19 +01:00
lexer.py handle empty oneline comments 2021年05月01日 19:33:20 +02:00
LICENSE Initial commit 2021年02月02日 16:12:29 +01:00
parser.py parser: allow space separated function parameters 2021年05月02日 21:30:55 +02:00
parser.py.manualgen initial Github dump 2021年02月02日 16:19:19 +01:00
parser_vanilla.py initial Github dump 2021年02月02日 16:19:19 +01:00
preprocessor.py Fix broken imports 2021年03月25日 10:19:27 +01:00
README.md update readme 2021年10月24日 16:16:40 +02:00
requirements.txt initial Github dump 2021年02月02日 16:19:19 +01:00

An aid in manually converting Reaper's JSFX (interpreted code)to C++.

TL; DR

./jsfx2cpp.py -f jsfx-samples/real-jsfx | clang-format --style LLVM

It generates a class of almost valid C++ code that is intended to be used as a starting point when manually porting JSFX DSP code (Cockos's Reaper JIT DSP language derived from EEL2) to C++.

The generated code has stubs that have to be implemented afterwards, related e.g. to memory allocation, time/BPM requesting, FFT function calls, etc. It completely ignores the graphics/interface.

The JSFX language is not fully speced, so many features were discovered very late unfortunately, e.g. namespace parameters. Those would require a rewrite which won't happen because in practice very few programs use it.

An example of class generated with this program: https://github.com/RafaGago/artv-audio/blob/master/src/artv-common/dsp/chokehold/gate_expander.hpp

The codebase has Proof of concept code quality. It could use some refactors here and there:

  • No unit testing.
  • Total disregard for speed/efficiency. Favoring simplicity.
  • Not a lot of documentation etc..
  • Coding on a big single file.
  • The error output is rudimentary

Deliberate known issues/omissions:

  • "this.." not implemented, just "this.". I have not seen a single script used.
  • strings. Those are mostly used on the GUI part, this project only is concerned with the DSP.

Non-deliberate known issues/omissions:

  • Only single function namespaces. E.g. fn(namespace*). The current implementation is based on substituting by "this" and namespace calls when possible. This JSFX features was found very late on the development cycle after successfully parsing many non-trivial JSFX scripts. It is a non documented a seldomly used feature.

  • Another feature I found very late. On JSFX calling a function with less parameters than the function expects succeeds by defaulting missing parameters to 0. I didn't even bother checking parameter counts as I was assuming that correct JSFX code would never do that. Just add explicit 0's for missing parameterson the generated code.

  • Comments are a bit flaky. If some file doesn't work because of the comments just temporarily remove them. PLY uses regexes for lexing, which doesn't play well. This could just be fixed by doing it on the preprocessing stage. At some point it could be interesting for the source's comments to make it to the generated code.

If I were to write this again I would probably use a statically typed language. It is good as a POC but I consider risky for my taste to keep growing this project in Python.

Note for me on the future, this is a good project to rewrite in Go or Nim.