Need some way to line up two wav's visually

[HerrFornit]

It's getting a professional sample player! wow.

perhaps some bugs:
-Raising rate +50 and lowering -50 resulted in lower pitch than the original
-Raising the tempo and then lowering resulted in an interesting echo
-crashed wile lowering the pitch, after first raising the pitch, I did permanently play the sample.

AB crash.jpg (71.01 KiB) Viewed 15633 times

[wde]

-Raising rate +50 and lowering -50 resulted in lower pitch than the original

The number is percent so that's correct.

-Raising the tempo and then lowering resulted in an interesting echo

You get best results using smallish values. Big values produce cool effects

-crashed wile lowering the pitch, after first raising the pitch, I did permanently play the sample.
AB crash.jpg

Fixed.

Edit: Fixes.

[Klangkulisse]

Fantastic work. I like it a lot. Thank you for doing this!

[Candle]

It's so good to see machines being continually developed Thanks for all this work WDE!

See You In The Shadows…

[wde]

1.0.4.0

• More parameters to SoundTouch effects
• Apply effect, undo/redo crash fix

[wde]

1.0.4.2

• Small GUI improvements
• Buzz theme applied to dialog window

[HerrFornit]

the tooltip disappear too quickly for my tired eyes . Please let them be displayed til mouse is moved away. Thanx.

[rav]

I think, that you have attached the wrong revision - older one ;p

[wde]

the tooltip disappear too quickly for my tired eyes . Please let them be displayed til mouse is moved away. Thanx.

New version gives you 60 seconds to read the text

I think, that you have attached the wrong revision - older one ;p

Ok, uploaded again.

[HerrFornit]

Ahhh, thanx.

[River Cricket]

I'm beginning to notice a few issues with playback of longer files.

1. .WAV file playbacks are giving me clicks and pops, as if my CPU is heavily taxed. Windows Task Manager doesn't show any particularly heavy load, and the Buzz CPU monitor has AudioBlock at about 3.0% CPU, but the clicks are definitely there. Here is an upload of a file "before" and "after" being loaded into a fresh Buzz project consisting of nothing except AudioBlock going straight to master. I clicked "record loop" so (theoretically) the new file should begin exactly as Buzz starts playback.

I'll warn you that it's subtle and may not be noticable on speakers - I recommend headphones, with the volume all the way up (I promise there's no loud noises ). It sounds like vinyl surface noise - the incidental little clicks and pops on a generally-well-taken-care-of record. I also get the same "surface noise" when rendering loop instead of recording loop.

2. The files also "fail" an "inversion test" - inverting one of them, then mixing them together should, in theory, produce silence or near-silence, but here there's plenty of ghosting. This is less of a concern, I suppose, because you (or at least I) can't really hear a difference, and it may be unavoidable due to the very nature of Buzz WAV capture itself. But thought I'd mention it anyway.

3. mp3 playback seems... really problematic. Maybe it's due to sample rate conversion (mp3 can only be at 44.1 or 48k, and I run Buzz at 96k)? I tried both 320 CBR and V2, 44.1 and 48K (48k should in theory convert to 96k pretty easily), and they all sounded pretty terrible - 320 has the aliasing of an old-school Real Audio file, and V2 does all sorts of wacky things, you can hear when the encoder is switching bitrates and stuff. VBR might be a bit "modern" for Buzz, but it seems a 320 CBR file should be well within spec. The files play fine in foobar.

The source file in question is about 4:31 long (the versions in the zip file I linked are just the beginning), so that may be the root cause of my issue here Polac VST blows Audacity's crummy VST handling completely out of the water, so it'd be really cool to be able to use Buzz for second-pass mastering, or when doing "bounce-downs" when CPU starts maxing out.

[wde]

1. Haven't noticed this. You could try different audio driver buffer sizes since there is some locking going on in AudioBlock to avoid thread collision.

2. I tried inversion test using 44.1KHz FLAC file and setting audio interface to 44.1kHz. Result is pure silence as expected. If your audio file sample rate differs from Buzz sample rate, you will get aliasing effect. To avoid/minimize this, you can resample the audio file from the right click menu.

3. AudioBlock uses the mp3 decoder in Buzz and I don't know what framework/library Buzz uses for mp3 decoding. The aliasing problem applies here as well. And to get the best output lossless audio format is the way to go.

[wde]

1.0.5.1

• Resize audio wave
• Spectrogram

[IXix]

1.0.5.1

• Resize audio wave
• Spectrogram

Nice!

[River Cricket]

1. Haven't noticed this. You could try different audio driver buffer sizes since there is some locking going on in AudioBlock to avoid thread collision.

2. I tried inversion test using 44.1KHz FLAC file and setting audio interface to 44.1kHz. Result is pure silence as expected. If your audio file sample rate differs from Buzz sample rate, you will get aliasing effect. To avoid/minimize this, you can resample the audio file from the right click menu.

3. AudioBlock uses the mp3 decoder in Buzz and I don't know what framework/library Buzz uses for mp3 decoding. The aliasing problem applies here as well. And to get the best output lossless audio format is the way to go.

A belated thank-you for this reply! Didn't know about the right-click resample - SUPER handy!

Is it normal for Audioblock to use a lot of CPU when rendering audio? I've been seeing CPU Monitor report up to 70%, but only during render - live record is fine. Made my last project super-difficult, had to learn to live with some glitched-out audio. I've played around with buffer sizes (and buffer counts) and haven't noticed any change. Using Polac ASIO at 96khz, 32 bit Buzz, Windows 7.

[wde]

Is it normal for Audioblock to use a lot of CPU when rendering audio? I've been seeing CPU Monitor report up to 70%, but only during render - live record is fine.

I think 'Render Loop' renders the audio output as fast as possible and thus uses more CPU. I usually use 'Record Loop' because of some misbehaving vst.

Made my last project super-difficult, had to learn to live with some glitched-out audio. I've played around with buffer sizes (and buffer counts) and haven't noticed any change. Using Polac ASIO at 96khz, 32 bit Buzz, Windows 7.

Might be related to the audio interface you are using. I have Focusrite Scarlett and it seems that I can use a little bit lower output latency with WASAPI driver vs ASIO (both handle well 3-4 ms latency). Can you try WASAPI?

New version with source. Small fixes and improvements.

[IXix]

CPU Monitor report up to 70%, but only during render - live record is fine. Made my last project super-difficult, had to learn to live with some glitched-out audio.

I had the same trouble with bad glitches in renders, never in live output but audioblock didn't exist then. I found that dropping from 32bit float to 24bit int got rid of them. I was on a very old 32bit Win7, using WASAPI and the CPU was struggling. I should probably do some tests to see it it's still an issue on my new system.

@wde thanks for the new version!

[River Cricket]

Is it normal for Audioblock to use a lot of CPU when rendering audio? I've been seeing CPU Monitor report up to 70%, but only during render - live record is fine.

I think 'Render Loop' renders the audio output as fast as possible and thus uses more CPU. I usually use 'Record Loop' because of some misbehaving vst.

I always assumed that "Render" would allow slowing down the render if various machines are getting CPU-hungry - so, for instance, if there's a segment that uses 200% CPU, Render would take twice as long as Record, but result in cleaner audio. My very, very informal testing seemed to back this up in non-Audioblock-related instances - certain segments that would nearly always glitch out when playing would end up fine in the file itself. But I'm not deeply in touch with the Buzz engine, much as I would love to be , so if it really is just a simple "as fast as possible" racecar option I guess that would explain things.

That said, in this particular project, I have some VSTs peaking at 40% CPU that really snap-crackle-pop on playback, but on render their associated chains are fine, it's only the Audioblock samples that end up glitched.

Made my last project super-difficult, had to learn to live with some glitched-out audio. I've played around with buffer sizes (and buffer counts) and haven't noticed any change. Using Polac ASIO at 96khz, 32 bit Buzz, Windows 7.

Might be related to the audio interface you are using. I have Focusrite Scarlett and it seems that I can use a little bit lower output latency with WASAPI driver vs ASIO (both handle well 3-4 ms latency). Can you try WASAPI?

I'm on a Behringer UMC404.

I'd be happy to try in the interests of bug-checking, but unfortunately there isn't a Polac WASAPI option, and I frequently use Polac Audio In with projects - as far as I know there's still no better option for audio input, no?

[after several renders]

...WASAPI in this instance seems "better", but still not perfect - some definite static that isn't in the original files. I tried recording at both 16 and 24 bit, with similar results both times.

CPU Monitor report up to 70%, but only during render - live record is fine. Made my last project super-difficult, had to learn to live with some glitched-out audio.

I had the same trouble with bad glitches in renders, never in live output but audioblock didn't exist then. I found that dropping from 32bit float to 24bit int got rid of them. I was on a very old 32bit Win7, using WASAPI and the CPU was struggling. I should probably do some tests to see it it's still an issue on my new system.

Weird! I guess it's understandable given the hardware, though. Anyway, it was thanks to your comment that I experimented with switching the bitrate, though it didn't seem to make much difference in my case.

[wde]

1.0.6.3:

• Power user option: auto-resample. Right click 'Wavetable Audio' label. Resamples audio to Buzz sample rate if audio selected from AudioBlock UI or dragged to AudioBlock UI.
• Flac, Ogg etc. should work now with drag&drop.

I was wondering if it'd be possible to add support for .ogg and .flac files? Or is this a Buzz-level limitation?

Buzz actually has a method called 'LoadWaveEx' that does all the magic. Somehow missed this earlier.

[IXix]

• Power user option: auto-resample. Right click 'Wavetable Audio' label. Resamples audio to Buzz sample rate if audio selected from AudioBlock UI or dragged to AudioBlock UI.
• Flac, Ogg etc. should work now with drag&drop.