essej
Add global cycle pos cmds and show it in gui
This commit adds the commands "global_cycle_len" and "global_cycle_pos" to sooperlooper and a gui element showing the position in the current sooperlooper cycle. This feature only works in Internal or Jack sync mode with quantize set to cycle or 8th (i.e. whenever sooperlooper actually has an internal cycle).
When recording the first loop in sync internal + quantize cycle + first loop on sync it is hard to hit the first note at the beginning of the cycle. A visual indicator of where we are in the cycle helps to be on time in situation where no other cue is available.
The gui element has currently no text and only displays the current cycle if its length is >= 1s. Both of these measures have been taken to reduce visual noise in the gui.
Soo, I've been having this problem with not knowing where in the sooperlooper cycle I was when I wanted to record my first loop, so I decided to make it visible. Display is done with a SliderBar, which I think is quite neat for displaying this (..or it's the best widget I've found on short notice to do the job). I hope this is useful to someone else as well.
This is my first deep dive into the sooperlooper source and I tried to orient myself a bit on the code surrounding my changes. Also, if you think the new widget in the top bar creates too much visual noise here's a couple things we could still implement:
- hide the widget when we're not in sync mode jack/internal and when the global cycle is shorter than 1s
- make display of this widget configurable via preferences
Though I had some trouble with hiding/displaying that widget. Reviews / comments welcome! ;)
I'm trying out. My suggestion would be that instead of displaying a new widget, what about if the button for "quantize" instead becomes this display when the button is set to "cycle". Just my two cents.
Since these are global values, you shouldn't have them be part of the per-loop state... instead add them to the global parameters /get OSC api (and from the GUI use get_global_value() and is_global_updated(), etc. As for the UI element itself... Eric may have the right idea to try to overlay the indicator with another control like "sync to" or "quantize", even though that is obviously more work...
I'll take a look at putting this into the global values. My first attempt of this did not work, but it might be because I haven't properly requested updates in the GUI.
Regarding the GUI element.... I like the idea as well, though the quantize box is a ChoiceBox and doesn't have the relevant indicator code that SliderBar has. I don't think I can make it a SliderBar. I could try to port the indicator code to ChoiceBox if that would be an OK use-case.
I taught the ChoiceBox how to draw a bar! The interface is far less sophisticated in comparison to the SliderBar (it only displays values between 0.0 and 1.0, no indicator and all of that), but it does the trick (I think in this case it even looks better without the indicator).
@essej could you take a look at the code in the second commit (b622663) and see if the changes in it are acceptable to you? If they are I'd go ahead, squash the two commits and remove the extra SliderBar I added for the cycle in the first commit.
@sebageek I'm trying your latest branch (at b62266360888caa52f87fd71d61a7e67ceeb923c) but I don't see any animations in the quantize box like you apparently show in your screenshot.
Try the settings from the screenshot. Sync to internal, 120bpm, 32 8th/cycle and quantize cycle. Anything with sync to internal that results in a cycle longer than 1s should work though.
I'm confused because when I first start your branch fresh, it looks like:
I don't think I'm supposed to see that curr cycle box in the top right.
oh but it seems to work with those settings your provided me. Though I think now the curr. cycle box in the ttop right is no longer necessary since you got the quantize box working with animation.
I notice that on 120bpm, if I set 8th/cycle to 4.0 the display work, but if I reduce 8th/cycle to 3.0 then there is no animation. So maybe the reason I didn't animation before was because I just had the setting below 4.0 earlier.
As written in https://github.com/essej/sooperlooper/pull/26#issuecomment-947195358 I first wanted to ask if that API change looks right before I remove the other commit, but on the other hand... I can just prepare the commit in the way it's meant to be merged later.
I notice that on 120bpm, if I set 8th/cycle to 4.0 the display work, but if I reduce 8th/cycle to 3.0 then there is no animation.
Yes, there is a limit in the code here. I only display the status if the global cycle is >= 1s, as for less than a second it just creates visual noise and is not really helpful. If you want try it out! Just comment out that one if and it should give you a very fast animation. :)
ok.
I'm making a note that when on 60 bpm, I can set 8th/cycle to 2.0 and the animation works, but not if I reduce to 1.0.
Though if go down to 30 bpm, then 8ths cycle of 1.0 works.
I taught the
ChoiceBoxhow to draw a bar! The interface is far less sophisticated in comparison to theSliderBar(it only displays values between 0.0 and 1.0, no indicator and all of that), but it does the trick (I think in this case it even looks better without the indicator).
@essej could you take a look at the code in the second commit (b622663) and see if the changes in it are acceptable to you? If they are I'd go ahead, squash the two commits and remove the extra
SliderBarI added for the cycle in the first commit.
Very cool... go for it!
well I've commented out that if and see that the the bar looks more chaotic cause it updates the bar in seemingly random points of completion that it is hard to tell the bar is completing. I'm personally am not bothered by that noise when it is just in the quantize cycle box, though the green outline of the curr. cycle box is more distracting.
I'm noticing funny behavior which is a separate issue, but when I have tempo at 59 bpm or lower, then pressing the up/down control on the tempo box causes the number in 8th/cycle to double, thus easily reaching astronomical values. ...reported as new issue #30
Okay, squashed the commits and rewrote the commit message a bit so it reflects the current state + the ChoiceBox API change. I also tested this again with sync to Jack, where this feature doesn't work. That is most likely because sooperlooper just listens to the sync/start event on Jack. We could also display this cycle by measuring time between two sync events, but I think that is something for a future PR. I also write into the commit message that it only works with internal sync for now.
tried lastest out and look nice now.
(I'm just making an observation that the tap button seems to flash up to 239 bpm but at 240 bpm and above it doesn't flash...so seems that a similar decision to avoid chaotic visual noise faster than 4 updates a second went into that decision as well. And I'm guessing it would be very unusual anyway for people to use cycle quantize feature when cycle is less than 1 second)
@sebageek is global_cycle_pos controllable with osc messages ? It feels it should be, but I can't manage to do it. Edit: nevermind, I manage to add the missing controls but it doesn't quite fit my need (it doesn't affect the loops' playback position).
