- Welcome to Apps by Arlomedia.
Before posting, please read: When to use this forum, when to submit a help ticket
Recent posts
#91
Repertoire Help / Re: Duplicating set lists
Last post by arlo - January 19, 2026, 08:56:51 AMYou can go to Repertoire > Set Lists > [set list name] > Edit Details and click the Copy button. Change the name and save if you're on the website (the app auto-saves), then go to the Edit Songs page and start making changes.
#92
Repertoire Help / Duplicating set lists
Last post by MikeBusby - January 19, 2026, 03:50:48 AMI have a standard set list and want to duplicate it with a couple of changes. I can't see this functionality.
#93
Account Help / Re: Features missing after rec...
Last post by arlo - January 17, 2026, 03:46:24 PMYes, your data from the Pro modules will still be there.
#94
Repertoire Help / Re: Feature request: Categorie...
Last post by ChrisMikolaj - January 17, 2026, 02:55:26 PMI'm very sorry.
I need to assign MIDI presets to buttons on a performance layout.
So I open the MIDI preset list and select a preset.
On the performance layout, the MIDI label is the preset name.
Because the available space there is limited, long preset names are hard to read, so I want to shorten them.
When I shorten the names, I can no longer tell in the preset list which device a preset belongs to (e.g. guitar vs lights), because that information currently only exists in the name.
So the problem is that shortening preset names improves the performance layout, but makes the preset list ambiguous.
I need to assign MIDI presets to buttons on a performance layout.
So I open the MIDI preset list and select a preset.
On the performance layout, the MIDI label is the preset name.
Because the available space there is limited, long preset names are hard to read, so I want to shorten them.
When I shorten the names, I can no longer tell in the preset list which device a preset belongs to (e.g. guitar vs lights), because that information currently only exists in the name.
So the problem is that shortening preset names improves the performance layout, but makes the preset list ambiguous.
#95
Account Help / Re: Features missing after rec...
Last post by megahertz - January 17, 2026, 12:28:06 PMok, thanks. my bad, i guess. if i upgrade, will my checklists and session logs be restored?
#96
Repertoire Help / Re: Feature request: Categorie...
Last post by arlo - January 17, 2026, 11:02:29 AMYou're telling me what solution you want, but not what problem you're trying to solve. Please describe a situation, like "I need to do ____, so I click ____ and ____, and then I see ____ and that's a problem because ____."
#97
Repertoire Help / Re: Feature request: Categorie...
Last post by ChrisMikolaj - January 17, 2026, 08:07:07 AMThe core "problem" is that the preset name is currently doing too much work.
Right now, I have to structure the name in a very specific way so it stays sortable. That works, but it means the names keep getting longer and more artificial over time.
For example:
Light presets often need to start with something like "Lightbar ..." just so I can group or filter them
Guitar presets may include the guitar or board name in the preset name, even though that's not really part of what the preset does
What I'd actually like is:
Use the preset name to describe the function ("Ambient Wash", "Crunch Verse", "Clean Intro", etc.)
Store what it belongs to (Lightbar, Guitar, which guitar / board) in a separate field
With the current system, if I don't encode that information into the name, I lose the ability to reliably filter or sort the list later.
That's why I was thinking about user-defined fields:
One field for "Device / System" (Lightbar, Guitar, Bass, etc.)
Maybe another for "Category" or "Sound Type" (Ambient, Clean, Crunch, Lead)
Then allow filtering by those fields in the MIDI preset list
This would keep preset names short and readable, while still making large preset lists manageable in the long run.
As a lightweight alternative, even showing the Notes field directly in the list view would already help, since it could act as a visible classification instead of hidden metadata.
So long answer short: If I would change the names of the presets to what they actually are doing (which is what I would like to do to be able to have a smaller MIDI field on my performance layout on the iPad), I cannot do that as of now without losing the ability to actually know what the preset does to which device.
Does that make more sense? Sorry if I cannot really describe what the issue is sufficient enough. I appreciate your time and efforts on that
Right now, I have to structure the name in a very specific way so it stays sortable. That works, but it means the names keep getting longer and more artificial over time.
For example:
Light presets often need to start with something like "Lightbar ..." just so I can group or filter them
Guitar presets may include the guitar or board name in the preset name, even though that's not really part of what the preset does
What I'd actually like is:
Use the preset name to describe the function ("Ambient Wash", "Crunch Verse", "Clean Intro", etc.)
Store what it belongs to (Lightbar, Guitar, which guitar / board) in a separate field
With the current system, if I don't encode that information into the name, I lose the ability to reliably filter or sort the list later.
That's why I was thinking about user-defined fields:
One field for "Device / System" (Lightbar, Guitar, Bass, etc.)
Maybe another for "Category" or "Sound Type" (Ambient, Clean, Crunch, Lead)
Then allow filtering by those fields in the MIDI preset list
This would keep preset names short and readable, while still making large preset lists manageable in the long run.
As a lightweight alternative, even showing the Notes field directly in the list view would already help, since it could act as a visible classification instead of hidden metadata.
So long answer short: If I would change the names of the presets to what they actually are doing (which is what I would like to do to be able to have a smaller MIDI field on my performance layout on the iPad), I cannot do that as of now without losing the ability to actually know what the preset does to which device.
Does that make more sense? Sorry if I cannot really describe what the issue is sufficient enough. I appreciate your time and efforts on that
#98
Repertoire Help / Lighting control from midi fil...
Last post by Ralleberg - January 17, 2026, 05:34:39 AMHi Forum,
I can see there are quite a few threads about this, but I haven't been able to find a clear solution so I'm hoping someone here can help.
Setup / prerequisites:
Thanks in advance!
I can see there are quite a few threads about this, but I haven't been able to find a clear solution so I'm hoping someone here can help.
Setup / prerequisites:
- iPad #1: running BandHelper
- iPad #2: running Light Rider
- I have some MIDI files that I'd like to play when a song is selected for the second time, so they stay in sync with the backing track, etc.
Right now, I've added them under "Recordings" - both as a file at the top, and also as the default MIDI file at the bottom of the page (I found a simple soundfont that it needs in order to play a MIDI file).
Is this the correct way to set this up? - When I play the file, I can see that Light Rider only receives "Note On vel: 127" and "Note On vel: 0", even though my raw MIDI file clearly contains both Note On and Note Off messages. If I use MidiWrench on the iPad with BandHelper, I can also see that a proper MIDI Note Off isn't being sent as expected.
Has anyone experienced the same issue and found a solution?
Thanks in advance!
#99
Repertoire Help / Re: Feature request: Categorie...
Last post by arlo - January 16, 2026, 05:37:08 PMThis isn't quite getting to what the problem is. You said the list is "cluttered." Can you describe a specific task you're doing that is difficult to do now?
#100
Repertoire Help / Re: Feature request: Categorie...
Last post by ChrisMikolaj - January 16, 2026, 05:12:50 PMI'll try to explain it as clearly as possible.
In the screenshot you can see how my current MIDI presets are organized. The brown-colored ones are presets for our lightbar. At the moment, this color coding is only temporary, as we've just started testing these presets and they are not final yet. Depending on how the different color modes end up, I will probably adjust the color scheme as well.
The presets in the other colors at the bottom are currently pedalboard presets that are assigned to individual songs. As I continue to assign presets to more songs and add additional presets, this list will inevitably become more and more cluttered.
That's why I think it would be really helpful to have tags or user-defined fields to categorize presets — for example "Lightbar", "Guitar", or even more specific categories like "Ambient" or "Crunch". This would make it much easier to find, adjust, use, and assign presets later on.
With the current list view on the website, I feel that managing a growing number of presets will become increasingly difficult over time.
Maybe I'm a bit picky here, but I thought this perspective might still be helpful.
In the screenshot you can see how my current MIDI presets are organized. The brown-colored ones are presets for our lightbar. At the moment, this color coding is only temporary, as we've just started testing these presets and they are not final yet. Depending on how the different color modes end up, I will probably adjust the color scheme as well.
The presets in the other colors at the bottom are currently pedalboard presets that are assigned to individual songs. As I continue to assign presets to more songs and add additional presets, this list will inevitably become more and more cluttered.
That's why I think it would be really helpful to have tags or user-defined fields to categorize presets — for example "Lightbar", "Guitar", or even more specific categories like "Ambient" or "Crunch". This would make it much easier to find, adjust, use, and assign presets later on.
With the current list view on the website, I feel that managing a growing number of presets will become increasingly difficult over time.
Maybe I'm a bit picky here, but I thought this perspective might still be helpful.