Enhancements on the Scenes screen

[bigboipete]

I'm a drummer and I was very happy to find this app with the scenes feature on F-Droid. This feature makes Metronome outstanding, because as far as my search went, I couldn't find something similar.

Lately I started heavy testing under "real life conditions". But this is of course only my personal use case playing in a band. I use it to pick up the song tempo visually in advance, but not having the beat sound constantly on a headphone during playing. The ability to save fancy rhythm patterns in a scene is not my first choice. I use Metronome to have usually a 4/4th bar with different BPMs.

Here are some improvement suggestions, I came across. They all apply to the scenes view, which I used about 99% of the time:

1. Reduce the used space per scene on the scenes page. On my 5 inch mobile screen there can only be displayed six scenes (aka songs) at once (I think it won't be significantly more on a larger screen). In my case an average song-set for a show contains at least ten to twelve scenes/songs, ususally more. So it would be an improvement to see as much scenes as possible on the screen without limiting overall usability too much. First thing that comes to mind for space reduction is to remove the notes. Beat indictaion instead would be crucial to me.

2. Make the scenes manually sortable, not only by a sorting scheme like A-Z, Z-A, Tempo asc, Tempo desc. A "drag and drop" approach would be great to have the scenes in any individual order you want it.

3. Have dedicated space for the Start/Pause button. During rehearsal I often didn't hit the button exactly and thus selected another scene by accident. This was quite error prone, even though I consider myself on a good average level using touch-buttons...

4. Implying a dedicated space for the Start/Pause button, a Forward/Backward button would be another cool thing to advance in the "playlist" of scenes one by one. This would be awesome to have for an on-stage situation and even at rehearsals too.

5. Have a clear beat indication. The sliding blocks are looking good from a design perspective, but to my experience it's harder to visually pick up the tempo, as the grafics are a bit too "washy" to get it fast and precise. Preciving it via the given sound is not an option in a (my) band scenario, as the surrounding noise is far louder than any mobile device's speaker. Is there maybe a possibility to trigger the mobile device's LED? Or make the visual indication configurable to alternatively have just a solid colored block "flashing" on the screen (wich could also be displayed in the context of 3. and 4.).

As said this is just my personal use case and what I'd love to see as an enhancement. If you want me to split these suggestions to different issues let me know.

[thetwom]

Thanks a lot for sharing your experience. Currently, it's hard for me to do changes in short term, but I will definitely keep your suggestions in mind.

Let me give some quick answers to your issues:

1. As you say this is very specific to your personal use case. Of course one could think of an option for a compact view, but this again is very personal and having more options also quickly makes the ui more complicated. But I don't say it is not possible in a neat way. If you have good ideas, paste it here. Maybe we can come up with something nice, which is of general use ...
2. Drag and drop should actually work already. Try a long press on a scene and move it up or down. Sorting by a-z or tempo seems not so usable for me ... but maybe you can convince me otherwise. 3-4. We could think of reserving the bottom area for play/forward/backward of course. Up to now I thought, one could simply select the next scene manually, since this would be even more flexible ... but maybe for "production" it would be easier to hit a "next" button. On the other hand, a dedicated bottom area would take extra space ... . So let me know your thoughts here ...
3. Beat indication is a open question:
   • Flashing (camera) LED: I was thinking about this, but this requires permission of the camera of the phone which I decided not to ask for, since it is very confusing (why would a metronome need camera permissions)
   • Flashing status led: Unfortunately it is not convenient way to access the status led in time-accurately.
   • Having "just" a blinking block would make it hard to read the tempo for low speeds. That's why I use the current animation. For high speeds I understand that it is not as helpful. But maybe it is possible to find a way to improve the animation. Actually, the current way is my attempt to make the tempo as clear as possible, but it might fail doing it's job nicely. Maybe it could be improved by simple modifications. When I find some time, I will implement some ideas and ask for your opinion. What speeds are you talking about?

[bigboipete]

Thanks for your quick reply.

1. One additional thought on providing information on the Scenes screen is - again a bit personally biased -, that the Scene name is way smaller than the notes pattern. I would consider the name the most important information. So maybe this one is worth a (slight) improvement. This goes alongside with 3. of my initial post. If I can read the scene name without taking the device in my hands, just touching the next scene would be an option. Currently the font is too small at least for me, having the mobile device about ~80cm away. Regarding the display of the notes on Scenes screen, maybe a simple "notes on/off" toggle in the settings including some font-size adaptions under the hood will do.
2. Hell yeah! Drag & Drop is already there. Seems that I was too sloppy trying it.
3. From my expericene, if you just want to pick up a tempo visually, a blinking block is good for all, even slow tempi. I don't see any disadvantage with a flashing solid block. It might need some evaluation what's the best "on" and "off" time for the best perception. The speeds I use are not too extreme. They currently range from 60 to 204 BPMs and all in between.

[thetwom]

I uploaded here a test release: v3.2.1-alpha1

It uses a modified tick visualization. Note, that the animation changes at 120bpm. Please let me know how it works out for you. I also played around with the sizes in the scenes screen ... it might not be a final setting ... but maybe you could let me know if this would work better for you

[bigboipete]

Thanks for the fast response. How am I supposed to install this alpha? Any settings to change? I downloaded the apk, started the installation process, but finally I got the message, that the app is not installed. I'm running ShiftOS which is basically an AOSP 8.0.0 (in case this might be relevant). But so far all F-Droid apps worked fine...

[thetwom]

In theory it should just work the way you did it. It is possible though, that you have to uninstall previous versions first, since the signing keys of fdroid don't match the ones I use ... you will lose your currently saved scenes on uninstall, so make sure that you have exported them.

[bigboipete]

Got it! Unfortunately reimporting my scenes didn't work so far (without much effort...), but that's no big deal.

I think, I can explain now, why neither the recent beat visualisation (BV) nor the new "slow" BV works for me. I noticed especially with the new one, that I want to focus on one single point to pick up the beat. But there are two at both sides of the screen, which is somehow distracting, when you try to focus on just one.

And the old BV is too washy with this kind of "in-motion unsharpness" of the moving blocks to easily and precisely focus THE point where exactly the beat is (aka the blocks collide).

So, the new "fast" BV is by far the best solution for me, because I have one "point" to focus on. Of course everything is mitigated, if sound comes into play. My observations described above are a purely visual evaluation. Hope that gives you an idea...

[thetwom]

Thanks for the testing. Can you say, why reimporting the scenes didn't work? In theory there should not be an issue ...

I will try modifying the slow visualization, such that the bar disappears just in one direction ... I understand that the "fast" animation is good for fast speeds. But in my opinion for low speeds some extra info which visualizes when the click can be expected is helpful. Maybe in the end it turns out that it isn't ... would be good to have more opinions here ...

[bigboipete]

I think, that every kind of motion makes it a bit harder to focus on an on/off thing (which to me a visual metronome is), because you are forced to follow the motion - even if it's done unconscious. But although on a low level, that still eats "brain-resources".

That's why I'm not convinced, that there's a need to add some movement as support to pick up slow speeds. My personal perspective...

I didn't try hard with the re-import. I'll check that later and let you know. So far, I selected the txt file containing the scenes and they simply didn't appear in the app. No error or something.

[bigboipete]

Regarding the scenes import: The version info 3.2.0 in the file is not an issue, importing into an alpha version 3.2.1?

[thetwom]

no, it should not be an issue, up to now the version number is ignored. Can you reimport into the fdroid version? I really wonder, what is wrong here. If you file is not confidential, can you share it, so I can try?

[bigboipete]

It looks like the import from within the Metronome app doesn't work (via "load scenes from file"). If I select the txt file in the file explorer (Android built-in and Material Files app) import works fine.

Btw. is deleting scenes an all or nothing thing? How am I supposed to delete a single scene? I couldn't figure it out yet.

[thetwom]

this is strange, maybe I have to try if I broke something here ... can you try exporting some test and reimporting again, and if it doesn't work, can you share the file here?

Deleting a single scene works with swiping it to the left ...

[bigboipete]

Taken my success with drag and drop and deleting, I should work on my ability to predict the basic tapping/swiping actions. Thanks for the hint, I only tried it to the right.

[thetwom]

Maybe the current way isn't as intuitive as I thought it is :-)

[bigboipete]

Here we go: metronome_test.txt

[thetwom]

Thanks a lot. I will investigate shortly. Will also try a little bit with the visualization and let you know what I find out ...

[bigboipete]

I just noticed that the new "fast" BV has some hickups at fast speeds. It starts at around 143bpm but becomes obvious at 160bpm and faster.

[thetwom]

thanks for letting me know. I will have to see how/if things can be improved. At some point we are running into the limits of the android system which is not perfectly time accurate ... for sound this can be circumvented by mixing an audio stream, for visual feedback this is not as easy.

[bigboipete]

Sure there are limits. I don't want to nag, but also in terms of implementation and timing, isn't an on/off virtualisation easier to achieve beat-perfectly, instead of precisely firing an animation with that kind of real-time requirement?

I dug a bit deeper into these "hickups". They actually occur with all BPMs. It is harder to notice with sound on, but they are there. For the "slow" BV focus on how the bar slides back from the sides. As far as I perceived it, it's often every 3rd or 5th beat. I tested only on a 4/4th bar, just in case this affects the issue.

Additionally I think the sound output is correct. So, as you said the visual side might me the harder thing to implement time-perfect.

[thetwom]

can you try if the problems is the same on the "main" window?

I am open to end up with a simple "blinking" bar if it makes most sense. I will try and experience myself a little bit more... .unfortunately there is not so much time, so all this might take a while ... first I have to find this problem with loading scenes ... it might be a problem with updated libraries I am using ...

[bigboipete]

Yes, it's the same BV issue on "main" and "scenes" view.

[thetwom]

OK, thanks.

Regarding the scene loading issue, I have the feeling it is related to "Material Files". Actually, I can reproduce the issue with "Material Files" installed. If I deinstall it, everything works fine. Could you try deinstalling Material Files and then loading files?

[bigboipete]

To be honest, I'm not so happy when it comes to uninstalling and reinstalling apps on my device, because I use it every day "in production". I usually take care to keep it as clean as possible in terms of installations. It's not a dedicated test-device. But it's on my list and of course I'll let you know my observations, if I do decide to test the "Material Files" issue. I hope, this is fine for you.

[thetwom]

Could you try this release: v3.2.1-alpha2

This should resolve the issue you mentioned in the other thread and uses now a blinking animation for all speeds. I tested it for me but the result does not seem to be very convincing. Maybe the bar is just too wide and I should transform it to a small dot, so that the eye just has to focus on one point? I also have the feeling that the timing is still not good.

[bigboipete]

You're right, unfortunately the timing of the bar is still not precise.

I'm not too much into app programming, but it seems that the bar is still an animation that quickly fades in. My guess would be, that a straight on/off is the simpler mechanism from an implementation perspective, which could react faster and more precise? I don't think the bar itself would be the problem, compared to a dot.

Actually there are two animations. It's the pulsating note and the fading-in bar. I would expect that the system could get even more in trouble to fire two animations, which both are supposed to be super time-accurate.

I don't want to spoil your whole visual concept, but my assumption would be, that removing all animations, would improve time accuracy. But that's completely unevaluated and a simple best guess, from what I know from programming.

[thetwom]

My strong guess for the inaccuracy is not that the system has to do too much work due to animation, but that threads are not perfectly synchronized. The audio is played a separate thread and when a click occurs, it calls the ui-thread to draw the animation. Unfortunately, there is no guarantee, that the ui-thread wakes up in time. It is even possible, that without animation it becomes worse since the ui-thread has not enough work to do and goes to sleep :-) and such takes longer to wake up.

But still, your reasoning appears straight forward and it is worth a try to switch of all animations (especially since this can easily be done). Please see v3.2.1-alpha3 for a version without animation.

I did change the tick visualization again, to avoid the fade out. Just having a short on and off does not work out nicely since you (or at least this was my observation) will see two clicks: One when the bar switches on and one when the bar switches off. The "new" animation circumvents this problem.

Unfortunately, a very quick test from my side shows, that this version is not better. If you agree that it is still not good, I will have to think if there are ways to somehow improve the behavior, but unfortunately this is no quick and easy change ...

[bigboipete]

First of all thank you very much for all your efforts!!!

As said, I have no clue about app programming and I do not know what is technically covered by the term "animation" on code level in the Android environment. The picture I have in mind (which could be totaly different for Android) is technically a CSS-like approach, like just switching a given rectangle from colored (opaque) to transparent and back. Would that also be an animation in Android?

Having "my" approach in mind, I can't imagine how these "two clicks" could occur. But again, I live in a different universe regarding my developer skills and so, my thoughts could easily be just complete nonsense when it comes to Android. If you've got the patience, I'd be very interested in some Android insights to understand, what's happening under the hood.

I don't know if I'll find the time today, but I'll test the alpha3 version tomorrow at the latest.

[thetwom]

... If you've got the patience ... -> no problem here for me, it just might take some time for me to answer sometimes :-)

"animation" -> sorry for using such a term without explaining. "Animation" in android means mostly gradual changes of appearance (e.g. moving rectangles, shrinking rectangles, changing color with time, changing transparency with time, ...)

So switching something on or off is normally not an animation.

The "two clicks" are not about programming, but about appearance. If the colored rectangle suddenly appears, it will make you "feel" a click. But if it disappears it also makes you feel a click. So if I switch on the green bar and after 0.1s switch it of again, it gives an undefined feeling -> is the click when it is switching on or when it is switching off? Or are there two clicks.

However, if you look at alpha3, in Android terms it doesn't use animation, but switches on and off two rectangles. I named it "animation" in my previous post, so technically this was incorrect.

[bigboipete]

Thanks for the explanation. I'm quite curious how the new visualisation looks like.

From what you are writing, it seems like now it's about optimizing on- and off-times. And in case the "off"-click keeps being somehow distracting, you could keep the block "on" for the duration of one beat and leave it "off" for the next and so on. I can't recall how this was solved on my old crappy Metronome device, but I'll check that, too.

But I guess, I have to have a look at the alpha3 first, before talking about it...

[bigboipete]

I had a look at the alpha3 and in my opinion these blocks are the best approach yet. Timing is still not accurate, as you wrote.

I did a micro-research on the keywords "android time based visual changes" and came across an article on developer.android.com, that identifies the RecyclerView (among others) as a likely source of dropped frames. This is at least somehow used in the ScenesFragment class. I don't know, whether this is a new and hopefully valuable information for you, but I thought I'll let you know anyway.

[thetwom]

Thanks for the research. It's an interesting article, but very unlikely, that it describes the cause. I strongly guess on thread synchronization, but there might be ways to improve the situation. However, it might take some time, since it is not trivial and my time is a little bit limited :-).

[thetwom]

hi, I am ready to do a bit more testing about the visualization. I created a simple test app. Maybe you can try it and give feedback if the visualization is more accurate TickVis. Not sure, if this really improves the situation, but it's the logical start ...

[thetwom]

I merged also some changes into v.4.0.0 which is already available on fdroid an play. Let me know, if this version improves the situation.

[brilnius]

Hello. To give a very quick (and late) feedback on this subject:

• The "scenes" feature is a very very good idea. :-D
• I also didn't know it was possible to reorder scenes manually (using long press), it was precisely a feature I wanted to suggest :-)
• I also don't need the notes preview. Maybe this can be hidden when there is only one note? This would free some space (for more scenes or bigger names/tempi). But personally I have no problem with the notes preview by itself and the number of displayed scenes.
• I'm also a drummer, I put my phone on the floor and for the time being I can read the scene names. But with age maybe slightly bigger names would help. :-)
• I have the same issue of selecting a scene when I just want to click play/pause. Maybe a bigger button would help.
• I also think a "next" button would be useful. Usually between two songs you don't want to make other people wait for you. A "next button" would be quicker than: figure out again where is the currently selected scene, maybe scroll down, and then click and the next one.

My 2 cents.

[thetwom]

Thanks for the suggestions:

• Bigger play/next/previous could effectively solved by a bottom bar, but this will of course reduce the space of visible scenes. But maybe it is worth the space
• I am still not convinced about a more compact view :-). I guess removing the notes completely would not be good for many people, so we would need an additional option. And too many options make the settings even more crowded ... not so easy decision :-)
• The recent versions already have slightly increased fonts ... not sure if increasing them even more at some place makes things looking not the way one would expect it ...

[thetwom]

Please check v4.2.0-beta1 for some enhanced player controls. There might be some room for improvement, but it should already pretty much do the job ... I would be glad to get some feedback ...

[bigboipete]

This is a major improvement compared to the last version I installed and checked. Thanks for putting so much effort into the app!

Visualisation seems precise at first glance, but I'll check that later today with my band.

Here are my suggestions for some micro improvements:

Given the available space in the scenes screen the font for scene names could be even bigger without taking space away from other elements.

After importing my set of scenes and switching to the scenes screen no scene was selected and so still the initial settings were applied. That was a bit confusing at first (but another reason might be, that I wasn't sure what to expect as indication for a selected scene in light mode). It might be more intuitive to default to the first (or maybe last used) scene when switching to the scenes screen. Maybe...

Another formal thing are the skip-buttons. The ones you use are ususally fast-forward/fast-backward and not skip-next/-back, which would be this one.

Btw. import from within the app still doesn't work. I don't know, if it should yet...

[bigboipete]

Just came accross one more:

Maybe my thumb is a bit more awry than others, but when scrolling the scenes screen I switch quite easily to the main screen. Is this scroll/switching behavior adjustable?

Precisely it's the case, if I want to scroll a long way up to the top of the list without letting it go (using the left hand for scrolling and holding the device). I touch the screen at a rather high position and the thumb has a good part of movement in the horizontal axis at start. This decreases when moving further down. But I think the initial direction might be a bit to much to detect the intention correctly. But maybe I just need some lessons on my touch-skills...

[thetwom]

Thanks a lot for testing:

• The problem with the space to the other elements is that there the note visualization takes up some space for being able to display triple note brackets ... I guess I will put some thought of saving space in future ...
• If your current metronome settings don't match any scene, no scene will be selected. Meaning, that when you import scenes, none of the scene will be directly selected ... but maybe I understood your description not correctly?
• You are right about the skip buttons. I will definitely correct this.
• Import still seems to be a problem of material files, I did not investigate further, but I fear, I cannot change this easily.
• I will check if it is possible to introduce an extra resistance when scrolling ...

[bigboipete]

About the import/scene thing: The current implementation might be intuitive, in case you are switching from main screen to the scenes screen while playing main screen's settings .

But as soon as the metronome is not running and you switch to scenes, I think it's quite likely, that the user wants to use a scene. So, my personal expectation would be, that e.g. the first (or last used) scene is selected and if I hit play the scene's settings will be taken into account instead of the main screen's.

Regarding font size of scene names andyour concerns about the cluttered settings for the option to display the notes or not, I wonder why the setting for min an max speed is necessary? Isn't this something that is generally determined by the system or differ the possible speeds between devices? Do you know about extreme cases (like 1.000BPM max) that would be an issue for a device? For me this setting is not at all crucial and could easily hard-coded under the hood without loosing convenience. Leaving this away provides enough space in the settings for notes on/off.

In that context, I checked the vibration feature and noticed that (at least with vibration on and sound off) visualisation and vibration is still not exact. Vibration is more obvious...

[thetwom]

• Since selecting a scene will discard your current settings, it would be quite dangerous to autoselect a scene when switching there. One could of course argue that when pressing "play" in the scenes view, one expects to play the first scene. But also here it would be dangerous to automatically discard the current settings. One could hide the player controls, when no scene is selected, but this is limiting functionality (e.g. you cannot stop the metronome playing while in scenes mode). Spontaneously, I have no good idea to make things consistent and intuitive here ...
• min/max is a bit historic ... but especially for the min value it makes sense to limit it to something reasonable, in order to avoid accidently chosen small values (this would end up in very long tick durations which could be a bit annoying for the users). On the other hand, you never know how users are using the app, so maybe there are people around who need bpms like 1 ... . So the option is to give the users control of what they do. The scenes appearance seems very specific to few users and currently I am not sure if this can be implemented without too much overhead of code (just hiding the notes is not enough to really save space, we would have to move the speed e.g. to the right, next to the title). But I will have a second look, if this is somehow possible ...
• If I understand you correctly your are saying that most probably, vibration is not exact but visualization might be fine. I tried around here a bit, but could find no way for a more precise control of vibration. In principle, you call "vibrate()", at the right time, but then android might not respond immediately ...

[bigboipete]

Min/max BPM: Concerning "accidently chosen small values", I wonder how accidently this could be? In the main screen the BPMs are displayed quite prominent (in scenes it's smaller but should be sufficient). So this is displayed at all times. And after trying, I also found the hard-coded upper limit of 10.000BPMs. So this setting seems a bit redundant to me... but that's as always just my personal perspective.

Vibration/Visualisation: As soon as I turned on vibration it went together with visualisation straight into these small hickups (like described on May 29th), checked at an average tempo around 130BPM. Visualisation only seems to be clearly more precise, as far as I observed it by now.

[thetwom]

min/max BPM: yes I think it's about taste, so lets agree that you would favor a compact mode for the scenes :-).

vibration/visualisation: It's strange, that vibration seems to affect also the visualization since they run on different threads. And visualization is now only loosely coupled to the sound, so even if there is lagging on the player, the visualization continues. Unfortunately I am a bit out of ideas on how to improve the situation.

[thetwom]

If you find time please check v4.3.0-beta1

In the settings you will find the option "compact scenes layout". Let me know if this helps.

[bigboipete]

Yes, this is definitely what I was looking for. Thanks for that adaption. That's all information I need in my universe.

I don't know if this would be as easy to achieve as it looks like, but here's a simple layout-suggestion for making full use of the freed space: .

[thetwom]

sure, such a thing is possible :-). It comes at the cost of the shorter titles and its harder to hit the correct scene. .. but we could give it a try ...

[thetwom]

here a new beta v4.3.0-beta2

I did not yet change the numbering style, but I like the idea of just number with point ....

[bigboipete]

After extensive usage of the current Toc2 beta during two days of rehearsal, the scenes layout is nearly perfect from my point of view.

For me the only thing to maybe adjust once more is the row-height of the scenes and the play/skip buttons. When it got bustling, I sometimes missed the button area or the right scene (given the usage described in my second entry).

[thetwom]

Thanks for the feedback. I will look into increasing the rows heights slightly, when I find some time.

[thetwom]

I am wondering, if I ever addressed the issue of the row heights. Maybe you could revisit the current status.