... or IOW the marvelessly into dutch translated "naast elkaar" bug.

See http://www.phasure.com/index.php?topic=328.msg2110#msg2110 for Release Notes.

Well, at least I have found a PC to copy that behaviour. So this time I must be able to solve this myself Johan !
You must be glad ... 

Btw, is there anyone *not* having this ?

Do not download this 0.9t-3; use 0.9t-4 instead !

Ok, let's say that a lot of time was wasted on 6 long says of implementing a crucial part of Unattended Playback : visualize what is playing.
You could say that after 2 days already there was no point of return because of otherwise two days wasted.  Well ...

• Some graphics were applied around the CoverArt (as a Wallpaper) in order to show data like the Album playing, the Track playing, the running time of the Track, whethers it's a WAV, FLAC, MP3, the bitrate.
  Tick the checkbox "CoverArt as Wallpaper" in the Settings Area to let it all work.
  
  
• The size of the picture can be set in the Settings Area by means of the Height.
  The default is set to 394, which is equal to a 480 height display that includes the Taskbar, and which allows for the data mentioned above to be in borders around the CoverArt.
  You may like this border, or you may not. If really not, please let it know ...
  
  
• A major technical problem was the scaling of the picture while at the same time the data (mentioned above) should not. Ok, it was done.
  Please note that currently this works the other way around as well : when you could work with really large pictures (because you just have a large screen), the data could show larger. It can be a future setting (easy job now, but not sure whether it's really needed).
  
  
• Mainly with *larger* original CoverArt pictures needing downscaling because of the smaller size wanted, rendering takes place to keep it looking good.
  Just compare with the picture which shows within XXHighEnd itself, and see the difference (it needs pictures which are really large like 1280x1024 and text to make this very obvious).
  
  
• Some effort has been put into the fact that the above needs some cpu power that originally implied one or two hickups in playback when the picture was formed. This has been solved, but, with "you" it might still cause problems.
  Please let know if this is so.
  
  
• A lot of effort has been put in the various states of the player versus the display as you are used to it, hence how you want it when the display would not be used for audio playback. You will see the merits of this at using it all (especially when it does not work out ).
  
  
• The most effort was put into the hiding of the Desktop Icons. This by itself already is a task which is very difficult since XP SP2, but not having it as a toggle only (hence absolute directing it to Hide or Show) is another. Ok, it works.
  Note that officially it cannot work with Windows2000, but this was not tested. If indeed it does not, an error will follow; please let know if this is so indeed.
  
  
• The Main Area (the left part, always visible) now contains a small button with an "I" caption. It toggles the Desktop Icons Off and On.
  Use that button to your conveniency, especially when the Icons should show while they do not.
  
  
• An advise : The CoverArt will show on a blank screen. However, any set color as a background (instead of a Wallpaper) will be respected. So if you want a color other than black, set that color (Display Settings - Desktop Background).
  
  

It seems -since the latest few versions- that XXHighEnd in its current stage is much less prone to variations of Q1 and Invert. Is this your opinion too, BUT were you used otherwise, please let this know.
The explanation of it would come down to the player being itself inheritantly "better", therewith narrowing the borders of variation with e.q. Q1.
Anyway, this 0.9t-3 version seems to sound with all the ease there is, which is the most pronounced at UnAttend Playback the Desktop Icons not showing (read : before UnAttended Playback created kind of the opposite, although it was very dynamically).
If it is your opinion that this ease is already there with Attended Playback ... you are most probably right.

Possible issue : When 0.9t-3 is started the first time, an error message may appear which is related to the checkbox in the Settings Area "CoverArt as Wallpaper". If this is so, quitting XX and restart may already solve it, and otherwise ticking this box - quit - restart (and untick to your likings) will solve it.

Happy listenings !
Now up to some important stuff ...

Hi,

At this moment I don't even start to comprehend with what's happened, but I'll help out by PM.

Sorry for the inconveniences !
Peter

Of course Johan. The worst thing that can happen is that you have two instances of XXHighEnd running.

I have got this working, but it can't be different than with a delay of about 10 seconds ...

Hi Johan,

Do these errors also occur with both priorities to Normal (or better : "Nothing" after a reboot) ?

Hmm ... I think so. And why not.
Good idea.

To all of you, from me too ... I hope you have some very special days coming ...

To Gerner especially : thank you my friend. I am very sorry you missed your holidays with your wife in a special place. I dedicate below picture to you.
Now go and do as this part of the forum was created for !



Peter

Hi Roni,

Maybe you use Engine#1 under XP ? There is a limit of 64MB (original WAV size = just over 6 minutes) in that situation ...
If so, XX should hop over to Engine#2, but now your sound device has to be set as the Primary Device.

Peter

Here again is a version I wanted to preserve because of its (IMO) fine sound. Mind you, with *Attended* playback.
Put the XXHighEnd.exe coming from the zip in your 0.9t-0 folder.

In the mean time a few things were added/solved :

• Cue files can now be loaded from the Library Area.
  
  
• The problem with tracks (or path names) with diacritical marks is definitely solved (and loading of such albums/tracks won't take longer anymore opposed to not containing diacritical marks).
  
  
• Cue files containing diacritical marks took very long to load, each track again (could be 30 seconds). This is solved per above solution.
  
  
• Meta data (.mta) tracks as contained in Galeries now can be selected by means of Explorer (not only from within the Library Area (rightclick on the coverart - Show/Load tracks, but also directly from Explorer - drag).
  
  
• A bug is solved causing the first Track Title of a Cue file album showing the same as the Album Title.
  
  
• A bug is solved causing very small Track Names (like Mu) to error out with Cue files.
  
  
• A bug is solved, not allowing Physical Copy by means of selecting without Checkboxes.
  
  
• Once the Library Area contains a list of Albums/Tracks, it is the intention that when you Quit XX, they are reloaded there at the next startup;
  They were, but depending on what you did not in full. This is solved now.
  Remaining issue : when you quit XX with a text to search filled in the field concerned, at a next startup the "full list" comprises of that implied selection only, and a next Search with empty search field really is required.
  
  

Hi Andrey,

The effects you describe are not related to what and how Q1 influences, nor does it imply that Q1 is wrong;
What happens is that you cross boundaries, btw those boundaries being different for everyone.

If you could set the buffersize of your DAC, you would know (or better understand) what could be happening : the buffersize does not cope with e.g. the samplerate. Although all is very logic, it is hard to explain (for me anyway), but maybe the easiest way to explain is this :

When the sample rate is doubled, twice as much data has to pass the DAC. This is an easy one.
Not easy to see, is that this requires a twice as large buffer at the same time. I mean, the twice as much data, passes twice as much just as well, so why needs the buffer to be larger ? but it is so ...

Similar things happen when you overdrive Q1. You can overdrive it towards the bottom e.g. -4 (say, the buffer needed there can't be smaller than it physically is), and towards the top e.g. 30 (say, the buffer needed there can't be larger than it physically is).

Of course I can imagine that you can't understand *why* this is so, but please trust me *that* it is so.
Anyway you need to find the boundaries for your chain (plain distortion, where skipping/repeating of even 1 sample I call distortion), and in between those boundaries you can slide the Q1.

What makes it extremely more difficult, is that -as the past proved- the boundaries vary per XX version. To me in the end this is logical, but not much convenient. Anyway this is because of working with super-low latencies, and in fact the Q1 "setting" becoming instable because of environmental influences. As I said elsewhere, the frequency of refilling the DAC's buffer we work with comes down to once per 1 ms. This is the same as the latency of 1ms with which every audio mastering engineer would love to work with. Here, however, things go even way further, because here it is not about pushing samples through in a short burst (like a midi keyboard's note), but a constant rate of that 1ms and NOTHING allowed to go wrong (for in fact hours).

I hope I am not too misty(fying), but the main thing is : nothing is broken and all is to be expected.

Peter

Hi Ava,

I must honestly admit that for me myself the logic has gone since indeed PlayerPrio changes more than the player alone. That is, I have to set my mind to obtaining the logic explicitly (which is not a good thing). But what happens is this :

First, for conveniency, let's define "Player" as "Controlling section". That would be the graphical user interface you see on the screen, but it also controls what to play when, provides the Library functions etc.;

For Engine#1 and #2 counts that the sound coming from those are provided by "threads" (a technical means of providing processor capacity in a dedicated area, also implying virtual parallel processing next to other processes/threads).
Now, if you give low(er) piority to the Player, the threads producing the sound get cpu cycles more easlily.

For Engine#3 in fact the same counts, though technically (and for techies) it works differently, because Engine#3 runs in a separate main process. However, still the same is applied : the Player (controlling section) could be given less cpu cylces than the process that produces the sound.

In either case all is applied to the whole system : all processes/threads not producing the sound (like the "Player" = XXHighEnd.exe) would receive the low(er) priority, while the process/threads producing the sound receive a higher priority.

Of course above is so when PlayerPrio is set to (e.g.) Low and ThreadPrio is set to (e.g.) RealTime.

The most important is the ThreadPrio setting relative to the rest of the system (the latter set by PlayerPrio). So when ThreadPrio is higher than PlayerPrio, the process/threads procuding the sound get cpu cycles more easily.
Note that some (or at least with other players) perceive better sound when the sound producing threads receive a LOWER priority opposed to the rest of the system.


Concluded, what you see is by design, but your brain told you to set the (relative) priorities just the opposite of how it should be (my problem too).

Peter

Hi Andrey,

With Unattanded it just does that, unless the whole Playlist has been played, then it shows all again (by design).
I could do the same with Attended Playback ...

Oh ... I am sorry. But I thought you activated your laptop as well ...