Login / Register  0 items | $0.00 New What is KVR? Submit News Advertise
keithwood
KVRist
 
40 posts since 24 Dec, 2015

Postby keithwood; Fri Feb 10, 2017 2:31 am Re: Dealing with variable buffer sizes in VS...

Thanks @Miles1981, I didn't know about that one. I'll have to see if it works with std::vector, Microsoft's documentation is as unhelpful as ever at explaining the details!
User avatar
#rob
KVRist
 
321 posts since 20 Aug, 2013

Postby #rob; Fri Feb 10, 2017 3:09 am Re: Dealing with variable buffer sizes in VS...

Kwestshun... but if you're using JUCE anyway, why not use JUCE methods?

Code: Select all
AudioSampleBuffer aBuffer;
aBuffer.makeCopyOf(buffer);

This will make aBuffer an identical mirror copy of buffer, same number of channels, same length, same content, everything.

getReadPointer(0) and getWritePointer(0) will only deal with the first channel, not with all of them. If you really only want to buffer a single channel 0, then you could also do it like this:

Code: Select all
AudioSampleBuffer aBuffer;
aBuffer.setSize(1,numSamples);    // 1 = 1 channel
aBuffer.copyFrom(0,0,buffer,numSamples);    // 0 = channel 0, 0 = start at sample 0


Btw, from my personal experience it will probably make your code slightly more performant (and a lot more readable) if you push for-loops into external functions. So don't have one huge "for all channels" -> "for all samples" construct in the processBlock() and call per-sample functions on each sample, but instead create functions that take an entire sample block (or buffer) as an argument and then do their own individual For-all-channels -> For-all-samples loops internally. In those functions, you can get the numChannels and numSamples from the referenced AudioSampleBuffer itself, so they'll never run out of range.

If you're always going to use the same 3 buffers to copy stuff into in processBlock(), it may also be an improvement to instantiate them globally in your .h file, not on-the-fly in processBlock(). Reusing already assigned memory chunks should be faster than constantly releasing old memory chunks and reassigning new ones. Even if it moves their scope from processBlock() to global.

(I hope I understood correctly what it is you're trying to do...)
Cheers,
Rob
u-he | Support | FAQ | Patch Library
Miles1981
KVRian
 
1146 posts since 26 Apr, 2004, from UK

Postby Miles1981; Fri Feb 10, 2017 3:50 am Re: Dealing with variable buffer sizes in VS...

keithwood wrote:Thanks @Miles1981, I didn't know about that one. I'll have to see if it works with std::vector, Microsoft's documentation is as unhelpful as ever at explaining the details!

It should, the debug iterator page indicates that it works for vector::operator[] ;)
keithwood
KVRist
 
40 posts since 24 Dec, 2015

Postby keithwood; Fri Mar 17, 2017 2:21 am Re: Dealing with variable buffer sizes in VS...

Thought I'd just add to this after doing some playing about:

I've found a limitation in Visual Studio where you can't change the _ITERATOR_DEBUG_LEVEL if you use facets (<locale>). That's the bad news (for me).

The good news is debugging seems to be a lot quicker in Visual Studio 2017 (surprisingly fast) so needing to change _ITERATOR_DEBUG_LEVEL becomes a non-issue.
User avatar
nonnaci
KVRist
 
125 posts since 7 Feb, 2017

Postby nonnaci; Fri Mar 17, 2017 1:51 pm Re: Dealing with variable buffer sizes in VS...

keithwood wrote:Thought I'd just add to this after doing some playing about:

I've found a limitation in Visual Studio where you can't change the _ITERATOR_DEBUG_LEVEL if you use facets (<locale>). That's the bad news (for me).

The good news is debugging seems to be a lot quicker in Visual Studio 2017 (surprisingly fast) so needing to change _ITERATOR_DEBUG_LEVEL becomes a non-issue.


How's VS2017 treating you? For performance reasons, there's always a time during development under VS2015 where I must make a switch to the release config. Are the debug builds in 2017 much faster?
keithwood
KVRist
 
40 posts since 24 Dec, 2015

Postby keithwood; Sat Mar 18, 2017 4:35 am Re: Dealing with variable buffer sizes in VS...

nonnaci wrote:How's VS2017 treating you? For performance reasons, there's always a time during development under VS2015 where I must make a switch to the release config. Are the debug builds in 2017 much faster?


After spending more time with VS 2017, it's mixed. I have two main builds I'm testing my plugin with, a windows application where I'm just testing the GUI and then the full plugin where I'm testing the audio.

The GUI code seems to be faster in debug than it previously was. I'm using DirectX and so am heavily reliant on variable length buffers in which I'm gathering/sorting vertices for polygon and sprite batching (hence my initial interest in this thread). So it might not make a huge difference to the GUI debugging experience of other projects depending on their workloads.

The audio code hasn't seen any benefit in debug mode. I'm heavily exploiting expression templates to automatically vectorize code for my dsp algorithms and it's still really slow in debug.

Linking is faster. I'm using various compilation firewall techniques to reduce build times down to a few seconds (there's around 85,000 lines of code across 1,000 source files in 20 projects) and so link times for me were a bottle neck. When I code, I tend to make a small change, compile and run. That cycle is definitely quicker (between 2 and 10 seconds to build and launch for me now depending on the change which is about 25% faster).

The msvc compiler has a few breaking changes. One of the source files that I wrote early on in my project had some dodgy template meta programming which I had to fix, but I'm pretty comfortable with that stuff now so it wasn't a problem and I suspect clang wouldn't have liked it either, I'm glad it made me change it! I'm heavily reliant on C++ 14 and keen to starting using more of the C++ 17 features.

The clang integration for Visual Studio 2017 worked perfectly, didn't need to reinstall anything. Intel performance primitives don't yet integrate (I even tried re-applying the latest update) so I had to manually add header and library includes.

All the projects needed re-targeting manually to the latest Windows SDK (I uninstalled VS 2015 first) even though VS told me it had done it for me.

It took about 2 hours to have everything up and running (including the code fix I mentioned). It was relatively painless.

The intelli-sense and refactoring (mainly renaming) seems quicker. Project loads a bit quicker.

I've not examined the generated assembly in release mode to see if it's better. I'm using msvc for all debug builds, but I'm using clang to build some of the code in release as that compiler seems to give me better results for dsp/scientific code (better inline decisions, better optimisation of expression template generated intrinsics).

On balance there are a few upsides and no downsides for my project.
mystran
KVRAF
 
4478 posts since 11 Feb, 2006, from Helsinki, Finland

Postby mystran; Sat Mar 18, 2017 7:15 am Re: Dealing with variable buffer sizes in VS...

With "old" MSVC you could make debug builds faster without hurting your ability to debug, simply by disable some of the additional "safety" features. If I remember correctly, the stack guards in particular would have crazy overhead for code that uses a lot of small functions (eg. template stuff) that are designed to be inlined for release builds. Haven't tried MSVC2017 so no idea if this still applies, but play with the debug code-gen settings and you might be able to make things a lot faster without having to enable actual optimisations.

That said, I find it really funny (in a sad way) how terribly the MSVC debugger handles optimised code most of the time. With Clang and LLDB you can still get sensible data for most of your variables, the case where the debugger can't figure out something seems more like an exception rather than a rule. With MSVC it's always been the other way. :P

edit: haven't used GCC in a while, but the GCC+GDB combo used to be way better than MSVC with optimised code as well.
Image <- plugins | forum
Previous

Moderator: Moderators (Main)

Return to DSP and Plug-in Development