@wyleu @MrBroccoli Can you describe the steps to trigger the issue?
just ran update with repositories set to testing.
after rebooting i get the red error message on the screen and that in the logs. it no worky now!
Simple as above.
Hmmm⌠I might need a test monkey. I develop on a Zynthian 3 and test on a Zynthian 4. I did the PR from my Zynthian 3. @jofemodo merged the PR then I updated my Zynthian 4 and it worked. It is of course possible that I had done some work on the Z4 at some time that tweaked it to not show this error. I can see it is in the code that handles menus. I will take a look-see.
The issue is with Enable Touch Widgets. I was porting the menu handling code to the base class but that work looks incomplete, not working when touch widgets are enabled. You may disable this to get things working whilst I fix the code to allow it to be re-enabled.
@jofemodo you may decide to wait for a day or so before changing anything, leaving Testing branch partially broken whilst I fix this or you may wish to revert Testing until this is fixed. Your decision may be influenced by whether you want the refactoring of menu handling to be in a separate branch which in turn may be influenced by your opinion on this work.
1 Like
Enable Touch Widgets is now working in Testing.
Yes that works.
Hadnât realised how much I used the on screen buttons.
Any ideas on which encoder action will hot switch to the mixer ?
and how does the audio recorder appear?
âEnable Onscreen Buttonsâ is the option you refer to which differs from âEnable Touch Widgetsâ which was the one with the issue. The former shows buttons at the bottom of the screen. The latter enables some GUI widgets, e.g. in menus and parameter editors.
There needs to be a top-down consideration of best use of shortcuts. I anticipate the mixer becoming part of a new workflow / layout which presents engines and their interconnects graphically but such an aspiration requires consideration from the gods. Your comment did make me realise that I had not added CUIA actions for the audio mixer which I am doing now and will update you once it has been through QA and merged.
What do you mean? The audio recorder has not changed. Are you suggesting a feature enhancement? (You know where to go with that!)
No i was wondering how itâs integrated into the audio mixer.
Currently the output of the mixer feeds the audio recorder. The audio player feeds main output direct. I guess it would be nice to be able to feed the player back into a mixer channel and / or with the ability to send direct to output to allow incidental music to be played between performances. Sounds like a feature request to me!
Add Audio Recorder output as a source in zynmixer ¡ Issue #553 ¡ zynthian/zynthian-issue-tracking ¡ GitHub brief or what . . .
Ok I am running now.
You have saved me a midi channel⌠i was routing the output of all my channels to a master channel on 15. Thats probably a good thing, Also, I now have at least 3 places to change the volume on my inputs⌠the physical pots on the sound card interface, the gain plugin that i used as a dummy for my input channels (iâm sure there will be another way?) and now the mixer too⌠getting closer to 11 all the time!!!
I think i will leave it a little while before feature requesting though, seen as you have done such a good job.
Feature requests and bug reports welcome. Letâs make this the best it can be. You can see issues already reported (and triaged) that relate to ZynMixer here.
I like the delineation of mixer functionality and zynthian modes on the left and right of the screen.
Very initiative.
Nice when driven
Enable LV2-plugins on webconfâŚ? not sure what Iâm being asked there.
Should I have loaded up some lv2 module(s) that is stitching this all together? Or do I load from here?
One can select a subset ( and possibly a superset with audio recorder) of layer objects to display.
How do these default?
Do I need to rebuild the layers from scratch? ( reload my stepping out snapshot 
) which is holding up very well under all this movement.
LastlyâŚ
How did Broccoli do the red bar?
You are bouncing between rapidly developing codeâŚ
@wyleu has found the menu (which I was going to mention once it was working - I made it work then @jofemodo changed (improved?) behaviour so it continues to be developed). The menu was there to allow access to the core zynthian features like adding engines. The version you are running is flawed in that only the synth engines work. (I fixed that in the development but I may have mentioned that is now void!) The version @MrBroccoli shows is one that changed the behaviour of the channel selection indication. That has subsequently changed in development. We are still working on the development branch so give us a few days to settle things down.
All layers are shown consecutively up to the maximum width, e.g. if your screen can show 4 channels and you have configured 1, 2, 4, 9, 10 &12 then initially channels 1, 2,4 & 9 are shown. Horizontal scrolling will reveal 2, 4, 9 & 10, etc. Missing layers are not displayed, i.e. we donât show 1, 2, 3, 4, etc. to conserve space. We want as many useful channels to be shown, not a swathe of empty ones. (This has the side effect of moving things around if you insert or remove layers.) The zoom level is dependant on screen resolution. A standard kit will show 8 channel strips and the main mix bus strip.
Regarding the red bar⌠Initially we had a rather (too) subtle border around the channel stripâs index at the bottom of the screen as can be seen by early images in this thread. A modification was done to change the fader to the highlight colour as shown in @MrBroccoliâs image. I worried this was too much (massive bright red fader - warning Will Robinson!!!) and also too little (fader closed = no indication of selected channel) so I propose changing the background of the strip at the bottom behind the channel index like this:
We need something that is obvious on a small screen whilst avoiding interfering with user workflow, e.g. distracting from function.
You can look forward to an update soon, once @jofemodo and I stop squabbling 
.
Excellent!
Should the Title say Mixer: Current Snapshot name.?
Iâve got it on two machines, the Pi3 with the SPI fixation and the 1820 touchscreen thing seems ok for most things. It will be interesting to see viable it is on 4 encoders and a mis sized, read only screen.
Border versus fill, somewhere between the two of them⌠Itâs not an issue if you are brave enough to go fro the first touch and see it change,
Perhaps it should include the whole channel column as that is the active area for the press and also defines the object you are currently editing?
Now this is the 
we wish to see.
Touchscreen is less of an issue - we donât need to identify the selected channel because you will be touching the one you want. The first touch on the fader does nothing. It moves relative to your movement, not absolute.
Channel selection indication is for non-touch operation which is the prime UI we design for and hence must and will work fully and be as intuitive as we can make it. We also target the 3.5" screen as our primary display as this is the official kit format. The problem with filling the fader strip background is the same as with filling the fader, if the fader is fully open you have no indication of selected channel.
The layer provides an overall output level and this is then mixed down by a the mixer component ( is this an lv2 thingy?) not operating over control signals sent to the layer?
Presumably we will allow a fader to be allocated to a MIDI CC as per layer volume? This might be start to be held up by our one to one mapping of ccâs to functions as existing layer configs are brought up to date.
The mixer is a core zynthian module implemented as a shared library. It is not implemented as an LV2 plugin. I think this makes more sense as it becomes part of the zynthian host application rather than something that can be fiddled with and broken!
There is a plan to allow MIDI learn in the mixer to allow control of any / all parameters from external MIDI controller. It would be good to have some templates for known controllers but that might be a future development. Once we have the core functionality working (which is mostly there) we can add the MIDI control. OSC control is already implemented and there is an Android app and config already available that gives full control of the ZynMixer.