Published v0.11 to fix issue with firmware v2.0.0-dev-12.5
1 Like
hello, apologies if this is a stupid question, but where can i download Sicko plugins for dev firmware?
EDIT: nevermind, found the github repo in comments, but maybe it makes sense to add it to the first message in the thread?
I think it will be added to metamodule site soon
3 Likes
published v0.12.
added randLoops, randLoops8, trigSeq8x modules
8 Likes
…And it’s up on the official v2.0-dev plugin zip file!
4 Likes
published v0.13 built for dev-13 SDK
added new modules: stepSeq8x, drumPlayerMk2, drumPlayer mini, ad mini, enver mini, randLoops mini, slewer mini
4 Likes
after some further tests i notice now that sickosampler allocates ram in chunks of 8mb, 16mb, 32mb, 64mb(this being the max, i think)… so a 21s 48/16 sample will use the 32mb allocation, but a 22s 16/48 sample will use the 64 amount. so we could run 4x 21sec samples, but only 3x 22s ones (with no other plugins installed but sicko) - which is a bit limiting. anyway, im curious if there might be a chance at some point we could see the samplers allocating in more granular amounts (30, 40mb 50mb etc). if that’s just impossible based on the way things are setup in the code, i totally get it…
i will say, i do really appreciate that samples can be loaded on the fly while the patch is playing and it doesn’t mess up the audio out signal, which is really awesome!!
edit: sorry to feature creep up there ;]
1 Like
also @sickozell - im noticing an issue where with sickosampler2 in vcv the full sample will load, but in mm it seems only part pf the sample will load. is this a known issue or am i just doing something wrong with ss2 in mm?
vcv reads 1:18
exact same sample loaded in mm read only 30s and on playback, definitely not hearing all the sample:
also seems to occur with the sickoPlayer
on latest firmware v2 dev 13.4 (latest plugins from bundle in thedownload)
maybe it’s something with that wav file that drwav library can’t read. How long should be that file? Which samplerate? How many channels has it?
[Edit: Maybe MM ran out of memory? What happens if you build a patch with only that sample?]
its just a stereo PCM signed 48kh/16bit wav file. it’s 1:18 long m, 14.4mb on disc. my patch was made from scratch on the mm: 1 instance of sicksampler2 routed to outs 1/2. ram showing 83/278 after the wav is loaded.
i also just tried w a different wav that is 33 seconds long and the ss2 only shows 30s. it seems anything over 30s is getting cut down to 30.
i can send you these wav files if you need them
Maybe it is memory allocation limit in MM? @danngreen should be able to provide info.
yes, that’s the memory allocation limit we agreed with @danngreen : it’s about 30 seconds stereo @48khz and about 1 minute mono.
ah ok 30s is the hard limit
Okay, wow. I think I got to the bottom of this whole thing after @offthesky remarked that some other wav players were hogging RAM.
First things first, Sickozell maintains copies of the original sample buffer, a filtered version of it I believe (?) to prevent aliasing, so most samples loaded in will be 2x as expensive for memory. Wondering if this is really necessary.
Second, the big question - why did RAM keep going up by powers of 2 seemingly?
The answer is in this
playBuffer[1].push_back
Whenever we call push_back on a vector, and the vector is too small, it will dynamically reallocate to make its capacity larger. This is usually a doubling of its original size - see What is better: reserve vector capacity, preallocate to size or push back in loop? https://stackoverflow.com/questions/32199388/what-is-better-reserve-vector-capacity-preallocate-to-size-or-push-back-in-loo · GitHub
So it looks like we can use reserve or shrink_to_fit to help combat this.
In practice though, I am still running into an issue - even though my debug printout on simulator shows less memory usage, the RAM usage on the MetaModule is still the same. Will have to keep digging.
2nd Update:
I figured it out now I think. I’m not sure if shrink_to_fit works on the MM, but this swap trick does, which condenses the vector to fit its content
vector<float>(playBuffer[1]).swap(playBuffer[1]);
Which seems like it’s working now to reduce RAM usage
3 Likes
Yeah, that’s how the allocator works in gcc (2x the size each time you need to allocate more).
Seems like reserving ahead of time is the way to go, and if you can’t know ahead how big it will be, then using the swap idiom is the way to go (it does a huge memcpy, so not to be used unnecessarily!)
Released v0.16 with these changes:
- sample player modules (sickoplayer, drumplayer, etc): reduced memory usage by removing unfiltered copy of the sample and allowing only anti-alias function on MM (for now, on recording modules as sickoSampler, two copies of the sample, 2x oversampled, are needed to work)
- all sample managing modules: general memory allocation fixes. (swap() + reserve())
5 Likes
Thanks again!!! so now we can save the .yml file with the samples?
Unfortunately It’s not the change you wish. Just sample memory allocation fixes
Update to v0.17.
The sample duration limit is now set to 2 mins @ 48khz mono or 1 min @ 48khz stereo.
About memory usage, the player modules (sickoPlayer / drumPlayer / waveTabler) are now using just one 2x oversampled anti-alias filtered copy of the sample, so it’s halved respect other recording modules (sickoSampler / keySampler / sickoLooper).
6 Likes
Update to v0.19 (vcv 2.7.4)
new modules: stepStation, trigStation, sampleDelay
6 Likes