XXHighEnd

Quite some effort has been put in dealing more nicely with CoverArt, especially for those who make a big deal of it (e.g. scanning all the pages of the inlay etc.). It should be noted though, that 0.9v-3 covers "half" of functionalities, hence not everything can be used to its fullest extend without a next version.

The zip to download can be found underneath the screen copies at the very bottom.

The below - to some extend - has been explained with examples here : CoverArt options and their effects (http://www.phasure.com/index.php?topic=540.msg3863#msg3863).

• A new area has been added : The CoverArt Area (see sceencopy below);
  Here all the files are shown belonging to the album and which are not music data.
  
  
• Doubleclick on the file, or rightclick - Open, opens the file.
  When no file association is known for the file extension, you can use a temporay program to open the file with, or set one fixed (in fact, as usual).
  
  
• A music file active in the Playlist Area (like clicking on a track there) will load the CoverArt Area with the files concerned.
  
  
• The same will happen when an item is made active (like clicked) in Library Area.
  Issue : Currently the related files in the CoverArt Area sometimes don't appear. Please just try to click again (and best is to click another item first then).
  
  
• Both above mentioned can be prevented by means of unticking the Show Data checkbox (visible near the bottom when the Playlist Area is shown).
  Not showing the data may be wanted when you browse through all the tracks (from different albums) in the Playlist Area or selecting items in the Library Area, knowing that loading the data consumes (sometimes considerable) time. Another reason would be that your screen has no space to show the CoverArt Area, or that you don't even *have* additional (!) CoverArt files (thus, why wait for them to find and show them then).
  
  
• You will see that three main vertical parts of the screen exist now : the left pane which holds the play control buttons and the main cover of the album, the middle pane which can show the contents of the various tabs (like Playlist Area, Library Area) and the right pane which holds the CoverArt area;
  Each pane can receive a width to your likings by means of dragging the (two) splitter bars deviding the panes.
  Note that initially the CoverArt pane (as well as the related splitter bar) doesn't show at all, and first the right border of the form has to be dragged to the right.
  
  
• When the Playlist Area is active, a small horizontal slider shows at the bottom, by means of which the width of the images in the CoverArt Area can be set. This works the same as the existing slider for setting the width of the images which show in the Library Area.
  Maximum width = 255 x 255 pixels (this is a technical limitation).
  
  
• Since 0.9v-2 it was found that browsing the Library Area had become more slow. This by itself is justified because of the digging up of all the coverart as well as rendering the images as good as possible, which consumes time;
  For both time consuming processes a checkbox has been added to the Settings Area, named respectively Simple Search and Fast Rendering.
  
  Simple Search ticked : There will be looked only for a Folder.jpg file in the album folder or one level iup for multi albums. This is the same as it worked before 0.9v-2.
  
  Fast Rendering ticked : No time will be consumed on enhancing the pictures, normally necessary when they are scaled to another size than as how they originally are. This too works the same as before 0.9v-2.
  Note that at ticking this checkbox side effects occur, like the sizing of images anticipating on being square, and which a normal CD cover (almost) is. This implies that non-square images will show square. Note that this happened the same before 0.9v-2 but you most probably wouldn't notice because only Folder.jpg images would show in those before 0.9v-2 versions and you most probably created those square.
  
  The Fast Rendering checkbox does *not* apply to the coverart shown in the left pane of the form.
  Note though that the Simple Search checkbox *does* influence the coverart shown there, because when you don't allow the system to find the best cover, it just shows the found Folder.jpg or nothing.
  
  There's also a side effect on keeping the Fast Rendering checkbox ticked - but which was there already in 09v-2 - and this is that some pictures which are too small - and which won't allow resizing to a larger size in the area that shows the coverart in the left pane - show in their original size. It's too complicated to explain this, but it just is so (while e.g. the coverart shows as large as you want when it's shown as Wallpaper).
  
  
• When rightclick is performed on an item in the CoverArt Area, a.o. a choice "Show Location" will be shown. Clicking that option will popup a message that shows the path to the CoverArt File.
  This comes handy when you (e.g.) see the best cover possible in the CoverArt Area, but which doesn't show up as cover in the left pane of the form or in the Library Area for that matter.
  
  
• Similarly, both the Library Area as well as the CoverArt Area now show an option after rightclick on the item, "Show Original Location". Clicking that will popup a message showing the *original* source location of the album or file, no matter how many times the item was used to create a Galery Entry from it.
  
  Important sidenote : Referring to 0.9v-3 being "half" of the whole as intended (as mentioned in the beginning of this Release Note topic) things like this are very much related to how the Galeries have been created when you want to change things. One example :
  Although nobody complained about it so far, your humble programmar (yes, me :)) hates it when he has to recreate his Galeries for whatever reason. The trouble you run into then will be very much related to how your source structure has been setup, but since the Galeries are meant to make that better there's the theory that you must think about what to put where (in which Galery). And, this "thinking" has to be done all over each time the Galeries have to be recreated;
  If you rightclick on an item in the Library Area and move the mouse to the Galery option, you'll see a (now) disabled option "Reprocess Transactions" appearing. Also, moving the mouse to Add to Galery and you see the disabled option "Do not add to Transactions";
  These both options (and some more) are the setup to recreate the Galeries completely automatically, which actually is already working but not made available yet. The why (not) is found in the smartest and friendliest way to let this all work, which actually has been worked out, but has to be implemented as of this moment.
  
  Below you may find some other new functionalities of which you may (or will) say "what to do with them if they aren't worked through to my Galery Data".
  
  
• Rightclick on an item in the CoveArt Area (the rightmost pane) will show an option "Rename".
  Btw, this leads to changing the label at the bottom of the coverart item concerned, and you will probably know that this also can be done by means of clicking in that label twice (not doubleclick !);
  
  Note that you would be changing the file which is current, meaning that if the file comes from a Galery you would be changing the name of the file in the Galery, and if the file comes from the original source, you would be changing *that*.
  The reason you would be changing these names, is because your naming was so that apparently XXHighEnd chose the wrong file for the one and only cover. However, when you know that when one of the files is being called Folder.jpg for 100% sure (programming errors not counted) that file will be taken for the one and only cover, you'll understand that there's a reason to change the names of coverart files.
  BUT : When you change the name of an original source file it doesn't work in the Galery derivals, and when you change the name of a Galery file, you will loose the change when you recreate the Galeries concerned. So again, since you are allowed to change the names neatly but there's no way yet to work it through to the Galeries concerned, this is a "half" function at this moment.
  
  When the name of a CoverArt item is changed, the Library Area will be refreshed, and you can see whether your change worked out for the better immediately.
  
  It can't be emphasized enough that a functionality like this urges for recreating your Galeries (or you must apply the changes to the Galeries as well) while the first thing you *need* to do with the next version (0.9v-4) is ... recreating the Galeries. This then is to create the base for next auto-recreations, or in other words, let the system create the Transactions for that, which is not available to you at this moment. :(
  
  Note ! Because of some twirk in something (in the OS -> tested with Vista only), it may take some longer time to rename the file, and it even may happen that the Rename does not succeed of which you will receive a message then. The last item shown in the CoverArt Area is more prone to this than the others. If this happens, just try it again, and best would be to restart XXHighEnd first.
  
  
• Similary, there's a Delete option in the context menu after rightlick on a CoverArt item.
  This is merely meant to delete files like Thumb.db which are from the OS when you let Explorer index the files, and which show just the same in the CoverArt Area and are of no value to you.
  
  See the Note ! at the previous topic; this counts the same for Delete.
  
  
• At rightclick on a Library item, an option "Delete Image from disk" exists. This has now been disabled because before this was used to remove a wrong Folder.jpg, which since 0.9v-2 doesn't need to be a Folder.jpg anymore. See the Delete option above which should be used now really.
  
  
• Many improvements have been applied to showing the one and only CD cover.
  Current issue : At this moment it is not possible to show the coverart of a multi volume album and where the coverart is being hold in an e.g. "Covers" folder at the same level of the album folders. Obviously it is theoretically wrong to structure it like that, but things can be programmatically be done about it anyway. :yes:.
  Later ...
  
  
• It could happen that the track data shown in the Playlist Area was cut at the right side (the track times vanishing).
  This has been solved now.
  
  
• When the !Played Playlist was loaded, the files extensions showed (with no other harm than that the !CurrentlyPlaying Playlist would be contained by that as well).
  This has been solved.
  
  
• The Playlist Area now shows grid lines.
  
  
• The visible quality of CoverArt pictures has improved siginificantly for those pictures subject to a significant resize.
  Note that this reflects the various sizes the picture can be shown in, and that the sizes actually are determined by you at all places they show.
  Now, as long as the pictures are not shown larger than the original is, they show in optimal quality.
  
  
• When the Tooltips checkbox (Settings Area) is unticked, tooltips don't show. However, the important tooltips on slider positions (not shown otherwise) didn't show as well.
  Now these important tooltips show even when the Tooltips checkbox is unticked.
  
  
• The album data at the bottom with the Playlist Area active did not show since 0.9v-2. This has been solved.
  
  
• A message "Pattern error Album" could appear for various (usual not persistent) reasons. This is still so, but now the message allows you to quit XXHighEnd, instead of answering numerous of these messages (ending up in you pulling up Taskbar ...).
  
  
• Since 0.9v-2 "Out of memory" messages could occur. The reason actually was a programming bug, but this message by the OS was as wrong (hence unrelated to out of memory).
  
  
• When the Library button is used to get tracks into the Playlist Area while the Playlist Area was not active and the Playlist Area was empty before this, the "XXHighEnd" indication and version number remained. This has been solved.
  
  
• At copying data to a Galery the coverart files (but Folder.jpg) were not copied from the folder the album is hold in itself.
  The same would apply for physical copying.
  This is now solved (although the latter has not been tested).
  
  

Known issue : At the startup of XXHighEnd a (dutch ?) message may popup telling that "the object currently is used somewhere else" (see below second screen copy). This won't harm, but at that moment at least one file in the CoverArt Area won't bear its image (only the textual description at the bottom of the item).

Generally you could say (or see) that this version is less stable. However, many messages have been built in which could be seen as debug info. Please report them when they occur, so the underlaying cause(s) can be solved.

Edit : An issue was found when referencing albums over a network, and no driver letter is used for the reference, but \\PCName (http://www.phasure.com/index.php?topic=542.msg3882#msg3882).

Edit : Referring to the above, you might want to download the 0.9v-3a intermediate version (http://www.phasure.com/index.php?topic=542.msg3885#msg3885) over the XXHighEnd.exe from the 0.9v-3 zip (below).