If all is right this is solved in the next version (0.9x-5).

Found it !

Or at least for the case you showed;
What you did here (I think), was bringing up XX again, and reposition the time slider. But it also happens when you change the volume.
I know, this all goes unnoticed since 0.9x-4, but in the mean time sneakily the file changes. So, at first it plays from the internal drive, and at e.g. a volume change it switches to the external drive again.

If you never touch anything after a first start of playback, all should be ok.

Btw, in the XX log file these two lines exist for each track :

Short Name initiated-1 : I:\Music\ELECTR~1\BRIANE~1.PET\2001-D~1\03-LIK~1.WAV
Short Name initiated-2 : I:\Music\ELECTR~1\BRIANE~1.PET\2001-D~1\03-LIK~1.WAV

and when they would have played as intended they would have looked like

Short Name initiated-1 : 03-LIK~1.WAV
Short Name initiated-2 : 03-LIK~1.WAV

In X3 it is more direct :

Music file found : I:\Music\ELECTR~1\BRIANE~1.PET\2001-D~1\03-LIK~1.WAV

should be

Music file found : 03-LIK~1.WAV

So you can check it when you hear spinup the disks.


Something to do again ...
Peter

No, it doesn't matter that I know of. However, people report more "stability" from Windows 2008 (which is the Server version of Vista).

The only real difference with a 64bit version is that you can use net (!) some 700MB more of memory, which only plays a role for 60 minute tracks *and* keeping everything (hdd) to sleep all the time. This is not the biggest deal though, and I'd choose the most convenient for other reasons (whatever they are).
Think about RDC for instance (Remote Desktop Control) which may come off handy at some day ...

Hi Bengt,

I am fairly sure things changed in this area in 0.9x-4. But I am also a kind of sure in 0.9x-4 still problems exist in this area, but, this would be related to using keyboard shortcuts (or remote control) for Volume or Invert.

So ... before I start looking for non-existent needles in haystacks ... could you please try 0.9x-4 and keep track whether you used a shortcut which doesn't interrupt playback (Volume and Invert are the only ones behaving like that).

Thanks !
Peter

Ok ...

1. Yes. The XP implementation is a kind of surrogate for those not owning Vista. It still might be the best you ever heard (alll to one's own observations, but many think so) but Vista is where it really happens, and where all is explored to all the detail *I* can imagine.
Also, in Vista/#3 the digital volume works, and besides you will be able to do without preamp, you can also use it to more or less (more with more digital attenuation) counteract the analogue volume, which latter just works very different (and to my humble opinion ... wrong(ish)). So, many use a preamp, but include digital attenuation to their likings. By this means alone you'll have quite a bunch of "quality settings", and it really makes a difference. As I said before, you will loose nothing with the digital volume of XX, but, this counts for 16 bit material played onto a 24 bit DAC.

2. Not much different from Vista/#3, but, with #3 all is more sophisticated. There is just more to "spread" there, because the kernel making the sound is another process again. See Description of Processor Core Appointment Schemes. An honest answer though would be : With XP there is much less control, and for the stuff where it really matters, there is no control at all. On the other hand this depends on the setting. Take for example Scheme-1, which just can't be fulfilled with XP (better : #1 and #2) because the audio runs in the middle of the GUI, and it will go along with it. Not so with #3, where, btw. the GUI can be completely removed.

HTH a bit !
Peter

Hi boleary,

Very nice to hear it goes so well for you. Thanks !

WMP playlists currently can't be read, and I guess those kind of things have a lower priority thus far. Later maybe ...

Your observations on the digital volume are most interesting, since the volume itself won't change in XP (or Engine#1 and #2 for that matter). That is, I guess is doesn't ?? The "problem" here is that those little notch up/down buttons are not disabled when they should. I small bug I saw myself the other day.
This does not mean, however, that sound can't change during "Attended" playback (the GUI staying), which is the only means of playback under XP. So ...

So, are you sure this influences sound ? I won't be surprised of these things anymore, but it sure is not intended (and don't be afraid to persist on it !)

Btw, might you use Vista and Engine#3 your observations about using the digital volume instead of (partly !) the analogue volume, sure are true and intended in this case. There's justification for that for sure (my own) ... but this can't be what you are "suffering" from now.
Besides that, using the digital volume in XXHighEnd is by itself 100% OK, because it is, say, special, and does not destroy anything (and that is the reason for the kind of rough ~1.5dB steps). But again, Vista/Engine#3 only ...

Regards,
Peter

Hey Johan, Good !


Uhhmm ... because I have done something wrong somewhere ?
To my knowledge it shouldn't, but if you say it does ... it does. Btw, it is hard to check for myself because I can't hear my disks spin up.

But I will sort that out !

What I talk about here (in this topic) is about WiFi. This is unrelated to IR and a normal IR remote cannot be used. The AutoHotkey stuff is for IR (AutoHotkey Install).

It is a stupid difficult subject.

At last got to this (my Fireface is not connected by standard anymore).

Well, nothing seems wrong to me. Not by listening either.
I checked all samplerates including the Invert versions of it.

Did you find anyhthing additionally ?

Peter

Hi Russ, I have moved your post to the AutoHotkey topic. Because of my resonse to it, I felt it went messy otherwise. Re: WiFi Remote.
Peter

Hi Russ,

Your response above was in the WiFi Remote thread, but since I thought to explain some more about the IR part, I moved your post to here.

If you have a good IR system working, there is no reason to hop over to the WiFi stuff. Well, I think. What you must do though in order to let IR working at all times (meaing : Unattended just the same) is start the AutoHotKey program, and configure that to receive the IR commands and pass those through as keyboard commands again. Without AutoHotKey (or something else for that matter) it can't work Unattendedly.

The downside of AutoHotKey is that it will also overrule the normal Windows hotkeys, and it is for that reason that you'll see the Alt-U etc. being captured explitcitly as well. This is hard to explain ... But concider these situations (all for volume up) ... you would want :

A. Alt-U when behind the keyboard. Attended.
B. Alt-U when behind the keyboard. Unattended.
C. Press Volume Up at the remote. Attended.
D. Press Volume Up at the remote. Unattended.

When nothing is arranged for, A works. B dos not, because indeed no GUI is there, and A works via the GUI.

B works via AutoHotKey. However, in order to let that work (as per AHK's design) Alt-U is globally captured, and it takes away the capturing from Windows itself. This is not what I like, but a nasty habit of AHK. It means, when AHK is running, A does not work anymore !

Because A does not work anymore, a special entry needs to be there in the .ahk config file and it works upon the GUI. It clicks the volume NotchUp button. When the GUI is not there, it starts XXHighEnd with the "U" parameter, XXHighEnd internally pressing that button.

Now C comes into play;
No matter how you arranged for letting that work, for the same reasons I just explained it probably (!) won't anymore once B is implemented. Also note that you need not to implement B for that reason (you never use keyboards) but you still need D to work, and it works with the same implementation (see later). Unless ... unless you can program the remote with the same things as is done in the .ahk file ... start XXHighEnd with the "U" parameter. When the remote can do that (needed for D) while IT AT THE SAME TIME can do C ... and I mean with the same button ... then AHK is not needed. But can it ? I doubt it. It needs the If/Else like similar to the .ahk config file.
So how is C to be solved ? an ADDITIONAL entry in the .ahk file that captures whatever it is the remote sends. So, there's the Alt-U for the keyboard (A + B) and there's the e.g. "Volume-Up" entry for your remote.

Before we can finish C we really must look at D. Why ? well, because the same If/Else is needed as with the Alt-U keyboard command : the treatment must be different for Attended vs. Unattended. In fact, in order to let C and D work, it needs a copy of the entries as are there for A + B, but the captured command is different.

Still with me ? Well, a major point is that for me this is all theory because I can't find a decently working IR receiver including the necessary reprogramming at the PC side. Or without reprogramming but passing through the commands to something that can capture it, which AHK in theory (!!) should do.
I have 4 IR sets now, and my latest aquisition has been a complete (Terratec) SAT h.264 receiver card just because of the programmable remote it contains. Am I stupid ? yes. But again it works too flakey, meaning yes/no/sometimes. It has to be for Vista too, and that may matter.

Peter

Correct. One time Read denotes one time of (the intention of) starting the track.

You have probably seen it, but if not : WiFi Remote.

All,

Although I haven't spent much words on the WiFi remore business in the 0.9x-4 release notes, I can imagine a 100 questions.
On the other hand, maybe nobody owns a WiFi remote.

Ok, I possibly made it for myself only (and for the Philips Pronto TSU9600 I own), but I think it currently works flawlessly which I sure can't say of the IR solutions I tried.

The XXTCPSrv.exe from below zip I created myself, and it is a so called "TCP listener". It waits for a connection on the port given (which can be done now), answers to it, and next waits for a command. Note that it assumes that the connection will be closed by the client after this (the client being the remote, amd the Listener being the server doing absolutely nothing while waiting).

It seems a quite undoable task to explain just all, but might you have a WiFi remote and wish to get it going ... waiting for the questions in this thread.
One thing : this solution (as how it is now) does not execute commands on a running XXHighEnd. This, translated into the terms we are familiar with : it works at Unattended only ! This will change in near future, but we have to start somewhere, and that is at Unattended (being the most difficult obviously).

From here on I will try to create similar for IR solutions. But later.

Oh, for those who want to start off without questions : don't forget to allow the port given to pass through the firewall.
And don't forget ... whatever your remote passes at a certain command (being a string like "Volume_Up"), it can be obtained in the XXWiFiRemote.cfg configuration file. This means you don't need to reprogram the remote. But if you can, you can do that too of course.

Lastly, and to be clear : Currently this is all totally unrelated to the AutoHotKey solution. It could, it can (for better transparency), but I just did not.

Peter

PS: If nobody responds because actually nobody has a WiFi remote or can deal with it, at least I am happy with it. So no problem there !

Dear Buggy Russ,

Can it be so that you changed the volume or Invert during that last track ?
I have been testing it tonight, but can't let it go wrong. However, the other day with the endless repeat I did change volume ...

Please don't start to explicitly test it, because I still think that it is related to that "one but last" situation I spoke about. So I will first solve that, and then we'll see further.

Peter