could this be extended from 32 to 256 to match the 256 hex code limit.
I’ve been trying to do delay based loop stuff lately.
Also, line sync values don’t seem to be automatable.
No the line sync isn’t automatable because they apply a formula on the right and left delay sliders which are both automatable. If the amount of lines you want to synchronize does not surpass the limitation of 2000msecs, you can view the slider value in milliseconds for each amount of lines that you want to have by clicking the set button next to it.
Extending to 256 should not be too hard i guess.
Also extending the delay amount for the sliders to a maximum of “half the time of the longest pattern” seems the best solution to me imho.
When not using Line Sync, use N50X and N60X (N = Position in the Chain, X = Line Sync Value). When using Line Sync you can even draw automation for this…
Its limited to 32 because we would else waste memory like hell. Remember that a duration of a line also depends on the BPM…
then how about allowing as much lines as the fixed memory buffer allows for the current speed? I guess that could then be “capped” if the speed goes down etc.
I see you can automate the line sync value by drawing automation and funnily enough it goes all the way up to 255.
It can be drawn down to 0 too which might be counted as a bug.
And about the memory usage, yeah. I didn’t think about that stuff.
The limit is in seconds (2 seconds) so you can use the 255 if cranking up the LPB/BPM settings…
If implemented yes, but the 32 lines is currently a hard limit regardless of the LPB/BPM settings…