Jump To File Extra (JTFE) Discussion / Bugs / Updates (1.33 Build 1216 - 16/12/2013)

[DrO]

will add it in for the next release (whenever that happens). i had the jtf window in manage mode instead of search mode at the time and forgot it's not there for the search mode handling.

-daz

[Stone Free]

Excellent, Thanks that will be fantastic.

[mizr3en]

Originally Posted by DrO

#1: not viable since it'd break most of the listviews functionality (plus would be a nightmare to implement). as such the send to menu is the safest and easiest way to implement such functionality. however i have possibly thought of implementing the ml_enqplay plugin into jtfe (which would allow me to possibly insert a menu item in place to do what's needed but that plugin isn't complete yet so i won't be looking into that for a while)

#2: look at the shell options page in the preferences for that functionality

#3: not quite sure how jtfe would be responsible for that since the plugin will try to use the appropriate apis where possible for passing a title with any files (unless you've got reading of playlist titles off until they're played or something like that)

-daz

I was wondering if there has been any progress on adding a hotkey to do the same action as right-click>send to:> add to queue from media library - in my opinion the queue functionality in itself sets Winamp apart from every other media player but I'd rather not drag files to the playlist and queue with the middle-mouse button or "q" key if I could just use a hotkey from the ML... I understand this may not be a simple task to complete but it's been 5 years so I figured I'd ask The other reason why I ask is because I'm working on modifying someone else's touchscreen skin and can't drag and drop to the playlist - perhaps someone knows of a way to replicate a menu path just like you can replicate hotkeys (CreateObject("WScript.Shell").SendKeys "^%q" to let the click of a button replicate Alt+Ctrl+Q).

Thanks,

mizr3en

[DrO]

i've not done anything towards it since as per what was quoted, it's not viable since there's no way from a hotkey to query the selection within a library view (if it's even set to that) to then be able to queue up those items.

even if it gets added to the ml_enqplay plug-in, adding a global hotkey wouldn't really work since it comes back to the same issue as trying to do it with this plug-in.

not sure where you're getting the 5 years thing from since you've only been registered for 2

-daz

[mizr3en]

Thanks for the quick response. I just searched through the thread and didn't find much about this topic since 2006 (the quoted post), figured someone might have worked on the functionality since then.

mizr3en

[DrO]

i suppose it could be done by hacking into the library views at a low level, but that's just not something i've time / inclination to do and would be too version specific so would probably cause me more issues than it'd be worth it (assuming it'd work to start with).

but doing it properly without hacking things, etc then there is no way to do it and i'm not expecting anything like that to happen in the next 5 years to come, heh.

-daz

[DrO]

1.2.5 (Build 1160) is out:: release info

------------------------------------------------------------
Download v1.2.5 (Distro Build for 5.57+ only)

------------------------------------------------------------

• Added IPC_GET_JTFE_QUEUE_UPDATE to notify when there are changes made to the queue contents (details will follow in updated sdk)
• Added checks on start-up to attempt a refresh of the icon pack (if one is specified) after a Winamp update
• Added 'shift' handler to up / down queue management buttons to change them into a move to top / button respectively
• Added view file info (alt+3) option to the main jtf window right-click menu (now matches with the management views)
• Changed queue management buttons to be disabled when there are no appropriate actions available e.g. empty queue
• Fixed handling of adding of urls to the queue when using drag and drop from the library
• Fixed jtf window not selecting the current song if the first search result on opening in some situations
• Fixed the [<<][>>] buttons on the alt+3 dialog appearing when they should not be in some situations
• Fixed the skinned jtf and queue manager windows not appearing correctly at times (should resolve jtf window not appearing always)
• Fixed possible crash when dragging files onto the queue if there was no length obtained from the file
• Fixed queue position not showing in the playlist editor (v1.2.4 issue)
• Fixed crash on loading when queue position not showing in the playlist editor (v1.2.4 issue)
• Fixed 'shift' handler for up / down queue management buttons not working in the queue manager window (v1.2.4 issue)

Currently this is only available in the 5.622 release and will sort out a separate installer + sdk installer update during the next few days. Also i've not changed over building of the plug-in with VS2008 (like the rest of Winamp) instead of MSVC6, so the current compile will only work on 5.57x and up - debating if i keep support as this or not...

[edit - 5th Nov 2011]
Have updated changelog and merged the v1.2.4 changes in with v1.2.5 which is now available for separate download.

-daz

[jamesyov]

"Display
Use text formatting in the playlist: Determines how to display the text and queue position number for queued items in the Playlist Editor window."
Until this new version it worked fine. Now, when you click middle mouse button in PL there is no number (que), but only background color is changed (if enabled). I'm using this option a lot and I really miss it. HELP

[DrO]

bugger, i thought it was just an issue with my setup after reviewing a load of plug-ins causing that *shrugs*

will try to work out what's gone wrong and get an update done when i can.

-daz

[DrO]

ok, i think i've found the cause of the issue with the queue position not working - another fallout from the change in the compiler used to build the plug-in. will post an updated version once i'm certain there's nothing else at fault with the plug-in, etc.

-daz

[DrO]

have released v1.2.5 (build 1160) which should resolve the issue with the queue position not appearing (sorry about that).

-daz

[jamesyov]

O.K. It's working again. Thank you for such a quick reply. And that's why forums like this exist and, also, that's why WinAmp is still the best.
AVE DrO!

[naumaxos]

the "prevent winamp from scrolling current file into view" button does not work for me for the past 2-3 versions...

[DrO]

first thing, you're using the first instead of second 5.622 release (build 3188 instead of build 3189). so would suggest you re-download the Winamp installer and then install the newer JTFE version from http://forums.winamp.com/showthread....32#post2813132

if that doesn't resolve things, then from your list the following are ones that i'm not sure about and might be causing it to not work (something i cannot replicate):

MessengerAmp v3.0 [gen_msn.dll]
Winamp Notify Plugin v0.5 [ gen_wanotify.dll ] [gen_wanotify.dll]

you can try by renaming them from .dll to .off and see if it still happens. if it doesn't then you'll need to rename one back to .dll and try again to determine which one causes the issue and see if there is an updated version of the plug-in available (or try to contact the plug-in author).

-daz

[naumaxos]

i updated and uninstalled both but it keeps happening . i'll try a clean install
--clean install did the trick so far so never mind

[DrO]

maybe a setting from one of those plug-ins or something else was conflicting with it. as the only change i can see between the old and new plug-in list is the removal of the 2 plug-ins, the current jtfe build and the native ipod plug-in is now present (though that shouldn't make an difference).

oh well, if it's working ok now then that's the main thing.

-daz

[naumaxos]

that's strange....the bug came back after the clean install when i loaded my "all mp3's" (~70000 songs)...even after a new clean install without any plugins,visualization or even any change in preferences (except of course the "prevent winamp..." check)...
i'm not sure what use a plugin list would have now but any information needed i'm ready to provide

[dizze]

Sorry for (another) first-post-helpseeker, but I've been experiencing this issue with Winamp + JTFE for a couple of times now.

I'm using Winamp v5.61 + JTFE v1.2.5.

I want to select the next file to play by selecting the playlist entry and pressing "q", but even if there's the number ([1], [2], etc.) appearing on the right side of the playlist, and the queue list in the preferences is listing the queued files as I selected them, Winamp won't play the queued order. Instead, the regular playlist continues playing.

I've tried a full reinstall, a reinstall of the plugin, and variations of the JTFE-settings, but I just can't get it to work properly.

I've attached my One for Nunz plugin list in case there might be any interferences.
I hope anyone here can help me out

Thanks a lot!

[inspire]

hi,

I'd like to check the JTFE version with

code:
UINT jtfeVer = SendMessage(plugin.hwndParent,WM_WA_IPC,0,IPC_GET_JTFE_VERSION);

But what's the pattern behind the return value? Especially, what's the return value for version 1.2.4? I'm looking for something like

code:


UINT jtfeVer = SendMessage(plugin.hwndParent,WM_WA_IPC,0,IPC_GET_JTFE_VERSION);



if (jtfeVer < 1.2.4)

   ...

else

   ...

thanks!
Martin

[DrO]

for v1.2.5 it returns 0x1020050.

it's formatted as 0x<major>0<minor>0<sub><build_specific> where <build_specific> can be used to identify sub-versions of a release like was done with the 1.2.4 builds e.g. 0x1020040 (1.2.4 Build 1158) and 0x1020041 (1.2.4 Build 1159).

though why specifically do you need the version # of 1.2.4? especially when it's not directly offered and i won't support it (which is why there's a 1.2.5).

-daz

[inspire]

ah thanks so far!

I need this because here you implemented a feature for me, which allows to recognize changes made in the JTFE queue. And I want to display a message if this feature is not supported by the currently installed JTFE version.

But this is strange. Is it not possible to compare UINTs?

The following if statement never returns true, even with version 1.2.5 installed:

code:
UINT jtfeVer = SendMessage(plugin.hwndParent,WM_WA_IPC,0,IPC_GET_JTFE_VERSION);



if (jtfeVer >= 0x1020040) { // <= always false

	genjtfe_queue = IPC_GET_JTFE_QUEUE_UPDATE(plugin.hwndParent);

}

[DrO]

i've probably screwed up the version check in the example since the version is returned as a LRESULT from the windowproc (which is generally a LONG_PTR). though i would make sure that you're getting the correct value by printing the version in hex.

-daz

[inspire]

printing the version in hex? Something like the following?

code:


LRESULT const lresult = SendMessage(plugin.hwndParent,WM_WA_IPC,0,IPC_GET_JTFE_VERSION);



std::ostringstream oss;

oss << std::hex << lresult;



char buffer[60];

sprintf(buffer, "%x", oss.str());

But here in the buffer is always character sequence "30363035" ... for every JTFE version. Maybe you can show me what exactly you mean. Thanks :)

[unemtfos]

Noticed this on 2 computers recently, both with JFTE 1.2.5 and Winamp 5.623 - if I untick the highlighting, the text doesn't appear in PE (default format or variations). Now maybe this is new or maybe it's been like this for many versions and I just didn't notice, but on another computer I have an old Winamp 5.35 with an ancient JTFE that lets me have the text formatting without any highlighting. I did try a few re-installs to see if it was a corruption, but no difference. Is this the way it is, or should I keep looking for a problem with my install?

[DrO]

reproduced *meh*

it should be showing the text without the highlighting being enabled so must have come in around 1.2 when all of the internal handling for such things were re-implemented.

will have to find some time over the next week or so to look into it fully.

-daz

[unemtfos]

That was a quick reply - Thanks. It just looks better to me without the highlighting.

[inspire]

hi,

the IPC_GET_JTFE_VERSION macro is defined in a file called "wa_jtfe.h" but I just have an old version where it says

code:
#define IPC_GET_JTFE_VERSION        0x000   // (not implemented)

where can I find a new version? it's not in the jtfe sdk.

thanks,
martin

[DrO]

whenever i get around to sorting out an update of the plug-in then i'll update the sdk at the same time, but at the moment i don't have the means to sort it out or just copy+paste that part (especially as my machine has decided it wants to repeatedly die very few hours).

-daz

[inspire]

ah okay. I just assumed you already had done so because 7 posts above you told me how to check the jtfe version

[DrO]

i cannot remember what i have or haven't done in all honesty and as i infrequently get to even work on them nowadays i can never remember where things are at or not (even when i've made notes).

-daz

[inspire]

Hi,

I've just updated your JTFE SDK but in the newest version (28_09_2010) but there doesn't seem to be the file "Agave/Queue/api_queue.h". In fact, the whole "Agave/Queue" folder is not there (and it's doesn't exist in the Winamp SDK). Can you tell me where I can find it?

Thanks!

Edit: the file "gen_api_queue/api.h" is looking for it.

[DrO]

first out of band update of this plug-in is now available - v1.33 Build 1216 which fixes the skinned mode not working as of the last Winamp v5.666 Build 3516 release.

[muppet]

As always, Thanks DrO.

[Jimekus]

Dro,

I got Winamp.5.666.3516.rar in order to test your plugin. My Ingrid On Winamp Final, controls two instances harmonically; beatmixing live, Spotify-like with 3000 to 33000ms crossfades. The FindWindow(WinampClass, WindowName) is copied to an Ingrid Status bar. The Slave AutoDJ started displaying this as almost all question marks. By looking at the minimized Winamp thumbnail hovering over the TaskBar, I confirmed it to be Manadarin, or some such UTF-16 characters passing through the Window title bar. The text changes independently of track length. This text is replaced by the normal ASCII Title as soon as the Winamp window is shown opaque and then my status bar can retrieve correct title. Let Winamp become transparent and the leak resumes. Being suspicious by nature, I found evidence that this is a major security breach. Going back to Winamp5.663507.rar immediately fixed the WAN leak. Ingrid's first Winamp instance was unaffected.

Please forward this to the right forum. Thanks.

Jim

[Jimekus]

The earlier Asian glyph problem is partly solved. It may have been a plugin and a reinstall closed the exploit. Now however, It's changed from Asian Glyphs to Short MsDos Filenames, and still prevents my IngridMixSync from being able to go live. I have to uninstall back to 5.66.3507 unless there are suggestions. Winamp 5.666.3516 cannot pass my tried and tested systems.

Back to your plugin, DrO,

I came to explain how I finally plan to integrate your queue in Ingrid (my project). For 9 years, until now the JTFE Queue sets WA_SetMANUALPLADVANCE to Zero, so there's no interruption by Ingrid. This leads to end-to-end mixing, which can sound terrible and needs to be fine tuned.

I don't need it but my daughter wants to play Albums. I can get these using JTFE, from which I then save a selection to disk and drop it into the queue. This way my full playlist by Key/Bpm is preserved in ram.

I have an old interim working method which enqueues the selection to the end of the playlist and from there my harmonic beatmixing is flawless and eventually shrinks the huge playlist back down to size. Its not finished and forgets stuff if shutdown. I was also looking for an extra string to my bow, in a way that doesn't involve playlist maintenance.

InGrid Sub LikeLessThanThirtySecondsLeft() I need WA_SetMANUALPLADVANCE to be delay set to One when Ingrid knows the next track is queued. The delay ends when the next track starts then immediately is stopped. I'm hoping that the JTFE queue should also be resilient and can be looked at in entirety, not just the next item for first platoon volunteers. From touch, Live Mixing is analogous a Line-Out in Rugby, formed by two equally matched platoons of items.

Is IPC_EOF_GET_NEXT_PLITEM the best means to knowing if the next item is from the JTFE queue?

Imagine arranging with Ingrid. You see Tumbleweeds rolling together, on each there are all items laced around each in Key/Bpm order. Like-surfaces are highly attractive to similarly attired tumbleweeds; imagine long slinkies of playlists over a cat's cradle upon cat's cradle in a dance.

There are snakes and ladders type disruptions above 3% tension, which are paid for by a random one third drop in grove. A one time two into three step gait shuffle. This seems to lead to a momentary loss in beatmixing quality, but is in fact a higher order bounce in dimension. The new gait is quickly back with the patient listening. Try it sometime. Dance two steps beside your friend's three steps, or the other-way round.