12x sample loop player

[offthesky]

12x Sample Loop Player.yml (23.3 KB)
12x sample loop player.vcv (3.3 KB)

sloppy demo (not sure why he left channel is a little fuzzed):

12X Sample Loop Player 1

why settle for 8 loops, when you can have 12! each loop is mapped to a knob. when the knob goes >0 it triggers the loop. with all 12 loops playing, the cpu maxes at around 85%

requirements:
latest beta dev firmware and plugins:
https://metamodule.info/downloads

system ideally set to 48/128 to 512*

your .wav files should be 48/16 and not exceed 43.5s in length (the module resamples them from 48khz up to 96khz, internally).

knob set 1
A vol+trigger for loop 1
B vol+trigger for loop 2
C vol+trigger for loop 3
D vol+trigger for loop 4
E vol+trigger for loop 5
F vol+trigger for loop 6
u vol+trigger for loop 7
v vol+trigger for loop 8
w vol+trigger for loop 9
x vol+trigger for loop 10
y vol+trigger for loop 11
z vol+trigger for loop 12

knob set 2
z = reverb mix

note: currently all canard sampler modules are set to loop (read knob = 1). if you don’t want the samples to loop, adjust the read (param 4) knob on the canard module to 0. you get ping-pong with 2.

note: if you wanted all samples to just trigger from a single knob (in the case that you have a bunch of beats or loops that need to properly sync to each other), you can just take the push output from the knob you want (knob A makes a good starter knob) and route that to the trigger (or gate, depending on if you want to be able to stop all loops at once) in on all remaining canard modules you wish to sync to the first.

also note: this patch can be very ram hungry. if you have a ton of modules loaded, and you try going for the max number of 12 samples at 43.5s each, you may run into freezing issues when you hit the play button. the patch only utilizes fundatmental vcv plugin, and bidoo so you might try unloaded others first. regardless, the patch usually takes about 1:10-1:20 seconds to load depending on how big all your samples are(that is from usb, can take longer from sdcard!). one easy way to quickly tell when it’s loaded is the cpu meter will appear in the top right. or if you have auto screen black out feature turned on in your user prefs (and set to a number like 1 minute or below), the screen will automatically black out once the patch starts playing.

[MetaGhost]

Sounds superb! Great example mate.

[rossimatic]

Is 48khz required? Anything more than 6 canard’s hangs, using 44khz samples < 5secs. Tried system 128 blocks and both 32 and 48.

[rossimatic]

I’m gonna try recording into the modules now.

[rossimatic]

Trying to save recorded samples from canard yields 4k samples - obviously incorrect.

[offthesky]

@rossimatic

Is 48khz required

48khz seems to work best imo

@rossimatic

canard yields 4k samples - obviously incorrect.

@etcetc might know what’s going on there? i haven’t tried recording with canard but i had some luck with sickosampler (max record length = 30s w that module)

[rossimatic]

Thanks @offthesky - I’ll try the sickosampler. Gonna keep at it cause I do like the idea.

[offthesky]

@rossimatic

Trying to save recorded samples from canard yields 4k samples - obviously incorrect.

so i just gave recording with canard a go with the latest bidoo 2.0.1 plugin* and it worked! but two caveats i noticed:

1. the record button is tricky. you have turn it up past 50% to start the recording (you will see a little red dot top left of the record button in fullscreen mode) but to stop recording, you have to turn the rec knob down to 0% then back up past the 50% mark. a bit confusing imo but thats just how the thing was coded to work. also if you start recording again a 2nd time it will crash the mm. so you have to hit that “clear” (turn up past 50%) and remove any samples loaded in, before starting a new recording.

2. saving samples worked ok! but when i reloaded the wav file into a new instance of canard, it only showed half the recording, and the 2nd half was just silence. @etcetc could this be related somehow to the issue we had where the wavs were getting truncated in half on load? dunno

and when i saved the patch, and restarted the mm and reloaded the patch, the sample loaded back into canard no problem (albeit, cut in half)

Release Release: v2.0.1 · Ericxgao/metamodule-bidoo

[etcetc]

Taking a look - how do you reproduce the record crash? I can’t seem to trigger it even with turning off and on record a ton - does it need to be playing or something.

Investigating the second issue.

Btw - VCV Library - Lomas Advanced Sampler - is this worth porting?

@offthesky @rossimatic

I am attempting a fix in v2.0.2 - I think it’s working now? No more extra silence, and also it saves properly if the sample is playing, whereas previous that would corrupt the saved sample.

You can find it here when it finishes compiling Releases · Ericxgao/metamodule-bidoo · GitHub

[offthesky]

@etcetc

Btw - VCV Library - Lomas Advanced Sampler - is this worth porting?

maybe not? as it’s monophonic. also its more drum centric- it works via a load folder/index, but the vox glitch wav bank module(stereo) already does that. lomas does have envelops though and a loop function.. anyway, others might disagree with me there on whether it should be ported or not.

@etcetc

I am attempting a fix in v2.0.2 - I think it’s working now? No more extra silence, and also it saves properly if the sample is playing, whereas previous that would corrupt the saved sample.

awesome will give a try again when i can today!!

@etcetc

how do you reproduce the record crash?

for me i just recorded for about 10 seconds, then attempted to record again without clearing the sample out first.. that seemed to crash the mm. ill give it a try again alter with this new 2.0.2 to see if i can repro

[etcetc]

I see, do let me know. I found another bug where it will crash if you are sending a gate/trigger in with no sample, then try to load a sample. Fixing shortly in the next release

2.0.3 should fix more loading sample crashes…

Note, I had to make saving samples blocking. It will pause your audio if you save a sample, I assume that this is okay as I assume you’re not going to be doing this often live? It just fixes a ton of race conditions.

However, I’m noticing that the audio still freezes when I’ve used an asyncthread

Bidoo/src/CANARD.cpp

@danngreen

Is this because of my rudimentary spinlock implementation? I added it in originally to try and fix some more race conditions: https://github.com/Ericxgao/metamodule-bidoo/blob/7b5d844fc86b884c9d30c9849aac49de884967d0/src/mutex-stub.hh

[offthesky]

@etcetc

2.0.3 should fix more loading sample crashes

awesome 2.0.3 seems way more stable! only crash i ran into is when a recording went over the 2 minute mark.. but maybe there’s nothing that can be done there. still, pretty great we can record past the 1:30s mark directly on mm now! very useful. will keep playing with it and let you know if i find any more wonkiness.

also im finding that using hetrick’s comparator running into the rec input, then mapping an mm knob to that, seems to do the trick in making the record function better
(+50%=rec on, -50%= rec off)

[danngreen]

@etcetc

Is this because of my rudimentary spinlock implementation?

I’m on the road and not able to look in detail but in general spin locks are not good tools for AsyncThreads because there is no OS to interrupt the spinklock.

If your AsyncThread has a spin lock then it will block all other Async threads (on everybody else’s modules) until your module releases the spinklock. So generally that’s a bad idea except maybe some
very obscure situation. Better to have your AsyncThread run continuously (not run_once) and make it check for the lock at the start of the thread and just return immediately if it can’t get the lock.

Spinlocks in the audio thread are also a bad idea obviously, since the Async Thread will never get called because nothing ever interrupts the audio thread.