I noticed tonight in Configuration, Miscellaneous, Settings that the maximum EndMon time is 32000mS. I would like to be able to set it to at least 60s, ideally a maximum of 90s. 60s is more realistic if you have a 4min or 5min track (or longer!).
I suspect that the limitation here is that the spin control internally has a maximum value of 32767, so because the the time is shown in mS and not seconds, that means a maximum of 32s.
Would it be possible to change this spin control to a) use seconds not mS, and b) set a min. value of 1 and a maximum of 90? Note that the setting stored in mAirList.ini would be stored in the same format as now (i.e. mS), so no backward compatibility problems,
Thanks for the praise; obviously my analysis skills are still intact!
There may however still be a problem. I tried manually changing mairlist.ini last night and changing the EndMonTime to (initially) 65000 (=65000 mS, I thought). This setting produced an actual End Mon time of approximately 68s.
I next tried changing the setting to 60000 (< 65535, right Torben? ;)) and got what seemed to be the same 68s (approx) EndMon time. Next I tried 55000 and got the same results.
Both of these tests were using the File Tagger, and (I think) Build 494.
It seems that the PFL player isn’t using exactly the value specified if it’s a high value. I do understand the perennial problem of telling BASS to go ‘x seconds from the end’ and the pre-scan issues :), but I somehow don’t think (?) that’s the underlying problem.
I will try to do some more testing later and produce a list of actual EndMon times for various values in mairlist.ini; meantime, I thought I would check whether the behaviour I’ve reported above is reproducible by Torben (or anyone else!).
Thanks, as always, in advance.
PS: I will be on holiday next week in the Netherlands. Whereabouts are you in Germany exactly? We’ll be spending a couple of days in Apeldoorn (I hope: to be confirmed) which is the closest we’ll be to Germany. I might just be able to visit you!
Correction: large EndMon times entered manually in mairlist.ini (e.g. 65000) are working AOK. ;D
I always forget that EndMon is calculated ‘back’ from the FadeOut point and not from the very end of the item (D’OH!). :-[
So, all we need is a slight adjustment to that spin control (as I said, a max. of 90s should suffice) and the code which loads the existing value into it from, and which saves the value back to mairlist.ini.
I don’t think there should be any need to change the mAirListScript interface because the format used in mairlist.ini will not change; unless, of course, the variable used is currently an Integer with a limit of ±32767 … that would naturally need to change. I don’t however think many people (?) will be using EndMon in their scripts!
Torben, I’ve been doing a lot of tagging this weekend of tracks of all ages from the 1960s to the present day, and I now know how EndMon SHOULD work. (Don’t be angry with me!)
The tracks I was working with have durations from < 2:00 to > 5:00, and naturally a fixed EndMon time means it is too short for some tracks, and too long for others (!).
SO …
Would it be possible to set EndMon as a % of the track’s duration, instead of a fixed number of seconds as at present? This would make the EndMon time ‘adapt’ to be at a sensible place for all tracks. I think somewhere between 15% and 20% would be a good default setting, with a maximum of maybe 75%?
(OK Doktor Torben, you can stop throwing things at me now!!! :o)
That’s an interesting idea - I remember from time using the Denon DN9xx CD+MD machines that EndMon was set on a “per machine” basis, the CDs 20s and the MDs 5s - when playing songs from MD, the EndMon was never long enough!
Since I don’t know every track I tag that well :D, I noticed that I tend to listen to the final one-third or so to make sure I put Outro after the second-time chorus; or at the end of the singing bit … depends on the track, obviously …
Hence quickly to the notion to define EndMon as a percentage. ;D
Torben: I’ve also had a think about backwards compatibility. If the Config for EndMon adds two new grouped option buttons (captioned seconds and percentage) plus one new control for the percentage amount (maybe a Spin control?), you can make mairlist.ini backwards compatible by allowing two formats for the EndMonTime key:
[ul][li]the existing/proposed mS (e.g. 30000) format[/li]
[li]the new % (e.g. 25%) format, including the % sign[/li][/ul]
You can then use the presence/absence of a % sign in the string when processing it to indicate whether the numeric part of the value represents, er, percent or mS.
OK, this annoyed me again recently (on v3.1.1, b7664), so I’ve come up with an even neater, less invasive solution.
The underlying reason for the ‘problem’ is that the TUpDown (aka ‘spin control’) is limited to a maximum allowed value of +32767.
EndMon time is currently specified in mS, hence is unlikely (?) to be < 1000 (= 1 second). It also seems unlikely (?) that anyone (?) would want or need an EndMon duration longer than 300 seconds (= 5 minutes).
Therefore, the final solution I propose is as follows:
Amend the mAirListConfig dialog to limit End Mon duration to a range of zero to 300. This will be a value in seconds (not mS) and so the label on the mAirListConfig ‘tab’ will also need to be changed (from mS to seconds).
If the current mairlist.ini file specifies an EndMon value >1000, convert it to seconds (div 1000) ‘on the fly’ while mAirListConfig is reading mairlist.ini and loading those values into the mAirListConfig dialog tree during mAirListConfig initialisation; and ensure the (converted) EndMon value is stored when you click Save in mAirListConfig. For example, an existing value of 15000 (or 15999 ;)) in mairlist.ini would be converted to 15, displayed as 15 in End Mon duration in mAirListConfig, and would (after a Save in mAirListConfig) be stored in mairlist.ini as 15.
Amend the other mAirList apps (mAirListDb, mAirListTag, and mAirList itself) so that they will also be able to handle both types of values when reading mairlist.ini, either by multiplying ‘small’ values by 1000 to convert to mS, or by dividing ‘large’ values by 1000 (preferred solution, looking to the future). This ensures that any ‘unconverted’ EndMon values will still work as intended.
Would that be a lot of work to implement, Herr Doktor, or not? To me, it seems the easiest backward-compatible solution to implement. And I could (finally! after all these years!) be able to have a 90s End Mon without crashing mAirListConfig if I manually edit the mairlist.ini value to 90000 (= 90 seconds). ;D
The seconds over milliseconds seems logical to me although I am curious as to why you need about 90sec of End Mon when it’s actual purpose is to simply review the final part of a track, typically to check if it fades/ends/whatever
Unfortunately, only half of the change to allow End Mon to be specified as seconds (instead of mS) has worked.
mAirListConfig correctly converts ‘old’ mS values to seconds, and writes them correctly to mairlist.ini as seconds.
All PFL players (mini-PFL, PFL, and Extra PFL) in all mAirList programs do not handle the new ‘seconds’ value correctly.
If the Fade Out cue point value is non-zero, clicking END MON simply jumps to the Fade Out point (!).
If the Fade Out cue point value is zero, clicking END MON does nothing (except: if the player is paused, it starts).
I tried changing the End Mon value in Config to 30000, but this did not change anything: END MON in all PFL players behaved the same way as above.
Is it only me, or is everyone else having the same problems?
