I need opinions - usability - not sure where to ask this
-
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.
-
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.
It is a lot. I'm currently running with about 320kb+ of it free with my demo track. as far as stage lighting, you make a point, but i can't very well go back to floppies. Only other option is wifi or bluetooth. That is an option with this chip, which will do both. The 320kB varies though. I also have a 90kB TTF font I load and unload periodically as the system starts up. While it runs, it runs super lean though. I think I'll probably wind up using a bunch of that to hold loops you can record and playback while you perform. But even Bohemian Rhapsody by Queen runs less than 60kB, Sabotage by Beastie Boys runs 80kB for the whole track, just as a perspective thing. I can't really get a custom ESP32 with less SRAM. Where I really use this thing is the 2 cores. I use the 2nd core for rendering high quality visual feedback - something lesser chips couldn't really support a screen for anyway. I could probably run this on an Atmel SAMD with 192kB of SRAM pretty comfortably but they run at a lower clock speed - i forget what - still probably fast enough without the graphics. Still, these chips are less than $2 a piece at digi-key and less if you get runs of them.
To err is human. Fortune favors the monsters.
-
That's an interesting idea. I'll consider it. My main concern with it is if the list isn't done loading it will be hard to tell when it's done and you've reached the end or if there's more to go. I guess I can squeeze an indicator on there but the screen is very small. Also it displays only one file at a time due to the size of the screen, and displaying information about each file, so there's no "list" to scroll. Plus scrolling is out of the question for performance reasons the way these little gadgets work.
To err is human. Fortune favors the monsters.
fileName where [x] is really an movement indicator. Either a number (n), that you fill in as you process each file. Or a Linux style set of ".-/-\*^v" that you MOD your way across, to give the appears of progress per file. the upside to this is that a long file doesn't make the user think it is done at file [13] xyz and they can start spinning the nob to select another... Also, I am a FAN of red LED for busy, and GREEN LED for available. So if you have a power LED, red during boot up. GREEN when good. YELLOW when you have an issue (Either a specific corrupted MIDI file, or something). But here I go adding hardware... And not sure if Nob only rotates, or if it contains a "switch" (pressing) as well. (Turn to select, Press to play type thing). But your project sounds like FUN! And you do a GREAT job on asking questions... I can REALLY tell you care about how it turns out! -
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.
With your one-item display and the need for immediate response, I would read the directory, sort the names into the desired order and display the first one without any information (say -checking- perhaps). Update it when it's been examined. Check the rest of the files as a background task after that. If the user scrolls to a new uninspected one, drop the inspection of the first one and give the new one priority. Keep partial results if you can. Allow selection and use before the check is finished, because it will nearly always be alright. Display corrupted ones anyway, and show that as the track information. It's better than having your user be sure "it was on one of these SD cards here somewhere".
-
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.