11-18-2018, 11:47 AM
In a sense, yes, it would be, because I only process the audio file stuff once when the audio file is first imported. I also have a dedicated table for tracking those file paths. If I only process the image command the first time I read the chord pro file after import, that's one thing, but if I have to handle any potential changes to the image command, that's something entirely different. If the user just edits the chord pro file and specifies a different file, how should I go about handling that? Should I remove the file from the database/library that was linked and link the new file? If an absolute path is used instead of a relative path (something you can't do on Windows 10 I might add), do I have to go and update the chord pro file during a library sync, library backup, etc, so that the path will point to a relative path and can be processed properly? If I force users to only link to other files inside the MobileSheetsPro library so that i don't have to process all that differently, how do I enforce that for newly imported files? That doesn't seem like it would work too well in practice.
I just think the whole thing is a huge headache unless I leave it up to users to manage their own files or urls are used instead of file paths (which then introduces other complexities unless the width/height options are not optional in the command so I can rely on that without having to parse the image dimensions). I think the feature becomes a lot less valuable though if I don't force it to be managed as part of the library. So it seems like if I force paths to be relative (by modifying the file itself to have the path I want), and I force the files to be copied into the storage location, then library backup/restore and synchronizing would work like expected. So it's doable, but it seems to me like it's going to be a considerable amount of work to support this for Android, Windows 10 and the companion app.
Mike
I just think the whole thing is a huge headache unless I leave it up to users to manage their own files or urls are used instead of file paths (which then introduces other complexities unless the width/height options are not optional in the command so I can rely on that without having to parse the image dimensions). I think the feature becomes a lot less valuable though if I don't force it to be managed as part of the library. So it seems like if I force paths to be relative (by modifying the file itself to have the path I want), and I force the files to be copied into the storage location, then library backup/restore and synchronizing would work like expected. So it's doable, but it seems to me like it's going to be a considerable amount of work to support this for Android, Windows 10 and the companion app.
Mike