• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ChordPro and images
#11
It's certainly something I would like to add support for. There are some issues that could be presented though, such as: 

1) What happens if the library is synchronized to another library? Do I have to include the linked file as part of the MobileSheets library? If so, that presents some real problems as it's only processed while rendering the file, so I would then have to add it to a new database to track it most likely or do extra processing of chord pro files when synchronizing to see if they link to image files.

2) Similar to #1, what about library backup/restore?

3) Are you using a relative path or absolute path? I'm assuming this feature would only work well for users who manage their own files or have their storage location set to a more accessible folder than the default one. If a user lets MobileSheets manage their files but specifies a different storage location, then changes that storage location later, the link will be broken, so similar to #1 and #2, do I have to handle this appropriately or is on the user to handle this?

If I keep it simple and allow the image to be rendered but I require that the user be responsible for ensuring the file is available, then I can probably add this feature without too much difficulty. If I have to correctly handle library backups, synchronization, etc, then it's going to be more complicated and more analysis and design time will be required.

Mike
Reply
#12
Would the treatment of assets (e.g., images) be different from audio and midi files that are associated with songs?
Johan
www.johanvromans.nlwww.howsagoin.nlwww.hetgeluidvanseptember.nl
Samsung Galaxy Note S4 (T830) 10.5", Android 9.0, AirTurn Duo & Digit.
Samsung Galaxy Note 2 (N8010) 10.1", Android 7.1.2 (LineageOS) (backup).
Samsung A3 (A320FL), Android 8.0 (emergency).
Reply
#13
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
Reply
#14
Maybe it is feasible to first implement a limited form of support. For example, simple filenames only (no path, no url) and the user is responsible that this file exists in the same folder as the ChordPro file.
I don't use Companion so I don't know if it can transfer arbitrary files.

When the user edits the ChordPro file and changes the filename of an image she is on her own. If the song is displayed and the image cannot be found just show a grey area (if sizes were specified) with a missing image icon.

If this feature is too much of a pain to add to MSPro --- well, bad luck then. There are lots of other interesting features left.

In my collection of ChordPro songs, only a few use the {image} feature, and always to include a small piece of a score, e.g.

   

A possible future inline ABC feature could do that as well, eliminating the need for these images...
Johan
www.johanvromans.nlwww.howsagoin.nlwww.hetgeluidvanseptember.nl
Samsung Galaxy Note S4 (T830) 10.5", Android 9.0, AirTurn Duo & Digit.
Samsung Galaxy Note 2 (N8010) 10.1", Android 7.1.2 (LineageOS) (backup).
Samsung A3 (A320FL), Android 8.0 (emergency).
Reply
#15
I agree with sciurius how it might be implemented - image must be in the same folder as ChordPro file, user is responsible to put images there and if image isn't found, just display grey area with missing image icon or simple text like "Image xxx.png" not found.

Also if ABC or MusicXML is going to be supported in the future, images in ChordPro might be not needed anymore.

Tablet: Surface Pro 4, 
Other: Strich BT-FP2, USB-MIDI connection to Kurzweil Forte 7
Reply
#16
Mike, what if we invent a way to embed the image in the ChordPro file?

For example (just a proposal):

Code:
{image id=img1 center}

and at the end of the ChordPro file:

Code:
##image: id=img1 type=jpg width=600 height=84 enc=base64
# /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEP
# ERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4e
# Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCBMbC7gDAREA
# ...
# EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ
# EBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEH//2Q==

MSPro would then only support these type of images, and I think it would be reasonably straightforward for Companion to turn a file link into an embedded image. By 'hiding' the image data within #-comments it will not get in the way of most other tools.
Johan
www.johanvromans.nlwww.howsagoin.nlwww.hetgeluidvanseptember.nl
Samsung Galaxy Note S4 (T830) 10.5", Android 9.0, AirTurn Duo & Digit.
Samsung Galaxy Note 2 (N8010) 10.1", Android 7.1.2 (LineageOS) (backup).
Samsung A3 (A320FL), Android 8.0 (emergency).
Reply
#17
That's certainly an interesting idea. I'm up for trying to support that. So just to verify, you think I should convert any image links to embedded images instead of giving the user control over that, right?  If the relative image link is broken, then I would do nothing when the file is imported or processed.

Thanks,
Mike
Reply
#18
Precisely. And only Companion will have to deal with the actual files. When sending the song file to the device, the file names are gone and the data is included. No tablet editing of filenames that can go wrong, no additional files on the tablet that must be kept track of.

I've made a proof-of-concept implementation in the ChordPro program that seems to work well. It may need another night sleep, though.
Stay tuned.
Johan
www.johanvromans.nlwww.howsagoin.nlwww.hetgeluidvanseptember.nl
Samsung Galaxy Note S4 (T830) 10.5", Android 9.0, AirTurn Duo & Digit.
Samsung Galaxy Note 2 (N8010) 10.1", Android 7.1.2 (LineageOS) (backup).
Samsung A3 (A320FL), Android 8.0 (emergency).
Reply
#19
Okay, this is how far I've got.

The syntax for the {image} directive has a new argument 'id=XXX' that specifies a known asset identified by the id 'XXX'. 'XXX' may be an arbitrary identifier.
For the {image} directive, the asset should be an image.
How the relation from 'XXX' to the image is established is up to the application program.

One way to define an asset is with a special file comment (not to be mistaken with a ChordPro {comment}). Such a comment looks like:

Code:
##image: id=XXX

Minimal, or with all options:

Code:
##image: id=XXX src=im.png type=png width=1341 height=340 enc=base64

which is immedeately followed by the data for the image, base64 encoded, in lines that start with "# " (pound space).

Code:
# iVBORw0KGgoAAAANSUhEUgAABT0AAAFUCAIAAABp2w/aAAAABGdBTUEAALGPC/xhBQAAAER0RVh0
# U29mdHdhcmUAWFYgdmVyc2lvbiAzLjEwYS1qdW1ib0ZpeCtFbmggb2YgMjAwODEyMTYgKGludGVy
... many more ...
# AAd0SU1FB+AEBwgjAAJ9CYIAAAAedEVYdENvbW1lbnQAQ3JlYXRlZCB3aXRoIFRoZSBHSU1QCpgy
# LukAAAAASUVORK5CYII=

So when the user presents a ChordPro file with one or more {image}s, Companion can change the {image} directives and include the image data as shown above. For people that do not use Companion, there are other tools that can assist.

When a song is edited in MSPro, the asset data can be omitted to not clobber the view and/or slow down the editor.

What do you think?
Johan
www.johanvromans.nlwww.howsagoin.nlwww.hetgeluidvanseptember.nl
Samsung Galaxy Note S4 (T830) 10.5", Android 9.0, AirTurn Duo & Digit.
Samsung Galaxy Note 2 (N8010) 10.1", Android 7.1.2 (LineageOS) (backup).
Samsung A3 (A320FL), Android 8.0 (emergency).
Reply
#20
I think that all sounds great. I'll just have to make sure there are easy ways to add or remove images, especially if I'm hiding the encoded image content from the user in the editor.  It's easy enough to add options for this in the tablet app editor, but the companion app doesn't really have a great editor at the moment for chord pro files. So I will need to start adding more  capabilities. I suppose if I parse the file after the user has edited it and they have removed the ##image line, then I can just remove any image data associated with the given id. So maybe an explicit option to remove an image isn't really needed. Adding an image is as simple as listing the name of the image file to include, so users can either write that themselves or I can add a simple option to add an image that lets them use a dialog to enter the data for the image (so that they don't have to memorize all of the supported parameters).

Thanks,
Mike
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


Users browsing this thread:
1 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2020 MyBB Group.