Audio Programming Environment 0.3 - x32/x64 on win + mac (vst/au)!

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

camsr wrote:Actually, I was hasteful with that post, it's working but the first two channels are going in and out on the other channels also, like the buffers are duplicated.
1. Does this happen when there's no active plugin in APE - ie. the sound passes through normally?

2. So the first two channels outputs to out: ([0, 1], [2, 3], [4, 5], [6,7])? But for example, channels [2,3] outputs correctly only to out: [2,3]?

Post

Yes, it happens when there's no active plugin. 1-2 go to all 8 channels like so:
1-3 1-5 1-7
2-4 2-6 2-8

When routed like this (default FL routing for plugin on mixer track)
Image

When routed like so, working normally
Image

Then output is summed on 1-2 from all channels, quadruple gain :)

I think it's just my fault, but then again it did it when there was no plugin also.

Post

I just tested it out in both FL and ableton and i understand your confusion, because FL seems to clone all inputs and merge them all at output stage if nothing else is defined --

Case in point, here's a small arrangement in ableton that works as expected with the exact same plugin (no manual mapping needed):
Image
Whats going in this picture is basically..
The acid bass in the track 1 ("1 acid bass") is sending to [1,2] into ape. [1, 2] passes through to the master, but not the other channels. Meanwhile, track 4 ("4 audio") is sending audio into track in in channels [5, 6] which correctly registers in ape, however since [5, 6] is not mapped for track 1, it will not continue to the master. Also, APE is generating a sine tone on channel 4 which track 3 ("3 audio") is receiving correctly. Track 3 maps APE's [3,4] to track 3's [1,2] which is sent to the master and therefore the sine tone is output as well on right channel.

Ehh, a bit complicated and confusing, but all in all i would say it's expected behaviour, only FL's standard routing is different from what you would expect. I was able to produce the same results in FL after manually routing the inputs correctly.

As for donating, yes you're very welcome to support me :) As per page 24 in the manual, donations can be attributed to the following paypal:
dyanuzz@hotmail.com

Post

It has to be FL's problem, does it in another plugin also. Any multi-channel inputs will default to using the 1-2 input signal until it's defined in the wrapper.

Post

Hi!
Any news on this great stuff?

:D

a.

Post

Hello!

I've been pretty busy with studies, and another project I'm working on, however I've always been keen on getting further with this project. At the moment it just does what I wanted it to do, so it's really up to you to suggest any further improvements - I'm very interested in new feature ideas or directions for this.

Currently it really needs getting the syswrap working on OS X, but in the meantime I've been developing the library for APE further so it needs rewriting, which I'll be doing over the summer. I'm still doing most of my modeling in this program, so I have an updated set of scripts that may be interesting for the world, perhaps the best direction is a public repository.

Post

Ability to interface to any compiler installed on the computer, write in any language you want!
Wonder if there's any feasibility in this being able to also compile different languages to C++, so that one could write the plug-in e.g. in Python and then have the program translate it to equivalent C++ (or anything that's compilable to a VST).

It might be reasonably out of scope of this though, if this is meant to be used more as a "prototyping" tool.

Post

First one would require a source to source compiler for Python to C++ or even C. This does not exist yet (so even less with the scientific modules).

Post

Miles1981 wrote:First one would require a source to source compiler for Python to C++ or even C. This does not exist yet (so even less with the scientific modules).
Isn't it technically feasible to do something similar to what's done with Bytecode in the JVM? That all languages that have the common Bytecode can be translated to the Bytecode and the same computations thus expressed.

Post

.Net has even a better way of doing this, but they all rely of a VM.

But even Python can't use Numpy for instance, you could use LLVM to have a JIT for Python (based on PyPy), but you will still lack the modules that were not built for the proper back end.

Post

I have an idea for the extension of APE.

Make it have a Reaktor/SynthEdit like "patcher" mode and a way to share "APE patches" in the same way.

If this is not yet possible.
Last edited by soundmodel on Mon Jan 25, 2016 10:38 pm, edited 1 time in total.

Post

Have you thought about switching from GPL?

If it's JUCE causing the GPL, then I might suggest switching to WDL-OL.

Post

Fluky wrote:I have an idea for the extension of APE.

Make it have a Reaktor/SynthEdit like "patcher" mode and a way to share "APE patches" in the same way.

It this is not yet possible.
Yes, I have thought of something similar (it's a great idea, I often find myself writing boilerplate filters etc. in APE, which is counter-intuitive), I just wanna avoid reinventing the wheel. I'm still working on something else currently, so this project is still paused for the moment
Fluky wrote:Have you thought about switching from GPL?

If it's JUCE causing the GPL, then I might suggest switching to WDL-OL.
I originally wrote it for vst2.4/VSTGUI, from which it still remains generally compatible with. Also, I don't really have a reason for avoiding GPL, if anyone chips in; all the better. Juce just made some things easier - didn't want to spend time setting platform differences etc. in a noncommercial project, anyway.

Post

Mayae wrote:
Fluky wrote:Have you thought about switching from GPL?

If it's JUCE causing the GPL, then I might suggest switching to WDL-OL.
I originally wrote it for vst2.4/VSTGUI, from which it still remains generally compatible with. Also, I don't really have a reason for avoiding GPL, if anyone chips in; all the better. Juce just made some things easier - didn't want to spend time setting platform differences etc. in a noncommercial project, anyway.
It's just that I'm doing partially commercial development. And the current license prohibits it.

I had a look at BlueCat's Plug'n Script, which is okay, but it costs additional 79€ for any user that would wish to use plug-ins made on it. Reaktor would cost even more. Which is the reason I'm trying to deviate from these commercial offerings. Since their user bases aren't large enough.

It could be reasonable to develop a similar platform that's "half-commercial". In the sense that it wouldn't cost the "full price" of the software for those that merely wish to use plug-ins developed on it, but not the development capabilities. Have a discounted license for those users.

Post

So what, you want to release commercial closed-source scripts, or? It takes two seconds to copy+paste an APE script into a fresh VST/AU project, that can bear any license you want

Post Reply

Return to “DSP and Plugin Development”