CoreCallback / ItemSequencer

[pbelkner]

In class CoreCallback (<WA SDK>/Wasabi/api/syscb/callbacks/corecb.h) there are events NEEDNEXTFILE and SETNEXTFILE. Does anybody know by which events they are fired?

In class api_core (<WA SDK>/Wasabi/api/core/api_core.h) there are methods

int core_registerSequencer(CoreToken core, ItemSequencer *seq);
int core_deregisterSequencer(CoreToken core, ItemSequencer *seq);

Does anybody know which header defines class ItemSequencer?

[DrO]

those are from the Winamp3 days, they don't apply to Winamp 5 and so whatever you're trying to do will not work with them (even if you could use them).

[pbelkner]

Originally Posted by DrO

twhatever you're trying to do will not work with them (even if you could use them).

How does WA 5 support choosing the next track by a pugin?

[DrO]

if you mean the next item to play, via api_queue (if jtfe/gen_jumpex.dll is present) or by returning an applicable response to IPC_GET_NEXT_PLITEM / IPC_GET_PREVIOUS_PLITEM or some hack to force Winamp to use a specific item (though that often breaks things and is not recommended).

the recommended way is by using api_queue since that's what the jtfe plug-in implements and so allows what it is instructed to do will not conflict with what other plug-ins are trying to do (which will just annoy users otherwise).

[pbelkner]

Originally Posted by DrO

if you mean the next item to play, via api_queue (if jtfe/gen_jumpex.dll is present) or by returning an applicable response to IPC_GET_NEXT_PLITEM / IPC_GET_PREVIOUS_PLITEM or some hack to force Winamp to use a specific item (though that often breaks things and is not recommended).

the recommended way is by using api_queue since that's what the jtfe plug-in implements and so allows what it is instructed to do will not conflict with what other plug-ins are trying to do (which will just annoy users otherwise).

I also tried this. The only example I found so far is the "TRUE Random Playlist" plugin. To be honest, it looks a bit strange to me ...

As it seems the "api_queue.h" is not part of the WA SDK anyway ...

Do you know of another example on how to use api_queue?

[DrO]

api_queue is something i provided and correct it's not in the official sdk as it was made after the last official sdk update iirc though i had provided it separately as part of the JTFE sdk i was providing (which i pulled in february and am trying to bring back along with updating at least 20+ plug-ins). so that explains why it's not easily available but then there's not been a new official sdk for years (though i'm tasked with providing something to resolve that at the moment).

the api_queue.h in that plug-in (which is a mess to try to skim read) is an older version of things but it's about where the current implementation is i.e. it should generally work for what you're trying to achieve.

i have an api_queue example project but i'm in the process of bringing up to date (and to have it included in an official sdk update) so it'll be a week or two before i can provide something that doesn't cause me more work to do (as i'm juggling a load of other projects at the same time which isn't ideal).

[pbelkner]

Originally Posted by DrO

the api_queue.h in that plug-in .. should generally work for what you're trying to achieve.

I did some experiments, and indeed (technically) it seems to work.

Unfortunately I couldn't catch the idea of that plugin. I suspect it subclasses WA's WndPrc in order to catch the event when to choose the next track. But obviously that's not right, and that's why I asked the question: From where I get the event to switch to the next track?

Originally Posted by DrO

i have an api_queue example project but i'm in the process of bringing up to date (and to have it included in an official sdk update) so it'll be a week or two before i can provide something that doesn't cause me more work to do (as i'm juggling a load of other projects at the same time which isn't ideal).

That would be great! Many thanks in advance!

[DrO]

if you're trying to change what goes next at the time of track transition then you're getting into the conflict state between what you want to do and api_queue/jtfe may also be trying to do. the point of api_queue is more to queue up things before the transition happens than trying to override it at the transition point.

if you must alter things at that time then the IPC messages i listed are more likely what you have to use but you're then likely fighting api_queue/jfte for who gets control of things due to the subclassing orders.

if you can better describe what / why (and also the plug-in type) you're trying to do then i can either look to make some changes or advise on the least troublesome way of doing things.

[pbelkner]

Originally Posted by DrO

if you can better describe what / why (and also the plug-in type) you're trying to do then i can either look to make some changes or advise on the least troublesome way of doing things.

I just want to substitute the build-in shuffle by srand()/rand().

[DrO]

so you want to replace what is currently used (which is stored as an internal list on playlist load / modification and can be attempted to be controlled via the preferences) with an override using the same method already being used for generating the number of the item to play...

[pbelkner]

Originally Posted by DrO

so you want to replace what is currently used (which is stored as an internal list on playlist load / modification and can be attempted to be controlled via the preferences) with an override using the same method already being used for generating the number of the item to play...

Currently it's just a kind of "hello world", i.e. the focus is on how to create such a (possibly not very useful) plugin and not on a sophisticated algorithm.