Thank you for your time and effort! I hope it will not be too much hassle for you.
1 Like
coming back to this with a little more time to digest it. i think i may be a little confused by what you’re asking.
basically, the intended usage of the polyphony in slips is to allow for notes to continue ringing out (like a built-in internal version of Grande’s ‘Tails’ module) while the next starts on a new channel.
maybe i’m misunderstanding your description, but it kind of sounded to me like you were expecting each channel of the poly signal to have its own unique sequence of notes? if so, then no, that’s not really what the intention was at all. i suppose i could consider something like that, but i feel like it would be something pretty substantial to add to a module that’s already rather unwieldy lol.
again, please correct me if it seems like i just didn’t fully grasp what you were saying.
1 Like
Thank you for explaining!
Yes, you are right in that I anticipated Slips to generate a unique sequence of notes on every polyphony channel.
Grande’s Tails is a fantastic module. However, I believe it is used for overlapping envelopes, not sequence generation, so the reference here is not exactly clear to me.
With Slips, for example, when Channels in the context menu is set to 16 and the Steps knob is set to either 16, 8, 4 or 2, each channel produces a flat line, not a sequence. Also, I do not see any ‘ringing out’ happening or being involved, as there is no input like there is in Tails.
But like I said, I also do not ask you to make any changes, because it is easy to avoid step sizes that are divisions by 2 of the number of channels.
It’s more just me trying to understand the utility of your design.
1 Like
3 Likes
Thank you for sending the video! Wasn’t aware of it, so all clear now, love it.
1 Like
yeah, sorry for the confusion lol.
when i said “let notes ring out” i just meant that it keeps each subsequent note + gate combo on its own unique channel, sort of acting like a sample and hold, allowing that step’s note to continue playing from whatever oscillator/voice it’s connected to while the next step plays on the next channel, so it doesn’t interrupt the previous one by cutting it off.
you’re right about the “overlapping envelopes” concept, i just described things poorly in my previous comment. 
1 Like
thank the gods for Omri Cohen 
All good, and thank you for clarifying. No matter what, Slips just is an exceptionally useful module, so thanks again for making it available!
1 Like
thank you so much 
i’m always genuinely thrilled to find out someone likes something i made, and slips specifically has gotten a lot more love than probably anything else i’ve ever made. i’m ever grateful for the praise and/or compliments (even if i don’t always feel like i deserve them lol).
4 Likes
hey everyone, a small news update:
i recently (finally) ditched Windows, and have moved over to daily driving Linux (arch btw) for a couple of weeks now. it’s taken some time to get used to things, but i am now at a place where i’m able to have a reasonably comfortable and functional development environment.
with that said, i just got Rack building from source, pulled down alefsbits, got it building as well, and decided to poke around with Nos’s polyphony issues again to see if enough time has passed to where i could come at it completely fresh.
as it turns out, i could. i’m pretty sure i just managed to completely fix the polyphony problem altogether.
(EDIT: as a reminder, ‘nightly’ builds are available on my github. most recent build includes the Nos fix. if anyone gives it a try, please let me know if it breaks at all for you, or even if it works correctly in the first place - Release nightly build updated with every push · alefnull/alefsbits · GitHub)
i’m not trying to make any promises or anything, but i was fairly excited that i managed to fix something that had vexed me every other time i’ve previously tried to tackle it, and in such a short amount of time (more testing required, but still).
so i really just wanted to share that much - that i’m tentatively dipping my toes back in, but with at least a little bit of extra confidence (and even some success) this time.
- ℵ
(EDIT EDIT: one final note - i just noticed while doing some more testing that it at least appears to me so far that my polyphony fix may have inadvertently also fixed the CTD that was originally reported by @octex912 back in September. would very much like to know if anyone can confirm that the CTD is no longer occurring for them when plugging in something like the VCV LFO with ‘offset’ toggled ON into Nos’s pitch input)
5 Likes
@alefnull Hi, i tried new github build of Nos - can confirm that adding VCV LFO modulation not cause crash anymore. Thanks.
Howewer, with adding square wave i observe some specificaly behavior, when sound become to stop going from Nos (or become very quiet) after a few square cycles (+ some actions with Nos freq and\or LFO freq for more quick catch this behavior). As if square shape produce falls beyond some boundary, thereby changing the operation of generator in Nos, and even after remove the modulation cable or initialize device the sound not bringing back (or it starts sounding again but after long awaits lol). Load new module instance helps though. Although i can assume that this is some normal behavior, idk due to some nuances in Nos engine maybe. But for to be sure better say.
1 Like
thanks for letting me know. I’ll try to reproduce the issue on my system when i get a chance and try to figure out what’s going on.
is the square wave you’re using a +/-5v or 0-10v signal? or something else?
1 Like
just pushed up a change to try fixing this.
basically, if i’m understanding right, you’ve been putting a square wave signal (i’ve been assuming an LFO) into the pitch input, which led to weird issues like silence or the value not changing after removing the input.
i tried doing the same, and definitely noticed some oddities. i’m not entirely sure exactly what is happening, but it clearly has something to do with putting more extreme v/oct inputs that would produce inaudible or even piercing sounds.
without knowing more specifics, my best idea so far was to simply clamp the pitch input value to between -4.0 volts and +4.0 volts, since the base frequency/note is “C4”, it will now only allow inputs to bring it between C0 and C8 and shouldn’t stray outside of that, causing weird issues.
i also fixed it so that if there is no input connected, it defaults back to the base frequency set by the parameter on the module. that’s something that just should have been in place to begin with.
let me know if this works for you when you get the chance. thanks again for testing and experimenting!
2 Likes
@alefnull Sorry for late reply.
Yes, i did check now (most latest github build) already with no described “lack of sound” behavior. Seems all ok. Thank you for module, nice “machine” texture.
I’m tests with basic VCV LFO module (SQR 0-10v yes).
1 Like
got it.
yeah the pitch input should have probably been clamped to begin with, but like many errors in my plugin over the years, it was a silly oversight on my part.
thanks again for testing, and for the kind words.
i’ll try to submit the fixes to the library sometime soon. i’m still reviewing the rest of the plugin for any other issues i need/want to fix before submitting the next update.
1 Like
just made a change to slips in the new nightly build, which i imagine will be a breaking change, at least in terms of saved sequences.
up until now, slips has been mapping the sequence, slips, and mod values when they are generated, meaning that when changing the cv range in the right click menu, you would need to generate a new sequence for the new range to take effect.
i have now moved the range remapping to just before quantization at output, meaning changing the range will update immediately.
this also means, however, that from now on, all note sequences as well as slips and mod sequences will be saved in patch files as values from 0 to 1, rather than as their initially cv_range mapped values. this means that this new version will almost certainly not work correctly with old patches.
for now, this is just something i wanted to try, because i got sick of having to regenerate the sequences whenever i wanted to change output ranges.
i would very much like to know if others feel the same way or if there is a desire to keep it as it is now so as to not break old patches. please do let me know your thoughts, if any - especially if you give this new version a try.
I think I prefer the old method where actual CVs are stored in the patch/preset; also it would be hugely disappointing to have old patches break.
2 Likes
I second that as Slips is by far my most used sequencer. However I think the new behavior also gives me some cool options to change the sequence range during playback.
If I remember correctly there were 1-2 cases on this forum where module devs introduced a breaking change and decided to implement it as a right click menu option with the following functionality:
- new instances will have the new behavior, with the option for switching to the old one in the right click menu (and have that permanent by overriding the default preset)
- Existing instances / patches will default to old behavior
@alefnull If you feel like introducing the new behavior, maybe this is a road to take?
3 Likes
thanks to both you and @auxmux for the feedback.
i definitely do not want to break patches if i can help it. adding it as another right-click menu option is absolutely feasible, and probably the best solution that i’ve been able to come up with myself as well, so i’ll absolutely start working on that soon.
i’m not 100% sure how to go about picking the behavior based on whether it’s an existing module or a new instance, but if that’s possible it’s certainly another idea to look into.
i very much appreciate the responses (and i don’t think i’ll ever get tired of hearing people say slips is one of their most used sequencers genuinely brings a smile to my face every time)
more than anything, i want to avoid making any changes to it that the people who actively use it wouldn’t want. i know that making ‘breaking changes’ to modules seems to be rather frowned upon by a lot of people, which i understand. at the same time, i’m an amateur hobbyist who struggles a great deal with long-term planning or foresight, etc. so i have a bad habit of thinking to myself “this is great, i like these changes a lot, i’ll just go ahead and push them” without considering longer-term implications.
very glad i decided to seek feedback on this one before just committing myself to it as i’ve done in the past
will update again soon when i’ve had some time to think and experiment a bit more.
3 Likes
here’s my only concern about adding another right-click menu option, and it’s a concern i’ve already had about the module for a while now, and that’s that i’ve already included so many options and settings into the right click menu, causing it to get a bit… unwieldy, in my opinion.
out of curiosity, is this just a “me” concern? does anyone actually even care how many options or settings there are in the context menu?
…does anybody even use the “root input v/oct” option? i certainly don’t, so it’s kind of funny that i spent as much time and effort into adding it as i did lol
