[Edit] In practice we are likely to not implement the controller but just the view and model. This is because the zynthian is effectively an embedded device with single viewport. There is no need to complicate it with a controller layer that manages windows, etc. So we plan a more simple view / model design. The model is managed by the state manager whilst the view is managed by zyngui. When we introduced state manager about a year ago, we did a lot of the work to separate the parts but that was not the actual goal of that development so it was not complete. We hope to finish that seperation soon to facilitate a more robust and complete API. The current API is rather tied into the UI and we plan provide similar API seperation: model / view. So - we aim for “MV” design and the “C” (or “P” ) may be ignored. (Well, it is incorporated in the View part.)
[Edit] But you might consider zyngui as the controller and all other screens as the views so maybe it is more MVC… but who really cares???
The footswitch capabilities are a welcome addition! My feedback is the same as Joe’s, above. It would be nice too if more of the functionality was available as the soft buttons don’t seem to do anything.
I’ve been playing with it a bit, and my biggest problem is actually having to go back to the looper screen to operate it. My typical workflow with a loop pedal is to record a loop on one instrument, and then add layers/tracks on other instruments. So, as I’m changing instruments with zs3s, I’m constantly going back to the mixer view and have to get back to sooperlooper from there.
For my use personal use case, I would love to see a reduced SL GUI shown on the mixer screen so that instrument changes, loop activation, selection, position and status can all be seen in one place. I personally need to see that a loop is playing/recording/overdubbing, and approximately where I am in the loop. It wouldn’t need to have a lot of controls.
Tracks 1 and 2 are playing, track 3 is recording. I would envision changing the active track with CC changes, and the single pedal functionality would work for the selected track. The SL button on the right would take you to the main sooperlooper screen to make settings changes. There would probably be some setting there that would enable or disable this view on the mixer screen.
If I had this, I could sell my looper and buy more pizza!
I set up a bunch of instruments in omni mode and then change the midi out channel on the keyboard I’m using. Then I don’t have to exit sooperlooper at all.
That’s even easier: no need to switch to them. Although you may want to mute those mics when you’re not using them. Which can be midi-learned, if you have a device capable of sending CCs.
Hmmm, I’ll have to play with around with it. I use different effects chains on the melodica, sometimes pitchshifters, sometimes delays and reverbs etc. I guess I could setup to mute each chain instead of changing with zs3s, I’ll give it a try…
I was writing a long story about something complete obsolete now
Yeah i guess that the Baggypant/Niels combo is the way to go. I have a nanokontrol - easy to mute mics and other audio sources there. I 'm a home-looper with bass and acoustic piano
There are currently two controls in sooperlooper to switch the selected loop:
One letting you select loop 1 to the number of loops
One prev/next, acting on 0 versus 127 of a CC value (I think, or its decrementing/incrementing, not behind my setup right now).
Both of them are problematic with my hardware.
For the first selector, encoders or faders are too crude to be certain which loop you selected.
For the second one, none of my devices seem capable of just sending 127 OR just sending 0. It always comes in pairs (whether momentary or latch).
Having a control that just moves you to the next loop on 127 (and ignores the rest) and cycles back to the first loop at the end would let you use a single pedal or CC button to switch loops.
Now, having three controls for effectively the same thing seems like utter overkill to me, so my question is: how do you people switch loops, and what do you think of this imaginary next/cycle control?
Actually - this doesn’t work well for me because I’m using pianoteq mostly, because the sounds are so superior to everything else. I use the piano, rhodes and clav, and since it’s a single chain I use zs3s to switch presets.
I realize this is probably an edge case, but it’s my primary use case…
Ah, well. I had one controller for the sooperlooper and another for playing, so I could trigger z3s on the chain midi channel with program changes from the keyboard. That made it easier.
Some really good discussion and feedback here. I have implemented some of these suggestions:
There is a new CC relative mode 4 which will nudge a control down when value < 64 and nudge up when >= 64. There is no acceleration in this mode.
In the “Control options” menu you can now explicitly set the CC mode.
Sooperlooper “prev/next” control is now “next loop” and wraps at end of range.
Some of you who have used the prev/next may need to change your config. This can now be implemented by configuring the “selected loop” control to MIDI CC mode 4. Other users can now use a normal CC pedal (e.g. sustain pedal) to control the “next loop” control. I did not implement an up/down from different pedals which may require more controllers - I didn’t want to expand the quantity of controllers at this time and there may be a different / better way to do it if it is required.
These changes are in testing (vangelis) branch.
This is an interesting idea. Your mockup looks good but how well would this scale, e.g. what happens if there is one or 6 loops? We may also want to see other things in the mixer view. (We need some flood gates to avoid being inundated with requests to show this, that, etc…) We are getting into the realm of expandable frames but, maybe we could consider some screen space available to show custom widgets in mixer view (similar to how we do the custom widgets in the control view). This might best be considered in the discussion on UI changes where we have discussed showing a more graphical chain layout.
There are 12 buttons at the top of the SooperLooper control view custom widget which should operate SooperLooper, offering touchscreen control. Some recent changes may have broken this. There is a state model where the previous, current and next states are relevant to operation and I think this got missed during some refactoring. We need to revisit this.
@niels will you please merge the changes back into your PR and then I will try to find time to review it.
I was able to do this because of the other change that allows the previous behaviour to be mapped to the selected loop control. There is a small constraint introduced in that a user can not use both absolute and relative CC binding for the selected loop so must choose but it seems unlikely that users will want / need both.
I just tested and these buttons are operating as expected. You must understand how SooperLooper works for them to make sense but they appear to behave correctly, e.g. “record” will toggle record and “replace” will indicate that the loop will play until the next sync point and then start replacing the audio. These operate on the selected loop. An orange loop shows that there is a pending action and a flashing button indicates what the next action will be. A small flaw or restriction that for some controls, once you have requested a next action you cannot press the button again to cancel that. This should be implemented or explained. (Feature request anyone???)
[Edit] Ah! They work with a mouse over VNC but not with touch. I will look at that… especially if someone raises a bug report.
Not exactly. If an action can be toggled then pressing its button again will disable the request but there are some actions that don’t behave this way, e.g. multiply, replace, etc. Undo will not affect these buttons in the same way as pressing the button again does not. I don’t recall why this is the case and it may be a bug.
A lot of the GUI is too small on a 3.5" screen. Touch is only really supported with a stylys on that size screen. Using a stylus makes it really very accessible - more so than fingers on a 5" screen.
I have fixed this in testing (vangelis). The problem was that zynthian’s multitouch driver was intercepting the touchscreen events and not triggering the button events. Solution is to bind the buttons’ release events to the event handler (plus some tweaks of course because nothing is easy… although this wasn’t too difficult).
Thanks @Baggypants and @niels for your suggestions, perhaps I can reconfig my controllers (or make a new one) to better fit my workflow. I don’t think I can get around the single pianoteq chain with multiple presets problem though. I also use a few noizemaker presets but that one is lightweight enough to have multiple chains. Some of the other heavy lift synths would share the pianoteq problem (Odin for instance)
@riban I will add to the UI/UX thread after I experiment more if it still seems like a good idea.
