I've sent v1.4 to apple for validation, it should take around a week.
Here are the major changes:
[Improvements] - SIDPLAY2: updated with latest version, fixing an issue with 'Fanta in space.sid' (fast device required for this one).
- MODLAND: updated to 04/09/2011
- HVSC: updated to #55
- BROWSER: optimizations
- BROWSER/PLAYER: playback of only 1 entry within a GME file (NSF,NSFE,GBS,...)
- PLAYER/VISUALIZERS: new visualizers, better selection menu, better beat detection
- PLAYER/Title: game name displayed (GME file), tap title to have the full name if display is truncated.
- DOWNLOADS: now can be suspended/resumed. Also now provides a "clear all" button. Lost of connection will suspend download (implemented for FTP only, not for HTTP yet).
[BugFixes] - SETTINGS/PLAYER: panning now applied as choosen
- SETTINGS/MODPLUG: settings now applied at launch
- VISU/SPECTRUM: high details mode was displaying Left value for Right Spectrum
- DOWNLOADS: wrong files list update when removing an entry
- SETTINGS/GME: default length now applied when applicable
- Lots of small bugfixes
I've been using the App since version 1.0 and I haven't found a way to change the default song length of certain formats, in particular is the SNDH (Atari YM2149). I have the SNDH archive as a zip and files always default to 2:30, although there is the rare song in there that does supersede the song length restriction. I've changed all song value locations in the Settings that I can find, but it doesn't seem to affect the SNDH files. Any help?
Thank you for the new release! The first release which correctly applies the Modplug options at startup, yay :) Also great, that you updated the Sidplay2 Engine. 'Fluterror' is nicely played now :)
I just wanted to let you know, that I spotted a tiny inconsistency: On the 'Browse' page the text under 'HVSC collection' incorrectly says '38714 downloadable files.' When I change into this folder and sum up the count for DEMOS, GAMES, and MISICIANS is leads to the correct 40400.
I'm not sure how long downloaded archives have been this way (ZIP/Rar, etc) but in older versions when I would download an archive it would make a blue link in downloads and I could search through the archive by folder or however it was sorted.
Now new archives create a black link with double arrows indicating you can browse it, however for archives with lots of files, like the zip with the large number of .YM files I just downloaded, it seems to only arrange by song name (even though it's sorted by composer in the actual Zip) and in the playlist it seems to search by reference (like "Atari YM.zip@518"), which takes loading songs a long time compared to the old blue links.
I don't know how better to explain the issue, so let me know if there's anything I can describe to clarify.
Thanks for this app. It's completely awesome with better features than similar programs on the Mac or PC.
I'm running into an issue where I can consistently crash Modizer 1.4. When a track is selected manually, the next time that the device locks, whether manually or automatically, Modizer nearly always crashes immediately. I have narrowed down the scope of this bug to the following circumstances:
1. The user must change the track manually. If the track automatically advances from the previous, this bug will not occur.
2. The user is changing tracks with the file browser (the "A" icon). If the file supports subsongs (the "S" icon) and the user changes tracks via subsongs, this bug will not occur.
Further to circumstance 2, this means that I was unable to reproduce the bug while using NSF files as they contain only subsongs. However a collection of music in a RAR or 7z archive (SPC files, for example) will consistently crash the device upon locking. Thus far I have only tested and experienced crashing using such archives.
The device in question is an unmodified 3rd generation iPod running iOS 5. Please let me know if you need any further details or testing.
Before the archives (rar, zip, ...) were uncompressed just after download. what you call a "blue link" is in fact a folder in the iphone file system. In latest version (since v1.3) the archives are not uncompressed but you can access the detail using the ">>" icon.
Actually it's not very efficient for large archives. I'll see what I can do for this. Probably I might add an
option to uncompress files (either just after download or at will).
Since I'm thinking adding a new screen with folders management capabilities I might also implement an "archive uncompress" feature. A kind of mini "iFile" if you see what I mean.
@setzer52: I'm not able to reproduce the issue on my iPhone 3GS, iOS 5...
If I understand well, I should do the following:
1/ launch a rsn file (so an archive without subsong)
2/ change the current file by tapping the "A" icon and then tapping a random entry
3/ lock my device by pressing the power button.
When I do this modizer continue to play the file, I can unlock and come back to modizer or let it go to the next entry...
I'll try to do more tests with more files, but could you just confirm I'm doing it right ?
It sounds like you are taking the correct steps to produce the error. I don't have any rsn files in my library, so I can't confirm that the problem exists with that type of file, but I imagine it works similar to mine. As previously stated, my problem files are rar and 7z files, which may or may not be significant. If you like, I can send you an example, and I'll try to acquire some rsn files to test as well.
Also, at times it takes a couple of tries to get Modizer to crash, but it's pretty regular. I was considering deleting and reinstalling Modizer, but I'll wait for your say so in case you want any more information.
Edit: Just tried and confirmed that I can trigger the bug using rsn files as well.
I appreciate the response yoyofr. Since you're talking about file management, would it be possible to have basic rename functionality? Every once in a while I download a wayward link to a cool archive and it ends up with horrible naming conventions (right now I have the big SNDH one called sndh31lf) and it would be cool if I could just call it something like SNDH archive without having to rename it on a computer, upload it somewhere and redownload it through Modizer.
If you sync with iTunes it should send your crash logs to yoyofr, unless you have that option turned off. It would have asked you the first time you tried to sync and there were crash logs, if you wanted to share them with Apple. I don't know how to turn it back on if you said no though.
Perhaps the crash logs could help him find your problem even if it can't be reproduced. As far as I know, they're anonymous though so it would be difficult to tell which ones were yours. And sometimes knowing why something crashed doesn't help you determine how it got to that point.
That's very helpful to know. I had no idea that Apple sent the crash logs for apps to their respective developers, but that makes a lot of sense and is a good idea. I had indeed turned that option off at some point, so for anyone who also wants to turn it on, you would do so through this path on your iPod (and likely other devices).
Settings > General > About > Diagnostics & Usage > Automatically Send
I have just submitted a crash report for this bug.
I also discovered a whole host of other crash logs that my computer has been saving for this bug. I don't know if these have also been submitted seeing as auto-submission was turned off at the time of those logs.
yoyofr if you would like me to send these logs to you, just say the word.
I'm not sure if it actually notifies him that crash logs are available but there is a section to download them under iTunes Connect. That is the portal developers use to submit their apps and control what information and screenshots show up in the iTunes store.