Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add setting to copy loop flags on loop create #27

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

sebageek
Copy link
Contributor

A new setting now controls if a newly created loop inherits all flags
from the previous loop (sync, play sync, feedback play, tempo stretch,
discrete prefader). This is a gui-only implementation. The MainPanel
class has an extra counter to track when this instance of slgui has
created a panel, to then copy the values over. This was done to not
interfere with other sooperlooper clients that might not wish the values
to be copied.


I didn't want to re-click all the sync-flags for each loop whenever I added a new loop (also I forgot to do that many times and wondered why my new loops suddenly behaved differently, a complete mystery™), so here's a flag to just do that! In my first draft I tried to implement that in MainPanel::do_add_loop(), but it didn't work. I presume the loops were not ready yet in the server and thus my set-commands were discarded, though I didn't investigate this any further. I then went ahead with implementing it in MainPanel::init_loopers(). I hope the update-commands are not blocking the GUI loop or anything, but in my tests it felt smooth enough.

I saw this feature was discussed in the sooperlooper forum, so @ericfont maybe this might be interesting to you as well. It's not a "remember default settings" implementation, only a "copy from last loop", but still might do the trick.

@@ -195,6 +197,8 @@ void LatencyPanel::init()
_slider_mousewheel_check = new wxCheckBox(this, ID_SliderMousewheelCheck, wxT("Allow mouse scroll wheel to change sliders"));
topsizer->Add(_slider_mousewheel_check, 0, wxALL, 3);

_copy_loop_values_on_create_check = new wxCheckBox(this, ID_CopyLoopValuesOnCreateCheck, wxT("Copy loop flags from last loop when cerating a new one"));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo: "cerating" -> "creating"

@ericfont
Copy link
Contributor

tried out. My only qualm is I sortof want to have the last setting be remembered when I delete all loops as well, cause often I delete all loops when clearing slate.

A new setting now controls if a newly created loop inherits all flags
from the previous loop (sync, play sync, feedback play, tempo stretch,
discrete prefader). This is a gui-only implementation. The MainPanel
class has an extra counter to track when this instance of slgui has
created a panel, to then copy the values over. This was done to not
interfere with other sooperlooper clients that might not wish the values
to be copied.
@sebageek sebageek force-pushed the copy-last-loop-config-on-loop-create branch from e52b240 to 018fa32 Compare October 16, 2021 20:18
@ericfont
Copy link
Contributor

Your PR seems to work as described. I guess the question is does this seem like something that other people will find useful enough to have in the codebase?

As I was looking over this PR, I sortof realized a very simple personal solution for my personal need of always having the sync button enabled when creating new loop for me would be simply hardcoding my preference in the init function (ericfont@3015648). So with that I don't even know if I would use this PR's feature.

So I guess if other people would find this PR useful then add it, but if I would be the only end-user then don't bother.

@sebageek
Copy link
Contributor Author

I would use this! ;) And yeah, your fix should do what you want, though I was looking for a solution that would generally be acceptable for the sooperlooper codebase. So yes, the feature implemented here is specifically "copy loop settings from last loop".

For your use-case... I'd say it depends. What I could do to further enhance my PR to support your case would be to save the settings of the loop to a variable when the last loop is deleted, and then on first-loop-create we re-add those settings. This would require you to set the correct settings once on the first loop when you start slgui.

Another option - probably as a separate feature - would be to just add 5 checkboxes (maybe in one row) in the preferences, each one allowing to set a default for one of the five loop flags. This would also be saved between restarts. But that would then do something completely different as what I have already implemented (which is probably fine and would also support my use-case).

@ericfont
Copy link
Contributor

ericfont commented Oct 17, 2021

ok good to know at least two people would find this PR useful.

Regarding my use case, I like your last suggestion:

add 5 checkboxes (maybe in one row) in the preferences, each one allowing to set a default for one of the five loop flags. This would also be saved between restarts.

I'm wondering if also every single per-loop setting could benefit from being able to configure a default setting. I'm wondering maybe the simplest way to avoid cluttering the preferences window would be to add to the right-click menu for each loop control an option "save as default". I'm noticing there is already an option in the right-click menu to "set to default" for "in gain", "thresh", "feedb", "in mon", "pan 1", "pan 2", "out", "pos", "rate", "pitch", "stretch", and so a "save as default" option in that right-click menu would pair nicely. (and maybe even the "main in", "sync", "play sync", "p feedb", "prefader", "t. stretch" checkboxes could also get the "set to default"). That way might reduce the amount of extra code for each particular button, cause then could just have the code for the base-class which is inherited by all these controls regardless. I guess I might make this as a separate PR and see what people think. (Update: I've spun this off as feature request #29)

@essej
Copy link
Owner

essej commented Jul 4, 2022

Hey, sorry I haven't been keeping up with these PRs! I think I like Eric's idea about having a quick way to save the parameters as the default.

As for this PR, I think instead of making it a setting, making it a new session menu command Duplicate Selected Loop would be a bit more powerful. Instead of just the last loop, it would be the (last) selected loop (if there was one), and then it wouldn't conflict with the Add Custom Loop command.

@davidmcnabnz
Copy link

Just noting that this PR, when downloaded as a patch, is working fine when applied to current code (as at 2023-11-05, commit c5e22ce). I'd recommend bringing the PR up to date with main head.

That -- and thanks for your effort in creating it. It's been annoying to always have to click on checkboxes with each loop. Not practical for real time playing.

@luzpaz
Copy link

luzpaz commented Dec 6, 2023

Can this be rebased ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants