surge-synthesizer / stochas

The Stochas Sequencer
https://stochas.org
GNU General Public License v3.0
406 stars 35 forks source link

Can't add anymore forward chains #42

Closed dooleyj closed 3 years ago

dooleyj commented 3 years ago

I have 32 notes and 19 of them have 1 or 2 outgoing chains.

I am trying to create a random sequence that avoids perfect forths and fifths.

When I try to add any more forward chains, nothing happens. I do the CTRL, click drag, the arrow/line appears but vanishes when I let go.

OS: Win10 My host is FL Studio 20.7.2 Stochas Version V1.3.HEAD.a2346d3 Screen shot: stochas-bug Patch file first-try.stochas.txt

Thanks

baconpaul commented 3 years ago

https://github.com/surge-synthesizer/stochas/blob/fc1a34df6a06e78eea08ded840788a877c2fa925/src/Constants.h#L101

So @rudeog will know way better than I do but it looks like 24 chains per row is a compile time constant right now. I don’t know the consequence of growing this but it certainly explains what you are seeing!

rudeog commented 3 years ago

@baconpaul is correct. You have reached the limit on the number of chain sources. This limit could be easily increased by just increasing that #define. And in fact it probably should be increased if it's actually being encountered in a real world scenario.

The question is, what is a good maximum? We could easily double it, but is that enough?

Each column of cells in the grid currently has this limit of 24 incoming arrows. The reason is because of the way the patch is laid out in memory and the way things are calculated... The incoming arrows are stored in an array (each element having 4 bytes) attached to each column. There is a max of 64 columns in the pattern, a max of 8 patterns and a max of 4 layers, so each number over 24 will consume an additional 8k of memory. Not too big of a deal, however some number had to be picked. The other factor is there are a few places in the code where we loop over this array while calculating which notes to play (possibly within other loops) and so this could have a performance factor (however I believe that even for a much higher value it would probably be negligible).

So eg. if we double it to 48, we are adding 196k to our memory consumption and a little bit of extra CPU %

dooleyj commented 3 years ago

Thanks for identifying this is not a bug or my computer freaking out, but just a current design limitation.

I can see where the 5 types of arrow connections is sufficient for drum patterns where each step on has roughly 8 notes to choose from, but patterns for muti-octave instruments is a whole different ball game.

I not sure I want to argue for upping the limit on incoming arrows per se, all I want to do is have a way to avoid steps that are perfect 4ths and 5ths across muti-octaves. Perhaps not with literal arrows, but maybe some logic formula like if no arrow, play whatever, but not any steps that are perfect 4ths or 5ths.

Thanks for looking into this, sorry if I opened up a can of worms.

baconpaul commented 3 years ago

@rudeog my experience with the surge users has been (1) people stretch things beyond limits but sometimes you need static data structures so (2) when there are limits at least pop an error up in that case. So 48 + a dialog on 49 is what I would do if this was a surge mod matrix thing. (The surge mod matrix is dynamic but there are other static data structures).

I like the idea of a logical constraint on an arrow. But that also sounds like way more work than 48 + a warning!!

rudeog commented 3 years ago

Sounds like a good plan, Paul.