Voxglitch modules - beta testers welcome!

[stoermelder (Ben)]

@clone45

Another big issue is CPU usage. In order to get lush sounds, you need to increase the window value. (Window is how long the grain is.) But this causes grains to stay in memory longer, and more grains means more CPU time. One way around this is to decrease the maximum number of grains allowed in memory. However, sometimes you might want more grains, but with a shorter window.

I suppose it is not the time that causes high CPU usage but the number of grains which need to be summed? I haven’t looked at your code yet but using SIMD might really help in this case as it can reduce needed CPU instructions up to factor 4 under ideal conditions.

[OhWell]

@clone45

Incoming audio is constantly streaming through a buffer. Let’s say that a grain spawns every 44 “ticks” (depending on sample rate) and starts playing at position in the buffer.

1. The 1st grain starts at position 44 in the buffer and begins playing at sample rate.
2. 100 ticks later, the 2nd grain starts at position 44 in the buffer and starts playing at sample rate.

Here’s the really mind-bending part: Both samples will be playing at the same position in the sample. In fact, if the playback position in the buffer is not modulated, all the grains will be playing the same exact same spot in the sample, causing the huge spike in volume that you can sometimes hear.

Hmm, I’m most likely missing something, but I thought a common solution is to use a fixed buffer length, pushing audio through and out at the same rate as it’s being added. So that (as far as the granular engine is concerned) each addressable position in the buffer acts like a tape play head. The way you describe it makes it sound like the position 44 works like position on the tape itself (instead of the relative position of playheads.) Could that be that’s what’s going to make it counterintuitive?

[clone45 (Bret Truchan)]

@OhWell

but I thought a common solution is to use a fixed buffer length, pushing audio through and out at the same rate as it’s being added. So that (as far as the granular engine is concerned) each addressable position in the buffer acts like a tape play head

Yes, that’s exactly how I’m implementing it. Sorry if I glossed over that implementation detail. I have a fixed width buffer where the audio gets “pushed though”. Technically, I’m adding the audio then incrementing the write-head, if you will. When the write head reaches the end of the buffer, I wrap it to the beginning. When a new grain is created, it’s passed:

1. The location of the write head, the [grain] Location input value. Is uses this as its starting playback position.
2. The pitch at which to playback. (a simple float value that’s been pre-calculated)
3. The selected amplitude slope. (That’s new and not yet in the repository.)
4. A pointer to the buffer. Memory consumption is not an issue.

However, @stoermelder Ben has a very good point that was troubling me last night as well. After I had posted, I realized that I wasn’t being logical when I talked about grain length affecting CPU. The CPU should be completely dependent on the number of grains. Right now I allow up to… 400 grains. Maybe that’s too many. I’ve tweaked that before, but maybe it’s work revisiting.

Also @stoermelder, that’s an amazing idea! I’ve never tried that before. I have programmed some assembly language in college 30 years ago. Oooo. Getting old. Ha ha. First, maybe I should double check that my code is as efficient as possible. I just spotted some division that could be converted to bit shifting.

Thanks so much for the suggestions!

[OhWell]

@clone45

I have a fixed width buffer where the audio gets “pushed though”. Technically, I’m adding the audio then incrementing the write-head , if you will. When the write head reaches the end of the buffer, I wrap it to the beginning. When a new grain is created, it’s passed:

Hmm, what about the read head? Does it move with the audio at the same pace as the write head?

(To get the intuitive tape read/write style behavior, I suspect the read and write heads would have to move at the same pace by default, with ‘position’ controlling the position of the read head relative to the write head.)

[stoermelder (Ben)]

@clone45

Also @stoermelder, that’s an amazing idea! I’ve never tried that before. I have programmed some assembly language in college 30 years ago . Oooo. Getting old. Ha ha. First, maybe I should double check that my code is as efficient as possible. I just spotted some division that could be converted to bit shifting.

Andrew did a really good job to make SIMD quite easy to understand and to use. Take a look at the simd namespace. Many operators on simd::float_4 just work like on float, a few helpers like simd::ifelse() make you life really easy

[stoermelder (Ben)]

Also, some good read:

What's the point of writing "manual SIMD code"?

Rack v1’s API provides a new simd:: namespace with (currently just) a float_4 type, operator overloads so you can write d = a * b + c etc, and lots of functions which accept float_4 arguments. But aren’t optimizers good enough to vectorize code already? Well, yes. Suppose we want to add two vectors of 4 floats and store the result in the first vector. void add4(float *x, const float *y); The compiler does a great job! https://godbolt.org/z/uQdioo. I couldn’t write better assembly myself. (Not…

[clone45 (Bret Truchan)]

@OhWell

Hmm, what about the read head? Does it move with the audio at the same pace as the write head?

(To get the intuitive tape read/write style behavior, I suspect the read and write heads would have to move at the same pace by default, with ‘position’ controlling the position of the read head relative to the write head.)

Yes it does. You’ve got it exactly right.

[OhWell]

That sounds perfectly intuitive!

[Squinky]

Will this sequencer cut and paste with Entrian, Impromptu, etc?

[clone45 (Bret Truchan)]

@Squinky

Which module are you referring to? If it’s Digital Sequencer, it is on my to-do list.

[Squinky]

@clone45

If it’s Digital Sequencer, it is on my to-do list

Yay!

[clone45 (Bret Truchan)]

Hey @pgatt, I think I’ve found a good middle-ground to allow this module to be instantly accessible by everyone yet have the ability for serious weirdness. Essentially:

1. I’m going to add adjustable modulation source that applies to the Position which can be overridden with a CV input. This will keep the module from acting badly when no cables are connected.

2. I’ve added a spawn rate knob to control the internal spawn rate. Again, the internal spawn rate can be superseded by an CV input. But I’m also going to add CV control over the internal spawn rate because I’ve found that tweaking it can be a lot of fun.

3. I’ve consolidated and removed some of the controls that are no longer necessary, such as grain throttling.

I won’t have a new version to show off for a few days. I’ve got a lot of work ahead of me! But I think that everyone will love the changes.

[pgatt]

Awesome Bret, look forward to it. Let me know if you want a tester. Thanks for all your hard work.

[clone45 (Bret Truchan)]

Absolutely! I would love your feedback. I’ll keep you posted of my progress.

[clone45 (Bret Truchan)]

Hi Everyone!

I think I’ve finished up work on an expander module to Grain Engine MK2 that was originally requested by Artem (@VCVRackIdeas). I could use any help I can get to test it before I release it. Here’s a summary of what it does:

1. Position it to the left of the Grain Engine MK2
2. It records incoming audio
3. Once recording has been stopped, it passes the audio to the Grain Engine MK2. (What actually happens is that it saves the audio to a .wav file and tells Grain Engine MK2 to load it.)

Here’s the front panel:

There isn’t any documentation yet, so here’s a quick overview:

• INPUTS: The audio to record
• START REC: Start recording. If the module is already recording, a gate signal at this input will stop recording. In other words, you could hook up a LFO square wave to this input and ignore the STOP REC input.
• STOP REC: Stops recording.
• SAMPLE: Which sample slot (1-5) the recording should be saved to in Grain Engine MK2
• THROUGH: Mirrors the audio at the inputs

Here’s a link to the repo. It’s on my main branch:

GitHub - clone45/voxglitch: Modules for VCV Rack

I had to make some complicated changes, so I would really appreciate your help in testing this before it goes live.

Cheers,
Bret

[Caecos (Marc Demers)]

Broken link!?

[clone45 (Bret Truchan)]

Sorry @Caecos, I just merged it into my main branch. Please see: https://github.com/clone45/voxglitch

[Caecos (Marc Demers)]

Great…just compiled it for Windows…regards…

[clone45 (Bret Truchan)]

Heads up: I found a pretty nasty bug and fixed it this morning. If you had issues with it crashing when cranking up both RATE and GRAINS, that should be fixed.

[Curlymorphic (Dave French)]

Build and ran on Ubuntu 20.04, build had a few warnings but completed.

From my tests as an unfamiliar user of your module, all seem to work, I tried pluging unexpected signals in. if noise is applied as the trigger for recording, VCV does slow down, but not crash, every time i was able to delete the cables and stability returned.