Audio Programming Environment 0.3 - x32/x64 on win + mac (vst/au)!
- KVRist
- 168 posts since 19 Apr, 2014 from London
When I was working with APE I created a little Lua script to merge my files.
If you want you can even invoke a C compiler to translate the C++ into plain C so you are in essence making a build specifically for APE, which is a much more sophisticated alternative to my manual concatenation approach.
If you want you can even invoke a C compiler to translate the C++ into plain C so you are in essence making a build specifically for APE, which is a much more sophisticated alternative to my manual concatenation approach.
-
- KVRian
- Topic Starter
- 573 posts since 1 Jan, 2013 from Denmark
I've tinkered with it a bit, and must admit I can't get it working. It doesn't help TCC doesn't give any information output (unless something goes wrong, I guess missing files isn't worth a diagnostic). I've checked that TCC actually recieves the commandline (it does, stuff like -Dsym=8 works). But the source code for TCC is really a huge mess and I kinda gave up when I couldn't even find the definition for tcc_set_options() which is the command line hook, which would be the next investigation step.Fluky wrote:It's included.Mayae wrote:I assume you #include the test file in the ape script, then (post it?). As APE doesn't natively support multiple translation units, you either have to pass the .c file as an additional argument to TCC, or compile it to a object file / shared object / dynamic library, and pass it via the args in the config file.
I tried adding:
to config.cfg under "compiler:" under "c:" under "languages:".Code: Select all
arguments = "-c ctest.c";
Problem persists. I don't even see if it generated a ctest.o file. Not at least into the same folder as the .c.
Maybe the path to ctest.c is wrong?
My guess is that TCC silently ignores (or only considers a subset of) certain command-line switches, when working in library mode.
However, if you wanted to compile the additional file anyway, you can just #include the source file directly in the APE script anyway - you're only dealing with a single translation unit, so you can't get multiple definition errors anyway.
-
- KVRian
- 1091 posts since 28 May, 2010 from Finland
BTW, something about the "product placement" of APE:
It's not that cumbersome to develop in WDL-OL. I don't know about JUCE development, but WDL-OL is really simple (I think it's almost like writing HTML+CSS, even while it's C++, because the library is so reasonable I think). Once it's set up on your computer (the setup is trivial on Windows, but takes some effort on OS X because of missing Xcode support for legacy OSes).
It's so fast that I don't really see much benefit from e.g. having Python bindings. Unless it's for trying out complicated algorithms without messing with even more complicated C++ expression of the algorithm.
APE is great though in the sense that one doesn't need to go through building the plug-in and then running a DAW to test it. Rather one can compile while running the DAW.
But APE misses a lot (perhaps) if it doesn't allow for actual development of plug-ins as well, not just prototyping.
It's not that cumbersome to develop in WDL-OL. I don't know about JUCE development, but WDL-OL is really simple (I think it's almost like writing HTML+CSS, even while it's C++, because the library is so reasonable I think). Once it's set up on your computer (the setup is trivial on Windows, but takes some effort on OS X because of missing Xcode support for legacy OSes).
It's so fast that I don't really see much benefit from e.g. having Python bindings. Unless it's for trying out complicated algorithms without messing with even more complicated C++ expression of the algorithm.
APE is great though in the sense that one doesn't need to go through building the plug-in and then running a DAW to test it. Rather one can compile while running the DAW.
But APE misses a lot (perhaps) if it doesn't allow for actual development of plug-ins as well, not just prototyping.
-
- KVRAF
- 1579 posts since 14 Oct, 2002
-
- KVRian
- Topic Starter
- 573 posts since 1 Jan, 2013 from Denmark
Hi, once I'm done with the next version of Signalizer this is on the top of the list. Many quality-of-life changes to come.lalo wrote:Hi! Any news here?
best!
Otherwise, I mainly just update the repository with examples once in a while:
https://bitbucket.org/Mayae/ape-snippets
-
- KVRAF
- 1579 posts since 14 Oct, 2002
-
- KVRian
- Topic Starter
- 573 posts since 1 Jan, 2013 from Denmark
Hi J1nx,
Bad news is I decided to rewrite pretty much all of it, so it can integrate better with my other pet projects. Good news is I'm almost done Additionally, some fun new features includes:
- Bleeding edge C++ compiler based on clang/llvm
- Built in oscilloscope to probe signal expressions in code
- Parameter automation
- Better (maybe?) UI with dockable components, resizable windows bla bla
- Much simpler, much faster and more expressive scripting system
- Linux support
- KVRian
- 872 posts since 6 Aug, 2005 from England
-
- KVRian
- Topic Starter
- 573 posts since 1 Jan, 2013 from Denmark
Refer to download links here please: http://jthorborg.com/index.html?ipage=ape
Note that this is for the 4-5 year old version.
If anyone is eager to try the new version (Windows only right now), and willing to bleed a little with me just reach out.
-
- KVRAF
- 1579 posts since 14 Oct, 2002
Mayae wrote: ↑Sun Feb 03, 2019 11:45 am Hi J1nx,
Bad news is I decided to rewrite pretty much all of it, so it can integrate better with my other pet projects. Good news is I'm almost done Additionally, some fun new features includes:
- Bleeding edge C++ compiler based on clang/llvm
- Built in oscilloscope to probe signal expressions in code
- Parameter automation
- Better (maybe?) UI with dockable components, resizable windows bla bla
- Much simpler, much faster and more expressive scripting system
- Linux support