I need opinions - usability - not sure where to ask this
-
For your intended users, is it a reasonable expectation that they can't put 100+ files on the SD card?
I think so. In practice, this is a little performance box, and scrolling through that many files is not really reasonable. Anything after a dozen and they'll get annoyed just because all you have to work with is a knob and a button. It's not like PC dev, unfortunately. The UI is severely limited by a very limited input interface - tiny screen, no keyboard or mouse. no scrolling because it's too slow. Because of that, I think a user at least once they are familiar with using the thing, isn't going to be put out by not carrying their entire catalog of MIDI sets on a single SD card. In fact, it's kind of optimized for one per SD-Card, such that when it finds just one file it will open that one and start up without prompting. That's because eventually I'll probably make it so you can punch in and punch out SD cards on the fly, but for now i don't have the right hardware for that. It's not hard to get it though, i just haven't yet.
To err is human. Fortune favors the monsters.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
Don't allow "scrolling" while files are being imported. Just show the progress of the import and maybe allow cancelation.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
find a musician like and ask this question, you will have first hand feedback...
diligent hands rule....
-
find a musician like and ask this question, you will have first hand feedback...
diligent hands rule....
I have some pretty tiny mp3 players (the size of a thumb drive); with 100's of songs. I'd review how they did it. Mostly single thumb actions.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
I have some pretty tiny mp3 players (the size of a thumb drive); with 100's of songs. I'd review how they did it. Mostly single thumb actions.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
I have no solution, just a little story: Some years ago, I bought myself a handheld digital recorder (for those who care: a Zoom H4n), and equipped it with a 32 GByte card so I didn't have to shuffle lots of cards around. It is a nice little device, can record plain PCM and MP3 in high quality, even 4 channels. The only thing that frustrated me was the extremely long boot up time - more than a minute and a half before any control could be operated. Either, the recording had to be well planned in advance, or the recorder had to kept 'on' continuously, draining the batteries. A couple of years ago, I made some recordings to an SD card of a friend of mine - a 2 GB card. To my surprise, the recorder booted up a lot faster. At the bottom of a box of old stuff, I found the very first SD card I ever bought, a 256 MB one, and now the recorder boots up in 12 seconds, rather than 95 seconds! It makes noticeable difference if there are lots of data on the card (the Zoom pre-initializes a directory structure with approx. 40 directories when it formats the card; it is unconditionally there). If I replace the 256 MB card with the 32 GB one, it goes back to eight times as slow boot up - the recorder hasn't been 'cured', the boot time is tied to the card size. Putting a hundred recordings on a card does not slow it down further. I have no idea what the Zoom is doing to the card; even though flash cards are fast, it can't possibly do any testing of a full 32 GB in 95 seconds. The size of the directory structure is exactly the same on a small and a large card. So what is it doing with the 32 GB at boot up? I was lucky to find a small pile of 256 MB cards on a web shop trading used electronics - my local computer shop couldn't help me. So now I have cured the major problem with my recorder, at the price of having to shuffle cards.
-
I have no solution, just a little story: Some years ago, I bought myself a handheld digital recorder (for those who care: a Zoom H4n), and equipped it with a 32 GByte card so I didn't have to shuffle lots of cards around. It is a nice little device, can record plain PCM and MP3 in high quality, even 4 channels. The only thing that frustrated me was the extremely long boot up time - more than a minute and a half before any control could be operated. Either, the recording had to be well planned in advance, or the recorder had to kept 'on' continuously, draining the batteries. A couple of years ago, I made some recordings to an SD card of a friend of mine - a 2 GB card. To my surprise, the recorder booted up a lot faster. At the bottom of a box of old stuff, I found the very first SD card I ever bought, a 256 MB one, and now the recorder boots up in 12 seconds, rather than 95 seconds! It makes noticeable difference if there are lots of data on the card (the Zoom pre-initializes a directory structure with approx. 40 directories when it formats the card; it is unconditionally there). If I replace the 256 MB card with the 32 GB one, it goes back to eight times as slow boot up - the recorder hasn't been 'cured', the boot time is tied to the card size. Putting a hundred recordings on a card does not slow it down further. I have no idea what the Zoom is doing to the card; even though flash cards are fast, it can't possibly do any testing of a full 32 GB in 95 seconds. The size of the directory structure is exactly the same on a small and a large card. So what is it doing with the 32 GB at boot up? I was lucky to find a small pile of 256 MB cards on a web shop trading used electronics - my local computer shop couldn't help me. So now I have cured the major problem with my recorder, at the price of having to shuffle cards.
Well at least you know my pain. I've since added a progress tracker "loading 1 of 13" for example. It helps.
To err is human. Fortune favors the monsters.
-
I have some pretty tiny mp3 players (the size of a thumb drive); with 100's of songs. I'd review how they did it. Mostly single thumb actions.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
It might cache. I could theoretically do that.
To err is human. Fortune favors the monsters.
-
I have no solution, just a little story: Some years ago, I bought myself a handheld digital recorder (for those who care: a Zoom H4n), and equipped it with a 32 GByte card so I didn't have to shuffle lots of cards around. It is a nice little device, can record plain PCM and MP3 in high quality, even 4 channels. The only thing that frustrated me was the extremely long boot up time - more than a minute and a half before any control could be operated. Either, the recording had to be well planned in advance, or the recorder had to kept 'on' continuously, draining the batteries. A couple of years ago, I made some recordings to an SD card of a friend of mine - a 2 GB card. To my surprise, the recorder booted up a lot faster. At the bottom of a box of old stuff, I found the very first SD card I ever bought, a 256 MB one, and now the recorder boots up in 12 seconds, rather than 95 seconds! It makes noticeable difference if there are lots of data on the card (the Zoom pre-initializes a directory structure with approx. 40 directories when it formats the card; it is unconditionally there). If I replace the 256 MB card with the 32 GB one, it goes back to eight times as slow boot up - the recorder hasn't been 'cured', the boot time is tied to the card size. Putting a hundred recordings on a card does not slow it down further. I have no idea what the Zoom is doing to the card; even though flash cards are fast, it can't possibly do any testing of a full 32 GB in 95 seconds. The size of the directory structure is exactly the same on a small and a large card. So what is it doing with the 32 GB at boot up? I was lucky to find a small pile of 256 MB cards on a web shop trading used electronics - my local computer shop couldn't help me. So now I have cured the major problem with my recorder, at the price of having to shuffle cards.
I was thinking, and I bet I know why your 32GB card took so long. It uses a different filesystem (exFAT i think?) for cards >=32GB? if i remember correctly - might be > 32GB and I'm wrong about this. That may explain the discrepancy, not that exFAT is especially slow, but it could be that the implementation was poor and nobody cared because at the time nobody used exFAT. frankly, it's kind of a wonder it reads it at all.
To err is human. Fortune favors the monsters.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
Reminds me on certain questions I have to resolve myself and I got a product manager working such questions out for me. However, this product manager talks to our users. From my personal perspective, that's not a trade-off I as the maintainer would make, I'd ask users.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
Just load the first 10 files. If the user goes for an 11th file then chuck the first 10 away and load the next 10 etc.. Optimised for less than 10 files but more can be reached. I imagine that it is intended to be minimally distracting to a performing musician so you don't want modal selection procedures. This way it remains a simple up/down selection but you get a bump delay as you cross 10, 20 etc. I would think that would be acceptable for such a device.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
List them all initially as 'grey', then as the list is parsed/checked change the colour to those for 'working', or 'corrupt'. That way the user is carried along with a little understanding of the apparent 'informative progress bar' style display.
-
The indicator is very important for perceived performance - if you can quickly count the files, I assume you can even show a percentage or similar? Maybe if you detect more than a reasonable amount of files, you can start by displaying a text saying "This will take a long time, do you want to continue" (well, something shorter probably). If you are really fancy, you can start the loading in the background while displaying the message so the time until they react (if they react) is not wasted. If they just insert the SD card and throw it on the table without paying attention - at least it will then have finished loading when they come back from lunch instead of just sitting waiting for them to press the button.
lmoelleb wrote:
The indicator is very important for perceived performance - if you can quickly count the files, I assume you can even show a percentage or similar?
This is roughly my thought -- when loading will take a long perceived time, I count files, records, or whatever, and post a message that says "loading file xx of yy", and force the screen to update periodically. If there's a thousand files, I won't update display for every file (that will slow down the process), but every 10 to 20 files. If you're expecting a max of 100 files, updating the display every 10 should give the user good feedback while not bogging down the process.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
Offer it with an SD card filing system and you're golden. They have to be loading the midi files onto those SD cards somehow; what if you give them an app that does the whole process: read/scan each midi file, collect data on each, store that info in a db table or json file, and provide a code for labeling the SD card. Then your app can have a look-up tool that uses all of that great info you collected. Offer a special case for the SD cards that fits the labeling scheme you set up in the app. ETA: obv, you'll need the look-up part of the app to be mobile-first.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
Use a hash? A small Copy app to put files on the SSD and save a hash there. Instead of completely reading through the file with an integrity check, do a hash and then check against the saved one on the SSD.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
This seems like the SD card file picker on my cheap 3D printer. Use a rotary knob to scroll thru the list of files and push to select. Except you can only show one line of text on your display. Can you read one row/file at a time, or possibly two? Then keep current, prev, and next in memory and ignore the rest until the user scrolls. Can you count the number of clicks on the rotator knob so you know how many indexes to scroll forward/back so the user can "spin the wheel" to get through a long list? Do you have a FAT or equivalent to use as if it were an ISAM index so you don't have to read each file whilst scrolling?
-
This seems like the SD card file picker on my cheap 3D printer. Use a rotary knob to scroll thru the list of files and push to select. Except you can only show one line of text on your display. Can you read one row/file at a time, or possibly two? Then keep current, prev, and next in memory and ignore the rest until the user scrolls. Can you count the number of clicks on the rotator knob so you know how many indexes to scroll forward/back so the user can "spin the wheel" to get through a long list? Do you have a FAT or equivalent to use as if it were an ISAM index so you don't have to read each file whilst scrolling?
I read all the filenames and basic information about the files into memory before I display the selection screen. It is this portion that takes the time. The reason being is that I pre-validate and scan every file for corruption first. The reason I do that is because musicians equipment seems to fail more often than what I'm used to and corrupt MIDIs are just a thing to be dealt with. Furthermore musicians are not tech savvy as a rule, so I'd rather not show the file in the list. So I don't. When I display the files, it's one at a time sonata.mid 4 tracks tempo varies or sabotage.mid 11 tracks tempo 175.0 BPM with the name of the file being blue for type 1 and type 0 files, otherwise black for type 2 files (which are most suited for this gadget) The rotary encoder spins the files plenty fast enough. The only issue is after about a dozen midi files is where things start to get just on the other side of breezy and it goes downhill from there.
To err is human. Fortune favors the monsters.
-
I think so. In practice, this is a little performance box, and scrolling through that many files is not really reasonable. Anything after a dozen and they'll get annoyed just because all you have to work with is a knob and a button. It's not like PC dev, unfortunately. The UI is severely limited by a very limited input interface - tiny screen, no keyboard or mouse. no scrolling because it's too slow. Because of that, I think a user at least once they are familiar with using the thing, isn't going to be put out by not carrying their entire catalog of MIDI sets on a single SD card. In fact, it's kind of optimized for one per SD-Card, such that when it finds just one file it will open that one and start up without prompting. That's because eventually I'll probably make it so you can punch in and punch out SD cards on the fly, but for now i don't have the right hardware for that. It's not hard to get it though, i just haven't yet.
To err is human. Fortune favors the monsters.
If I were to use this in a live performance (unlikely; I'm an acoustic guy :) ) I think I would be VERY unlikely to have more than a few songs on the card. There's no time to scroll through even "just" 100 files when you're on stage. 10 is more likely to be manageable. Though maybe if "you can play file #1, stop, scroll to next, then go to file #2,stop, scroll to next..." you could plan your list of songs to always be in that sequence. But the reality of live performance has a way of interfering with planned set lists. If the gadget is cheap enough, people might buy more than one. Like having a spare guitar in a different key. Booting a 2nd device has to be faster than swapping SD cards, doesn't it?
-
If I were to use this in a live performance (unlikely; I'm an acoustic guy :) ) I think I would be VERY unlikely to have more than a few songs on the card. There's no time to scroll through even "just" 100 files when you're on stage. 10 is more likely to be manageable. Though maybe if "you can play file #1, stop, scroll to next, then go to file #2,stop, scroll to next..." you could plan your list of songs to always be in that sequence. But the reality of live performance has a way of interfering with planned set lists. If the gadget is cheap enough, people might buy more than one. Like having a spare guitar in a different key. Booting a 2nd device has to be faster than swapping SD cards, doesn't it?
Oh I hear you. In fact, my device will automatically load a MIDI file in the case where it's the only one on a card. The idea being for live sets you can punch whole cards in and out. Only issue is my current device takes microSD and I think standard SD would be better just for quickness of handling. The end device will support punch out in that manner, but i don't have the hardware necessary yet to detect the line change when the card is pulled and i don't have the resources to poll it. The end device will also allow you to loop your own sets in midi (since it will take a MIDI in) and punch those in and out, which doesn't use the SD card at all. I think I can get the gadget fabbed and built for about $100, giving me a few bucks for the PITA factor, but not much. A happy meal. What's funny is I'm doing all of this in about the 365kB I get on boot.
To err is human. Fortune favors the monsters.
-
Oh I hear you. In fact, my device will automatically load a MIDI file in the case where it's the only one on a card. The idea being for live sets you can punch whole cards in and out. Only issue is my current device takes microSD and I think standard SD would be better just for quickness of handling. The end device will support punch out in that manner, but i don't have the hardware necessary yet to detect the line change when the card is pulled and i don't have the resources to poll it. The end device will also allow you to loop your own sets in midi (since it will take a MIDI in) and punch those in and out, which doesn't use the SD card at all. I think I can get the gadget fabbed and built for about $100, giving me a few bucks for the PITA factor, but not much. A happy meal. What's funny is I'm doing all of this in about the 365kB I get on boot.
To err is human. Fortune favors the monsters.
I think you're right about SD vs uSD -- the uSD would be very easy to lose on stage. Neither card is going to be easy to see on stage, though; you're usually either nearly blinded by spotlights or in the dark. And most of your cables and equipment cases are black. 365Kb used to seem like a lot. I remember doing an 8051-based system which managed 5 RS232 ports (two customer inputs, two devices to control, one debug port) with 64K EEPROM, 32K RAM. Unless it was 32K EEPROM, 8K RAM... it's only been about 30 years, so those particulars are fuzzy.