Miscellaneous Interface Issues

[shibetpc]

To start with, it blows my mind that musicians that have a chance to use this app, after someone else has done all the heavy lifting, would just give up on it. 

Ha! Sisyphus didn't have as much heavy lifting....

I've been struggling with this for some time now.  I am not a novice user.  I'm technically adept, been around this stuff for most of my life, have worked in the industry.   I utilize this type of technology in every aspect of my life.  I am an early adopter of many technologies, and am not afraid to spend many hours working toward understanding tech that may be a benefit to me (I've clocked a ridiculous amount on this one). 

That being said, I am continually stymied by BandHelper.  This will be the 3rd season I've attempted to transition over to BandHelper from any number of other song management apps, and already its looking as if this attempt will fail.  Each time it becomes more and more difficult to convince others that the app will work...myself included. It will fail because it is a nightmare to use in a live and realistic environment, and is unintuitive in every aspect.  It goes against all the expectations that users have when using an app, and responds differently depending on the device it is deployed on.   NOTHING about the layouts and navigation are intuitive. Even custom layouts are unintuitive because of the constraints they put on a user.

Here are some examples:

:: want to play a song > open Songs > NOPE...you have to access a song from a setlist.  The Song 'feature' is only to populate information.  Ok.  Opens Setlist.  Oh, that song isn't on a setlist? You'll have to use a smart list and find it.  How is that easier than just opening it from Songs? The workflow presumes that a gig is comprised of predetermined set of songs.  It is not necessarily so, (never in my case) and is inhibitive.
:: open a song in setlist > play song > press back button to return to list of songs > NOPE...that takes you out of the setlist all together and dumps you into a muddled view of layouts.  that's not at all intuitive.  In a gig when seconds between songs count, this is important.  I still do this ALL THE TIME despite being aware that this is how it works.  Mobile app navigation isn't up for grabs.  There are established User Experience expectations.  This app defies these EVERYWHERE.
:: Turn view from horizontal to vertical, and view disappears...sometimes...on certain devices.  Sometimes the view fails to fill the screen.
:: Create a custom layout on my android tablet (a layout which comprised of data I want to see when I open ANY device I use) > Opens iPad > no custom layout.  Has to recreate the same layout for each device.  IN TWO ORIENTATIONS!!!
:: Song starts scrolling  > You play it a bit faster or slower based on the crowd > There is no function to increase or decrease speed.  You drag the screen, and the scrolling feature bugs out and jumps to the top causing you to lose your place.
:: Band mate sees interface and asks if they can change the horrible blocky font.  NOPE. can't change that.  Why? Standard sans-serif please...
:: Transpose a song just for me?  Yup.  But if doesn't really.  It creates a new and independent copy of the song.  So if someone changes the master version you don't get the update.  Well, once again, not at all intuitive.
:: Open a menu, make a selection, have menu disappear.... NOPE  let's divide the already limited screen space until you can't read the column of data you are trying to edit.
:: Custom Layouts require a separate view for each orientation.  Why not just recognize changes or customizations to layouts in each orientation, and save it as a single custom layout?  NOPE.  Instead, if you don't create a custom layout for each orientation, you will get a blank screen, OR default to another view in that orientation.  A result which is both unintutive and inconsistent. 

Overall, this feels like a very Beta experience.  Yet, I'm paying for it. 

It seems that the interface and experience was designed to serve the functionality, and not the user.  For example, why do i need to input the duration of each of the 400 songs I have loaded?  Not because I want to or because I need that information,  but because it serves the purpose of the scrolling 'feature'.  If the scroll speed relies on a relationship between duration and font/screen size, why not just assign a duration (default or input by user) behind the scenes and give users ability to increase/decrease scroll speed on the spot. The increase/decrease scroll speed function buttons would increase/decrease the duration by % or by some increment, and the new duration changed behind the scenes.  That serves the users need.  Instead, BandHelper has taken an approach which makes no sense at all.  Spend hours prepopulating the data of duration time (which you would otherwise NEVER do, and STILL don't have the ability to make an adjustment on the spot.  That's poor design.  Your insides are on the outside.  As a user, I want to control scroll speed, not time out my songs.

I'm not meaning to come down on Arlo, but its not like this is a free app and this is being done as a favour.  It is a business, and he provides a service for money.  It should be expected that the service is adequately provided as described.  I feel it is disingenuous to claim to have these features, and charge money, when they don't work as they should reasonably be expected to. The forum is littered with users having the same issues. So many having to do with how unintuitive the application is, whether they realize that is the issue or not.

To me, it would be a straightforward fix.  Get someone who is comfortable with User Experience (UX) and User Interface (UI), and redesign the frontend.  I'd be thrilled to contribute toward that, as I'm sure many in this community would.  Crowd funding is great. No easy mode needed.  Just a well designed interface providing access to the information we all want in front of us.  It can be achieved.  Instead, the forum is filled with responses like "that's not something you should have to do very often" or "just move to another screen, it should sort itself out" or "you shouldn't do that anyway".  That, to me, is unacceptable.

The upside to BandHelper, and the reason I continue to try to work with it, is that is contains all the data necessary to do the things we want it to do.  I keep trying to find a way to work through the clunky interface to pull that data forward in a meaninful way.  However, it does even the most basic functions in a clunky antiquated way.  Investment in a decent UX/UI redesign would make this app a "must have" for every musician.  With what features BandHelper claims to provide and at the price, every musician on the planet would be using it.  Anyone I've encountered who has tried it gives up on it. What you would gain from new and retained users would certainly cover the cost of redesign efforts, and then some.

I've just come from a rehearsal where (after many more hours of data massaging) band mate informed me he stopped using BH and has loaded the new songs to learn in the old system.  He did it because in BH 'lyrics didn't scroll', he 'pressed a button' and ended up on some screen he didn't recognize and couldn't get back.  He gave up.  I don't blame him.  My subscription runs out in May, so I only have until then to rightfully rant, which I'm sure I'll continue to do.

[arlo]

want to play a song > open Songs > NOPE...you have to access a song from a setlist.  The Song 'feature' is only to populate information.  Ok.  Opens Setlist.  Oh, that song isn't on a setlist? You'll have to use a smart list and find it.  How is that easier than just opening it from Songs? The workflow presumes that a gig is comprised of predetermined set of songs.  It is not necessarily so, (never in my case) and is inhibitive.

It's not required that you play from a predetermined set list (the app has several functions to accommodate that), but you do need to use a set list or smart list to access the performance-related functions like auto-scrolling and remote control.

open a song in setlist > play song > press back button to return to list of songs > NOPE...that takes you out of the setlist all together and dumps you into a muddled view of layouts.  that's not at all intuitive.

Correct, the Back button takes you to the previous page of the app. If you want to show the song list after hiding it, you can use the song list button, or a two-fingered tap gesture, or a remote control action. Also, if your list of layouts is muddled, you can clean it up by deactivating or deleting layouts you don't use, and/or entering sort orders to place your favorites at the top.

Create a custom layout on my android tablet (a layout which comprised of data I want to see when I open ANY device I use) > Opens iPad > no custom layout.  Has to recreate the same layout for each device.

You can enable the Scalable option for a layout if you want to use the same layout on different screen sizes. The display will be letterboxed on screens with a different aspect ratio. To make full use of every screen size, you can copy the layout and then adjust the new copy to fill the new screen.

Song starts scrolling  > You play it a bit faster or slower based on the crowd > There is no function to increase or decrease speed.  You drag the screen, and the scrolling feature bugs out and jumps to the top causing you to lose your place.

I haven't seen the lyrics jumping to the top when dragging while auto-scrolling. We could troubleshoot that if you submit a help ticket. See also some alternatives to auto-scrolling demonstrated in this video:

https://youtu.be/7Z8s64BYWGo

Band mate sees interface and asks if they can change the horrible blocky font.  NOPE. can't change that.  Why?

That's just the app branding, and IMO it looks better than the system default, especially at larger sizes.

Transpose a song just for me?  Yup.  But if doesn't really.  It creates a new and independent copy of the song.  So if someone changes the master version you don't get the update.  Well, once again, not at all intuitive.

I'm not sure what workflow you're referring to here, but there are several options. You can transpose on the fly during a performance and that won't be saved, or you can transpose while editing and it will be saved, for all users by default. If you want different users to see different keys, that's a little more involved, but you can get it done with personal sync fields. If you use the separate Lyrics and Chords fields, you can maintain separate versions of the chords while sharing one copy of the lyrics.

Open a menu, make a selection, have menu disappear.... NOPE  let's divide the already limited screen space until you can't read the column of data you are trying to edit.

The app does use a two-column navigational structure on tablets. That's a common design pattern and it has worked that way since day one, with no complaints that I can recall.

Custom Layouts require a separate view for each orientation.  Why not just recognize changes or customizations to layouts in each orientation, and save it as a single custom layout?

Viewing a layout in the other orientation would require either significant stretching or significant letterboxing. Neither option would work very well, so the expectation is that you would have different layouts for different orientations. You can always use the predefined layouts as a starting point and customize from there.

why do i need to input the duration of each of the 400 songs I have loaded?

You can enter a default duration. This is described in the first step of the auto-scrolling tutorial:

http://www.bandhelper.com/tutorials/autoscrolling.html

BandHelper has taken an approach which makes no sense at all.  Spend hours prepopulating the data of duration time (which you would otherwise NEVER do, and STILL don't have the ability to make an adjustment on the spot.  That's poor design.  Your insides are on the outside.  As a user, I want to control scroll speed, not time out my songs.

If you consider a user or a band sharing data across multiple devices with multiple screen sizes, then calculating the speed from the duration makes sense. The duration is relatively constant, so then the speed can vary proportionally to the different screen sizes. If the speed were constant, it wouldn't work on different screens. If your song duration is not constant because you vary the tempo or the arrangement, then the auto-scrolling alternatives mentioned above would be better.

in BH 'lyrics didn't scroll', he 'pressed a button' and ended up on some screen he didn't recognize and couldn't get back

I can't tell what happened from that description, but I'm always happy to sort out questions like this when they come up.

I'm not meaning to come down on Arlo, but its not like this is a free app and this is being done as a favour.  It is a business, and he provides a service for money.  It should be expected that the service is adequately provided as described.  I feel it is disingenuous to claim to have these features, and charge money, when they don't work as they should reasonably be expected to

It's fair to make any critique you want about implementation decisions or visual glitches, and I track all of it, in a necessarily prioritized way. But if you're ignoring the unparalleled functionality and versatility here, and implying this should be a free app, then I think you're not seeing the forest for the trees. As far as what you should "reasonably expect," the documentation and the explanations you get from tech support are what you should reasonably expect. I don't think it's fair to imply that my product is ripping people off because it implements features differently than you imagined they would work.

By the way, I've found in talking with thousands of users that "intuitive" is subjective and has a lot to do with the expectations of the user, how they think and what software they used in the past. Some people think BandHelper is intuitive, some don't. I'm always tweaking and trying to improve it, but I believe the perspective I bring to that process is broader than the perspective of any single user.

[shibetpc]

It's not required that you play from a predetermined set list (the app has several functions to accommodate that), but you do need to use a set list or smart list to access the performance-related functions like auto-scrolling and remote control.

This doesn't address the issue.  Its just saying how it can technically be done, however unintuitively and inefficient.  But technically and inefficiently, I can carry around a printed out book of chords and lyrics.  My point is that services like BH should seek to be both efficient and intuitive.  Intuitively when you intend to perform a song, the simplest way you would expect to do it to select Song, choose that song, be presented with a view, and perform it.  The fact that you separated the Song function out is proof of the point I'm making.  You've done that because it resembles how the underlying data structures exist.  But the user never even needs to be exposed to that. When a new user adds a song, they will INTUITIVELY look in Songs to retrieve it for performance, and the interface should reflect that. As users, we shouldn't have the need or requirement to understand how data is structured in order find the features we want.  The app should come to us.

Why not have Songs let you access the songs themselves (as one would rightfully expect)? Default layout view at first, unless otherwise specified in settings). From there you can edit data or add to a setlist if necessary. 

Correct, the Back button takes you to the previous page of the app. If you want to show the song list after hiding it, you can use the song list button, or a two-fingered tap gesture, or a remote control action. Also, if your list of layouts is muddled, you can clean it up by deactivating or deleting layouts you don't use, and/or entering sort orders to place your favorites at the top.

Same answer as above essentially.  A technical one that doesn't take user experience into consideration. The back function is not for YOU as the app designer.  Its for the USER.  The back button is intuitively to access the last feature a USER came from.  In the case of the user, that is the Setlist, or list of songs, or the main menu.  Not to leave the Layout itself, which is a technical function, not a user one. 

Also, I found it dangerous to deactivate or delete layouts.  In cases, I hadn't realized that orientation changes were relying on system layouts.  Deleting them causes blank screens when orientation mode is changed.  This should never happen for any reason, and the user shouldn't have to understand why in order for it not to occur.  That is a developer issue.  Not a user one.

You can enable the Scalable option for a layout if you want to use the same layout on different screen sizes. The display will be letterboxed on screens with a different aspect ratio. To make full use of every screen size, you can copy the layout and then adjust the new copy to fill the new screen.

OK. I'll concede that, but again only as a technicality.  Many apps offer custom layouts.  They don't utilize letterboxing.  They make a decision on how to scale and position the individual items based on the relative placement of the original layout.  It feels like you've tried to reinvent the wheel here, and came up with a square.  There are established means of accomplishing this cleanly.  Why not take advantage of them?

I haven't seen the lyrics jumping to the top when dragging while auto-scrolling. We could troubleshoot that if you submit a help ticket. See also some alternatives to auto-scrolling demonstrated in this video:  https://youtu.be/7Z8s64BYWGo

I've attached a video showing the effect.  I expect, as with other responses, you'll see the video and explain to my WHY its doing that, and why I shouldn't need do what I'm doing to cause it to happen.  Preemptively, I don't want to know what is causing it. It doesn't matter to me as a user. I just want it to not happen.  It happens regularly during appropriate use of the application.  The desired response would be "that should never happen".

The alternatives you offer in the video are to add hardware (which complicates setup), or to record an automation track (which requires even more initial setup and is then rigid and unadjustable.  Scrolling is a basic function of apps of these kinds.  I don't understand how it is so overcomplicated.

That's just the app branding, and IMO it looks better than the system default, especially at larger sizes.

Stylistic choices aside, if it were an appropriate font/style to use, you would see it and similar being used everywhere is apps.  You don't.  There is a reason.  User Interface information is abundant on the web.  There is research, discussions, suggestions, justifications, and even full libraries of standardized user interface toolkits.  It feels like there was little attention paid to the established standards and that interface decisions were made in an information vacuum.   The result is that the interface looks heavy and antiquated.

However, this truly is subjective.  If the functionality/interface issues were solved, it would hardly be a second thought.  It is only made more prevalent in context to the other issues.

I'm not sure what workflow you're referring to here, but there are several options. You can transpose on the fly during a performance and that won't be saved, or you can transpose while editing and it will be saved, for all users by default. If you want different users to see different keys, that's a little more involved, but you can get it done with personal sync fields. If you use the separate Lyrics and Chords fields, you can maintain separate versions of the chords while sharing one copy of the lyrics.

A technical answer that doesn't accomplish the expected result as to how a USER would expect it to work in the real world.  You've created a feature that addresses each point, but not the problem as it exists in a real environment.  The issue is that transposition happens for each user, and may only be specific to them.  However, the OBVIOUS expectation would be that while my transpositions remain mine alone, any changes to lyrics or song structure would be maintained.  Now, look at how you've addressed the situation. You've created a scenario where if you want to keep your own transposition, a second copy of lyrics is created and the transposition is stored in the new copy.  If another user were to make changes to the original key or lyrics, you're still working off an old copy.   What is expected is an 'offset' (which has been discussed) whereby each users transposition is stored as an offset to the ONE shared copy.  Any changes to the original are fed to each user and the transposition offset applied.

This is also what I meant by being disingenuous about features.  I don't mean to imply you're doing it maliciously or trying to rip people off.  I'm an a**h***, not a slanderer    You can tick the box saying you have that feature, but in reality the feature does not work in a functional manner to address the real life issue.  You've CREATED a problem.  I now have to manually maintain multiple copies and ensure each band member is working off the appropriate copy. More work.

The app does use a two-column navigational structure on tablets. That's a common design pattern and it has worked that way since day one, with no complaints that I can recall.

When was this common? Certainly not within the last 5 years.  Show me one app where it is used to success, and I'll show you 50 that don't.  Common practice is to use sliding menus that get out of the way, or full overlays / view changes that are hidden once a selection is made, or even a persistent menu on the top or bottom (which is also being phased out).  Have a look at others apps like Reddit, Discord, Telegram, or even competitor apps like Setlist Helper.  All using slide out menus very effectively.  Why?  They maximize screen real-estate.  That's important.

I have my hunch as to why you don't see more posts like mine on the forum.  Those users don't get that far.  They see an app act wonky or unintuitively and they bail and move on.  Its a false negative.  You're not seeing it because those users aren't in the dataset to be queried.  They abandoned ship. I don't give up so easy

However, my complaint is real.  I've shown the video that displays a song editing column that is less than 1/4" wide, in which only the first letter of field labels are shown.  It is not possible to work like that.  The response was got was that I shouldn't have to change it that often.... In reality, it should never have been let into a production environment with the ability for it to end up like that. I would be afraid to use that app in a live environment, and band mates have validated that concern by refusing to use the app for its inconsistencies.  Outside of BH I've never experienced an app that has done that, and I've used them all.

Viewing a layout in the other orientation would require either significant stretching or significant letterboxing. Neither option would work very well, so the expectation is that you would have different layouts for different orientations. You can always use the predefined layouts as a starting point and customize from there.

I'm not suggesting you can't have different layout for each orientation.  I wondering why you force the users to be exposed to the developmental constraint that each orientation is technically its own separate view?  No other app deploys default or custom layouts this way.  You can easily store the values of each orientation as a single layout.  A single layout which contains two orientations (portrait and landscape).  The fact that TECHNICALLY a layout is comprised of 2 separate orientation specific layouts should NEVER be exposed to the user at all.  Ever.  They don't need to know, and it confuses the matter.  The EXPECTATION is that a custom layout contains both orientations.  That should be painfully obvious. It leads to people creating a custom layout, switching orientation, and experiencing empty screens or default views which are unexpected. 

You can enter a default duration. This is described in the first step of the auto-scrolling tutorial:

http://www.bandhelper.com/tutorials/autoscrolling.html

You've missed the point here.  App aside, why would a musician need to keep track of specific song durations?  In 25 years as a working musician, dozens and dozens of projects, no one has ever asked me to know the specific duration of a song, nor have I had found that information useful for my own needs.

It is REQUIRED in BH for the purpose of serving the auto-scroll function.  So let's make that clear.  You are ADDING and COMPLEXIFYING the song creation function to serve a function of the app.  If the song is 3.5 minutes long, it will take me 3.5 minutes plus whatever data entry time to create a new song as it requires me to time out the song for 'accurately' functioning auto-scroll.  This is because I don't have, and would otherwise NEVER have need for capturing and storing song durations. I can't think of a scenario where a musician would to be honest.  So who is working for who here? The app is meant to make it easier to work.  I'm going through the effort to make it easier for the app.

My point is that you can address this another way. 

:: Use the same formula for creating the auto-scroll, just in reverse 
:: Prepopulate (by default) song duration so EVERY song scrolls by default. 
:: In the song view, include +- scroll SPEED buttons.
:: BEHIND THE SCENES, those +- speed scroll changes effect the song DURATION.
:: Same result achieved, but in an intuitive way for the user. No setup. No need for USER to understand the correlation of duration to font size to screen size.  Again, the tendancy of BH is to force the user to undestand WHY the app works.  This is confusing.
:: Using the above, you increase functionality (adding +- speed buttons) and decrease user input. Is that not preferred?  You can still include a field in song settings for those who want to enter duration manually.  It doesn't change the underlying data, but you've added highly desirable (if not absolutely essential) functionality in the process.  And you can't tell me that I shouldn't need to increase or decrease speed of scrolling, or tempos remain the same.  Live performance requires this flexibility.  It just does.

If you consider a user or a band sharing data across multiple devices with multiple screen sizes, then calculating the speed from the duration makes sense. The duration is relatively constant, so then the speed can vary proportionally to the different screen sizes. If the speed were constant, it wouldn't work on different screens. If your song duration is not constant because you vary the tempo or the arrangement, then the auto-scrolling alternatives mentioned above would be better.

I'm not suggesting a constant speed.  See above response.

Further, virtually EVERY app considers a user/users sharing data across multiple devices with multiple screen sizes.  This isn't specific to this application by any stretch of imagination.  Yet, what other app do you know that puts it on the USER to solve this issue.  This should be addressed by good design practices, with user experience in mind.

Also, also, just to reiterate.  Use the same auto-scroll formula.  Just make it transparent to the user.  Have speed increases (user) effect song duration (system).  Same effect. Cleaner for user.

I can't tell what happened from that description, but I'm always happy to sort out questions like this when they come up.

The point is that you'll likely never get that opportunity.  Users don't have the expectation of needing to be trained in to an app.  and in general they aren't willing to adopt an app that works contrary to their fundamental tablet experience or requires them to understand application development.  They don't want to know why. They just want it to work.  If it doesn't work, they move on.  There is no reason for BH to not just work.  These problems can/should be solved with good interface design practices.  The data is there, and the underlying processes are there.  IMO it just needs to be presented better.

It's fair to make any critique you want about implementation decisions or visual glitches, and I track all of it, in a necessarily prioritized way. But if you're ignoring the unparalleled functionality and versatility here, and implying this should be a free app, then I think you're not seeing the forest for the trees. As far as what you should "reasonably expect," the documentation and the explanations you get from tech support are what you should reasonably expect. I don't think it's fair to imply that my product is ripping people off because it implements features differently than you imagined they would work.

I am certainly not implying that the app should be free.  Charge whatever the market will allow, but have a product that is commensurate with your pricing.  If BH worked as expected, I'd happily pay you every year, and be glad for it.  Your marketing shows an app that does everything a musician can want.  The truth is even basic functionality such as navigation is unpolished, buggy and inconsistent; basic functionality like auto-scroll requires intensive setup, explanation, and understanding of underlying data structure; listed features like transposition discussed above are not implemented in a manner to address real world problems.

The user is in service to the app, rather than the app being in service to the user.  This is my point about charging money.  I use apps everyday.  Many of them free that do amazing things in amazing ways.  I control digital hardware; I do video, audio, and text messaging with large groups of people worldwide across mobile devices, tablets, laptops, desktops; have the web scoured for my specific tailored interests, and presented to me on demand.  That's all free.  And intuitive.  No training required.  Just a basic understanding of how to use common features of a tablet.  You are charging me a subscription, and I'm the one who is responsible for creating layouts for each of my own devices.  I am responsible for providing the variables necessary to control auto scroll speed.  I am responsible for version management to utilize individual transposition. So on, and so forth.  If it were open source, I'd hire someone to just do it, or submit code changes on my own.  I am willing to donate to the cause. I am willing to pony up my skills or resources in support of the effort to achieve the desired product.  That isn't your model, and I respect that.  You control the code and design implementation, and you charge for your efforts.  Good.  For my end, I pay for the services and as part of the buyer/seller contract I want to achieve what your app promises.  So far, that's not been possible.

By the way, I do think you have the guts of an amazing platform here.  Just one that requires an interface and user experience worthy of its processes.

By the way, I've found in talking with thousands of users that "intuitive" is subjective and has a lot to do with the expectations of the user, how they think and what software they used in the past. Some people think BandHelper is intuitive, some don't. I'm always tweaking and trying to improve it, but I believe the perspective I bring to that process is broader than the perspective of any single user.

I understand that.  Intuitiveness is subjective.  However, it does have a threshold.  You can survey a large user base just by looking at the commonalities across the heavily used popular apps.  Their utilization of common toolsets and design decisions are an indication of intuitiveness and user comfort levels.  BH doesn't work like other apps, and suffers from it. There isn't any reason why it should be any different. 

[arlo]

I think what this boils down to is that you want the app to be designed differently than it is. But I'm simply not going to throw away something that has worked for thousands of users for more than eight years based on one person's experience. You're always welcome to make requests and suggestions, but if your tone is predominantly crabby or condescending, or you can't prioritize your own needs, or you don't make an effort to learn and understand the benefits of the current design, it's difficult to justify continuing the conversation.

[shibetpc]

Well, that's a bit of a funny way to boil it down.  I think my post stands for itself and the concerns are valid and supported with fact.  However, if you are unwilling to engage it, and unable to see these concerns reflected across the forum and in reviews,  i can't make you.

For those who do continue to read this, I won't hide my frustration. I've worked countless hours troubleshooting, studying this forum, watching videos, posting 'help tickets', and trying anything else to make BH do what it claims to be able to do.  I have been thwarted at every turn by half thought out features and illogical workflow.  Unfortunately, what I'm left with is so convoluted as to make any potential benefits null.  It is certainly not a solution I would consider using in an environment of consequence. 

[JerryK]

Clearly, you don't like much about the app.  You should probably spend a fraction of your time in using another one.  How you imagine BH could successfully scroll a song at the right speed without knowing something about the duration, number of beats or some additional info defeats me.
Thanks for an interesting read but BH does a much better job for most of us IMO, than it ever will for you.
Be lucky.

[shibetpc]

Hi Jerry, thanks for the response.  I actually like a lot about the app, which is why I have invested SO much time in trying to get it functioning.  I really like how it handles midi, and the control level you have to initiate midi messages. I like that I can create different projects from one account with different members, so every sees what they are suppose to.  I like the idea that near-on every piece of data (outside of mixer control interface) you need for gigging is present in the app. that's why i chose it.  That is why I am frustrated.  All the pieces are there, just not in the right order.

I think though, you've misunderstood my suggestion the control of auto scrolling.  Scrolling would still be based on DURATION.  However, scrolling SPEED control would affect the DURATION, so:

:: press increase SPEED = cut the DURATION
:: press decrease SPEED = increase the DURATION

The duration of the song is controlled by an inverse relationship to the speed operation.  This would allow the user to set and control scroll speed right from the song, without the need to know the duration of the song.  You could easily set the default song duration as 3 min (or whatever), and then control the desired speed (affecting the duration) during performance, with the ability to adjust real time.  Behind the scenese, the song duration gets adjusted to fit the desired scroll speed.  No change to the underlying structure of data or formula, and no functionality lost.  Just additional important functionality that serves the user.

I'm glad that BH works for you.  I guess it does remain to be seen whether BH will serve my needs in the future.  I really hope it does, as the foundation is already there.  If not, another app will eventually come along.  That's the way it works In the meantime, I'll keep following it so see how it progresses.

[JerryK]

Thanks for the explanation. Point taken. Perhaps it could even learn your preferred scroll speeds per-song.
Whatever, I'm glad you're not simply against all that BH has to offer, though it did rather sound that way.  An app of this complexity and capability is not going to do all things for all users in their own ideal way. It's great that Arlo listens to all comments and acts on many of them.  BH is not perfect but it has a great deal to offer most users, for which I applaud it/him.
So once again, good luck.

[arlo]

The duration of the song is controlled by an inverse relationship to the speed operation.  This would allow the user to set and control scroll speed right from the song, without the need to know the duration of the song.  You could easily set the default song duration as 3 min (or whatever), and then control the desired speed (affecting the duration) during performance, with the ability to adjust real time.

An on-the-fly scroll speed override is on my wish list and I'll add a vote for you. Meanwhile, the supported options are to pause/resume autoscrolling with a screen tap or remote control as needed, to drag to reposition as needed (you can still submit a help ticket if that isn't working for you) or to use one of the alternatives to auto-scrolling discussed in the tutorial:

http://www.bandhelper.com/tutorials/autoscrolling.html

[shibetpc]

Thank you for that.  Much appreciation.  Ill submit the help ticket on drag repositioning.

All the best.
T