Reference External C++ Node as Audio Sample script - is it possible?
-
Just as the title says, is it possible to reference or copy the buffer from my C++ node (similar to the Audio Loop Player for example)?
-
@Christoph-Hart do you know if this is possible with the current C++ template?
-
@HISEnberg sure, just set
static constexpr int NumAudioFiles=0to1. -
Can you push to that buffer from inside the c++ node though?
I think @HISEnberg is wanting to generate an audio file in c++, then push it out to the Hise script?
I might be wrong.
-
@griffinboy ah ok, I think you can use a global cable's data callback for that. The buffer will be copied though so it's not the fastest way (and definitely not realtime compatible).
-
yeah that was my thinking.
But I'm not certain whether that's the case @HISEnberg was asking about or not! -
@griffinboy Yup this is exactly what I am aiming for.
I more or less assumed it would not be real-time compatible. My goal is to have this functioning with a custom built Ring-Buffer but I'm still hazy about how I could possibly render/copy a buffer.
I'll attempt dealing with the rendering time afterwards (my buffer can currently go up to 60 seconds which, at higher sampling rates, could be a huge amount of data to render). I'll start small and try the global cable's first and report back shortly!
-
@HISEnberg what's the high level concept that you're trying to implement? Maybe there's another route.
-
@Christoph-Hart Essentially we are working towards a live audio-looper with overdubbing. Enso by Audio Damage is the inspiration behind it.
The idea is that once the user is happy with their loop they can render it to an audio file and drag it into a DAW (just .wav file format to start). This is where I imagine inheriting for the AudioSampleProcessor (and AudioFile API) can come in handy, though I am not sure how to make that "jump" happen since it is expecting a pre-rendered/non-changing audio buffer.
Personally I don't see the big fuss since a user can just record the output in their DAW but this is the requested feature. For that reason I don't think real-time compatibility is completely necessary--I just need a way to access the buffer and/or render it to disk (i.e. pause audio processing and export the buffer).
The other consideration is this is part of a modular/dynamic FX system, so it will be possible to move the looper around. That means I need to set up a way of storing the buffer and copying it over to it's new location (but this is long term, I may just end up clearing it and initiating a new instance of the looper).
Your Global cable idea is interesting but now I am wondering what the overhead will be since the buffer is continuously recording and overwriting, I'd also need to make sure the data transmitted over the cable is aware when the buffer is full and overwriting. I also see a lot of concerns with 60-seconds of stereo buffers at something like 96kHz being well over 10MB of data....
I'll start simple with
static constexpr int NumAudioFiles=1. If I follow this will give me access to theMultiChannelAudioBuffer, which stores the full audio data (not just the visual representation)? From there I could access it from HISEScript and use methods liketoBase64String()for serialization and direct file export? I'm just glossing over the HISE source code so correct me where I am going wrong! -
@HISEnberg what's wrong with the recorder node?
-
@Christoph-Hart I'll try it again but last time I tried it failed to compile. The recorder node is more or less what I am after though. There's a number of features my node possesses that aren't featured here like playback speed, reversing, etc. But I should study this node and see if I can't replicate it.
