Multi-channel Buffer Processing with pluginBase.cpp | Algorithm Design | Forum

Avatar

Please consider registering
guest

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —




— Match —





— Forum Options —





Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
Multi-channel Buffer Processing with pluginBase.cpp
Avatar
New Member
Members
June 15, 2020 - 6:41 am
Member Since: June 15, 2020
Forum Posts: 1
sp_UserOfflineSmall Offline

So, I found a way to modify code in pluginBase.cpp to perform buffer processing instead of frameProcessing in pluginCore.cpp using ASPiK.
But my question is, is it possible to do buffer processing with a static/weird buffer size like 192 while the processBufferInfo.numFramesToProcess could be either higher or lower than it?

Thanks.Confused

Avatar
Admin
June 19, 2020 - 11:04 am
Member Since: January 29, 2017
Forum Posts: 689
sp_UserOfflineSmall Offline

To do buffer processing, I recommend overriding processAudioBuffers( ) in the PluginCore; the PluginBase file could potentially change in the future (and it will need to, in a minor way, for the new Synth Book I am writing). 

If you look in the PluginCore.h file, you will see that this function is prototyped, but it is commented out. Uncomment it, and then implement it in the .cpp file (using the base version as a template). If you do this, then the pluginbase version will never be called, and you will be immune to future changes to the base SDK files. 

My new Synth Book and synth plugins all do block processing by default as it is much more efficient in the Synth paradigm (it is for FX as well, but not as noticeable). 

For my block processing version, I break the incoming buffer into blocks that are sized for the plugin. If a block comes in that is smaller than I need, or I have a partial or "incomplete" buffer, I go ahead and process the smaller block as it only happens sporadically, and is not in my control - the host DAW controls that.

If your plugin requires a certain block size, which is not uncommon for FFT based code where you absolutely must process exact sizes, then you need to do more work to deal with partial or incomplete buffers, and you need to "sew them together" across the processAudioBuffer( ) calls, so that you are always delivering an exact size to your processing objects. Of course, this can be tricky because you need to declare a temporary but persistent array (buffer) to store incomplete blocks. 

In addition, you will need the temporary storage buffers for every channel your plugin processes. The block processing and temporary buffer issues have been around forever so you will probably find code that you can adapt.

Will 

Avatar
Member
Members
June 16, 2021 - 8:19 pm
Member Since: June 16, 2021
Forum Posts: 43
sp_UserOfflineSmall Offline

W Pirkle said
...My new Synth Book and synth plugins all do block processing by default as it is much more efficient in the Synth paradigm (it is for FX as well, but not as noticeable). 

If your plugin requires a certain block size, which is not uncommon for FFT based code where you absolutely must process exact sizes, then you need to do more work to deal with partial or incomplete buffers, and you need to "sew them together" across the processAudioBuffer( ) calls, so that you are always delivering an exact size to your processing objects. Of course, this can be tricky because you need to declare a temporary but persistent array (buffer) to store incomplete blocks...

Hi will. Dunno if you'll read this or not, seeing as it's been a little while now. But by chance, would your book detail how to do this creation, storing, and sewing together of blocks? 🙂 Been looking through the code examples and reading the book trying to figure out how this is done. Haven't found anything yet.

Avatar
Admin
June 17, 2021 - 8:29 am
Member Since: January 29, 2017
Forum Posts: 689
sp_UserOfflineSmall Offline

Over the last 12 years, I've published 4 books, given away tons of free software, developed a license free open source plugin framework, numerous app notes, and free code examples.

Alas, I do not give it all away, and this is one thing that I do not publish, the other main thing is multi-threaded file parsing for reading samples and wavetables from data bricks at run time for synths. 

However, I am sure that someone else here on the Forum has already developed this and may be happy to share it with you. And I would guess that someone on the KVR and/or JUCE forum has already developed it as well so you might want to ask around those forums. 

But, I would suggest figuring it out yourself as it makes a great exercise in understanding an interesting type of double-buffering -- you will need a temporary storage buffer (or two, depending on implementation). 

Today (June 17, 2021) the 2nd edition Synth Book is shipping and I've just uploaded all of the free open-source SDK and compiled projects, developed over the last 5 years of teaching at the university level. These synths use block processing for the audio rendering operation with an interface that accepts audio sub-blocks (64 samples in size is the default, but you may easily adjust that). I setup the SynthLab SDK to allow partial buffer processing without the need for sewing together blocks because nothing is dependent on the 64-sample block size for operation. 

Will 

Avatar
Member
Members
June 17, 2021 - 8:23 pm
Member Since: June 16, 2021
Forum Posts: 43
sp_UserOfflineSmall Offline

W Pirkle said
Over the last 12 years, I've published 4 books, given away tons of free software, developed a license free open source plugin framework, numerous app notes, and free code examples.

Alas, I do not give it all away, and this is one thing that I do not publish, the other main thing is multi-threaded file parsing for reading samples and wavetables from data bricks at run time for synths. . .
   

Apologies if I came off sounding a bit greedy just then. 🙂 (I probably am. 😛 ) I'm more confused than anything. I'm rather green at programming as well as the more theoretical aspects of digital signal processing and all the maths behind it. So honestly, from where I'm sitting, your contribution is really quite astonishing. I honestly can't believe this information exists, and that you're giving away the code in . . . well, gee, all these SDK's! 🙂 (and it's got comments that make sense! Yay! ) You're one of a few authors on this topic that I can actually understand. 🙂

I was gifted the second edition effects book, and I've been enjoying the heck out of it. 🙂 It meets me where I'm at, and even provides a really lean, super permissive framework to jump off from! (JUCE was like adding a whole other language on top of C++; so as a complete novice, your framework is the easiest one to comprehend) . . . Really, ASPiK is such a comprehensible little thing, that it has me thinking "you know, I can't do much with c++, but with a bit of head-scratching, I bet I could extend this to work with the API for my DAW's native format too!" (minus the project creator; but Cmake would still work, with fiddling, and I'm reasonably confident VSTGUI won't pose too much of a problem. . . He said, baselessly. 😛 ) 

So really, sorry if that seemed rude. It wasn't my intention. 🙂 (And sorry for rambling/going so far off topic. I know you're busy. )

Avatar
Admin
June 18, 2021 - 10:12 am
Member Since: January 29, 2017
Forum Posts: 689
sp_UserOfflineSmall Offline

It's not a problem, nothing to fret about. 

I had many issues with the original RackAFX6, which came from a consulting project I was working on around 2004, that involved an embedded DSP chip. When I started teaching, I molded it into a lightweight framework thinking that this would help students who were interested in signal processing - a simple API to start, and then when they got their first job, they would use more complicated tools. There was no real GUI, just the prototyping panel (because there was no. GUI needed for the DSP chip). I had never heard of JUCE until one of my students mentioned it around 2013 or so. I made the mistake of not correcting the original RAFX problems, and then another big mistake of saying YES to my publisher for the 1st edition synth book. After that behemoth was published, I decided to start fresh, and throw all of the old RackAFX stuff out, and developed ASPiK very slowly, over several summers, in parallel with RackAFX7, but intentionally disconnected and not dependent on it.

And, now I use it and RackAFX/ASPiK all the time, developing algorithms that are in commercial products (and many, many more to come). 

So my problem is that it is hard for me to say "no" and I've been trying to work on that. And, I did not mean to come off like an asshole. 

The last vacation I've had since going back to teaching was in 2007, a surfing trip to Costa Rica (I used to go twice a year, every year).

Now that the 2nd edition synth book is out, and the old 1st editions can be destroyed in a giant bonfire, maybe it is time for me to go back to the waves - the watery kind.

WP

Forum Timezone: America/New_York

Most Users Ever Online: 152

Currently Online:
9 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Chaes: 56

Skyler: 48

StevieD: 46

Derek: 46

Frodson: 45

Peter: 43

TheSmile: 43

Nickolai: 43

clau_ste: 39

jeanlecode: 37

Member Stats:

Guest Posters: 1

Members: 768

Moderators: 1

Admins: 6

Forum Stats:

Groups: 13

Forums: 42

Topics: 842

Posts: 3347

Moderators: W Pirkle: 689