Voxglitch modules - beta testers welcome!

Awesome. Thanks. Look forward to it!

Somebody can share a compiled Mac osx version to try? Thanks in advance!

1 Like

@VCVRackIdeas Artem, you wore me down. I succumbed to your request for purge buttons on the front panels. They’re on the master branch right now. :smiley:

image

image

1 Like

All in the name of UX!) Thanks, will check that a bit later but I guess it is pretty handy tool for testing a sample again n again so fast

1 Like

To block DC, just add a highpass filter at “not DC”. Take a look at our Shaper module, I think we use a 4 pole butterworth filter at 50 hz. Not sure, however.

2 Likes

Thanks!!!

I’ve put together a module to experiment with mixing granular synthesis with an audio input. It’s a bit tricky so far. I’m reading audio into a circular buffer with enough memory for about 1 second of audio.

The difficult part is figuring out which portion of the circular buffer the grains should play at. It’s not an easy problem to describe without a whiteboard. Ha ha ha.

At the moment, I’m trying to apply everything to incoming streaming audio. It might make things a lot easier if I add a “record” button that fills a buffer with audio. But I’d rather get something interesting to work real-time.

I’ll keep working on it this weekend and see if I come up with any breakthroughs.

1 Like

That would be awesome if it can be real-time. Opens up a lot more possibilities!

autobreak-front-panel

Hello everyone! This weekend I threw together a new module idea and could use your advice. Here’s the concept: You load in a drum loop and the module chops it up, break-beat style, based on a bunch of internal breakbeat pattern arrays.

Each sample is (conceptually) split into 16 slices.

A breakbeat pattern array might look like: 0… … 5… 13…

Each value in the breakbeat pattern array represents one of the 16 conceptual sample slices. During sample playback, if a value is not “.”, sample playback jumps to that slice.

I hope that you’re following so far! There’s also a CLK trigger output that fires at every 1/32nd of the sample playback length, making it possible to control timing of an external sequencer, etc. And finally, there’s an END trigger output that fires at the end of the sample playback.

Here comes the tricky part. It’s designed so that you can switch between samples during playback. But if the sample lengths aren’t identical, things can get a little wonky.

Should I normalize all of the sample lengths by essentially stretching out the smaller samples to match the longest loaded sample? Or, should I add some type of BPM selector and play all samples at that BPM?

I’d love to hear your thoughts.

Cheers, Bret

3 Likes

Another home-run! I like it a lot.

Stretching them out would be better as long as pitch is preserved. Without playing with I can’t say for sure. BPM detecting could work as long as pitch is preserved also and assuming a sample has the same amount of bars.

Setting the amount of bars a sample has by ear would better aid BPM detection. If the 1/32 could snap to the nearest 0 crossing it could split slices properly, but that is provided the loop has that time signature or a multiple of this.

some things to consider:

  • Slice detection working on max peaks
  • nearest 0 crossing to those peaks
  • Threshold for min dB to detect max peaks i.e. number of peaks 8 (9th peak not detected based on Threshold)
  • Set number of slices (8 peaks) reduces to 7, where lowest thresholded peak eliminated ( previous slice gets longer)

The only issue doing this is transients, where a pad would not have many

If it is just split 1/32 on the length I reckon it will click like crazy when on a lower BPM.

Thanks , works fine here on Mojave

Thanks a lot for these modules @clone45 , promise a lot of fun experimentation’s and creation’s Here a first test :wink:

3 Likes

@Coirt I’m using my smoothing code to interpolate between sample slices whenever playback jumps to a new slice. I had to fine-tune the smoothing code, but it seems to be working and removing any nasty clicks.

I’ll have to consider your other ideas for while. BPM detection sounds interesting, but I don’t know what to do if someone loads in samples with different BPMs. That’s why I was thinking of having the user choose the BPM, then adjust all the samples to match that BPM. PS: Glad you like it!

1 Like

@Nay-seven Wow! You’re pushing the modules farther than I’ve tried so far! I love it!

Hey, Thanks @clone45 ! Really glad you like it ! I’m very impatient to see where your research will take you with these modules, it’s going really well anyway and I’ll follow this with pleasure, thanks again!

Which way does pattern select work? Do the patterns have to be programmed in, if so 16 small displays with up/down arrows would be amazing, with pattern select now taking input from these rather than hard coded.

Crash on negative voltage - pattern select issue posted to GitHub https://github.com/clone45/voxglitch/issues/7

@Coirt Hey Phil, you’re already playing around with it!? Ha ha ha. Rock on! It’s totally still in development. Thanks for catching the negative voltage issue. I’ll fix that this evening.

To answer your question, the patterns are hard-coded at the moment. The array of pattern that’s currently supplied is mostly for testing purposes and doesn’t contain many useful patterns. In the array, a value of -1 means, “Don’t do anything. Just let the sample continue playing uninterrupted.”

int break_patterns[NUMBER_OF_PATTERNS][16] = {
   { -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1, -1,-1,-1,-1 },
   { -1,-1,-1,-1,  0,-1,-1,-1, -1,-1,-1,-1,  8,-1,-1,-1 },
   {  0,-1,-1,-1,  0,-1,-1,-1, -1,-1,-1,-1,  0,-1,-1,-1 },
   {  0,-1, 0,-1, -1,-1,-1, 4,  6,-1,-1,-1,  6,-1,-1,-1 },
   {  0, 0, 0, 0,  0, 0, 0, 0,  0, 0, 0, 0,  0, 0, 0, 0 },
   {  12, 14, 12, 12,  0, 0, 0, 0,  0, 0, 0, 0,  0, 0, 0, 12 }
};

The pattern select input decides which of these arrays to use. I like the idea of being able to dynamically switch between patterns during playback. Quickly sequencing between break patterns can result in brand new patterns. Or, slow changes to the selected pattern can evolve a breakbeat slowly over time. I intend to place similar breakbeat patterns next to each other and provide… oh… maybe 32 different patterns?

I like your idea of allowing the user to provide a pattern, but I’m not sure how to do that yet and still support CV control over multiple patterns. I’ll think it over.

Was thinking along these lines… Mockup:

@Coirt That’s pretty cool. In order to allow for switching between patterns via CV, I suppose you could have 8 rows of patterns? Like this?

image

I wonder though: If I supply 32 different preset breakbeat patterns, would that be adequate for 99% of the use-cases? Would giving users the ability to supply their own patterns be really necessary?