Nice! Welcome back! Second v/Oct would be dope.
1 Like
i honestly went back and added that option like half an hour after posting this update lol. the context menu has gotten a bit crowded and will need some cleaning up, but i like having and giving more options rather than less 
3 Likes
hey folks 
i think i’m getting closer to pushing the full update up to the github repo and submitting to the library.
i’ve made a number of changes to various modules. some bigger changes but mostly minor tweaks and fixes for bugs i never caught before.
slips contains the most changes, obviously. i outlined most of them in my last update post. since then, i did finally add an option to quantize the new modulation sequence output, and i’ve also (again at the request of Mr. @Omri_Cohen, who almost certainly uses slips even more than i do lol) made it so that when the “starting step” cv input is connected, changes to the input value will immediately move the currently active step to where it should be in the sequence, given the new starting step. (just now considering adding a toggle to the context menu for this behavior, TBD)
at the moment, with no cv input, manually changing the starting step parameter will still wait to take effect until the next cycle - still not sure if i want to change anything about that, so i’m definitely open to suggestions. also, as it is currently, i don’t believe manually adjusting the param will even do anything if the cv input is connected. again, something i still need to consider.
other than the slips changes, i’d say the biggest change is the addition of ‘polyshuffle’ and ‘polycounter’, which are just dumb little utilities i decided to make because i needed a distraction from bugfixing for a while. well, technically, ‘polyshuffle’ was initially my attempt at a module someone had asked for here in the forums some months back, and i finally got around to finishing it. ‘polycounter’ is something i threw together just in the last few days.
‘polyshuffle’ just takes a poly input, and on a trigger, rearranges them either by shuffling them randomly, or rotating them ‘up’ or ‘down’. reset trigger does what it says and resets all channels to the original order.
as for ‘polycounter’ - basically, given a ‘start’ and ‘end’ value (currently maxing out at +/-10V), as well as an ‘increment’ value, each trigger received will increment the output value by the ‘inc’ value (also clamped to +/-10V). when the count reaches the end (or start, if being decremented with negative ‘inc’ value) it wraps around. (so incrementing the value 10.0 by 1.0, with a start value of 0.0, will wrap back around to 1.0, basically skipping the initial ‘start’ value - still not sure if that’s the best option, but i’m ok with it so far) a trigger sent to the reset input will reset the count to the ‘start’ value.
and yes, as the module is called “polycounter”, this is all polyphonic. output channels are determined by the trigger input channels, with each channel having a dedicated counter but all using the same start/stop/inc values. if the reset input is mono, when it receives a reset trigger, all poly counts will be reset, but using a polyphonic cable, only the output channels with a matching channel number will reset to the start.
again, probably not that useful, but was a random thought i had and figured it was something easy to take my mind off other things for a while. in any case, it’s officially the 20th module added to alef’s bits (not counting the slips expander “slipspander”, that is), which is kinda cool to me.
if you actually read all of this, i’m sorry, and thank you lol. i honestly just felt like rambling about what i’ve been working on because it keeps me motivated.
12 Likes
i’ve finally pushed all of my recent changes up to the repo, and created a new release (using an updated github action which now also builds for arm64). holding off on submitting to the library for the time being while i make sure i haven’t forgotten or overlooked anything, but y’all are welcome to grab the newest build and check out the changes so far for yourselves.
if anyone does, and you come across any issues or have any requests, definitely let me know! (either here or by submitting a github issue, whatever you choose)
4 Likes
I tried updating your modules in <other project> but there’s a bunch of things that will need tweaking like async file dialogs, undeclared functions and some issue with std includes.
We will probably send a PR your way when that’s been sorted.
2 Likes
thanks for the reply. i’m not quite sure what you mean by <other project>, though…
EDIT: nevermind, just remembered. thanks for the heads up 
i’ll watch for a PR.
1 Like
I am playing with some of my “old” Alefs Bits patches with your new test version. Was the quantizer in and out removed from Slips? Or am I just overlooking it? If the functionality is removed, was it moved to another module or is it just gone. I had not used it before, but I have an interest in modules that expose their internal quantizers for external use, as I do in Meander. This is not a big deal, but the question may come up from others is they were using the quantizer in and out in Slips.
A cursory look at the old and new panel images turned up no apparent other such panel patching changes to an existing module.
yes, I did remove the quantizer input and output. I never ended up using it myself, and wanted to make some room on the panel for the new modulation sequence controls. I suppose I should have made clear that there were likely breaking changes.
1 Like
well it’s a good thing i’ve been taking my time with these updates.
i just discovered that my ‘polyrand’ module is not doing what i initially wanted it to do, and looking at the code, i honestly have no idea what i was thinking lol.
the idea was simply to take a poly input, and on a trigger, pick one random channel to output. that’s it.
but for some reason, i was also making the output polyphonic. not to mention i was only sampling the inputs on the trigger, and only outputting that single sampled value rather than allowing the channel to simply pass through entirely.
no idea where i was trying to go with that, but i’ve now reworked it so that it does what i intended.
and so the bug hunt continues…
3 Likes
sounds like a good time to write some unit tests for that module!
i’m starting to think that i must have been trying to implement some sort of sample & hold functionality, but that’s not at all how i remember wanting it to function…
not sure unit tests would have told me that lol
in any case, yeah i know unit tests are something i should probably be doing, and i just keep avoiding it. some day… 
You would make a unit test that tests if it does what it’s supposed to, of course. And a super basic test is “does it have the number of output channels I expect it to?”.
oh i understand the concept. my point was that since it seems i was trying at the time to do something entirely different from what i actually initially wanted to do, i would have just been writing unit tests that wouldn’t have told me i was on the wrong track from my initial idea. if that makes sense.
1 Like
barring any new bugs i come across or which are brought to my attention, or any further feature requests, this is likely the last update before i submit to the library sometime in the next week or so. and as i stated with the last build update, i’m using the updated github action which builds for all platforms including arm64, so i’d be curious to hear if it actually works on all those platforms.
Seems to work on my Windows test patch from last week. Well, I should say Slops works as that it the one I have been playing with.
1 Like
ok, i’ve finally submitted the updates to the library. i have a fear that i’ve overlooked something, but i suppose only time will tell.
since my last submitted updates before taking my break from development caused build failures on arm64, they never made it into the library, which means that on top of all of my recent updates/additions to the plugin, the modules ‘nos’ (my dumb and chaotic random-noise based oscillator) and ‘lucc’ (clock divider based on the Lucas number sequence) will also be added in this release, as they were part of the updates that caused the arm64 build failure.
1 Like
i’m almost certain most of you have already noticed by now, but my internet was out all day yesterday so i wasn’t able to point it out until now - the most recent updates to the plugin are now live in the library.
3 Likes
Does CV control work for Slips? (root, steps, scale, start, prob and slips)…I have tried each and can’t seem to change the params.
I am on Windows.
My windows 10 VCV pro is modulating all those parameters fine.
hmm, strange… as far as i’m aware all cv inputs should be working fine… i haven’t had any such issues and this is the first i’m hearing of it.
although now that you mentioned it, i just hopped into Rack and tried them all out myself, and found that it seems like cv control over the root note and scale, at least, may not be working correctly.
i’ll have a dig around and see if i can figure out what’s happening. thanks for bringing it to my attention
1 Like