Bugs with addon api...

Russ · Sep 9, 2006, 12:42 AM

There still (3538k) appears to be some bugs with the addon api, but some of them only show up on mutli-card systems, so it is hard (for me) to figure out exactly what is happening -vs- what is supposed to happen with an addon on multi-card systems (since I have only a single card).

Issues:

Per Device Addons (only):
----------------------
The value of "p" in init() is supposed to be the device number, but on my system the value is always -10. (-1 for System Wide addons, which is expected).

Up until save_settings() is called the first time, kx_manager->get_current_device() also results in a value of -10. Only after save_settings() is called the first time, does the function appear to return the current device. (it does appear to return the current device for System Wide addons during init() (as far as I can tell anyway)).
----------

System Wide addons (only):
----------------------
load_settings() is never called.
----------

Both:
----------------------
Registering the addon reports that 2 addons were registered, even though there is only a single addon.

The return value from init() seems to make no difference. I tried returning a value of -1 (as well as other non-zero values, for testing purposes) and the addon continued to load normally.

It is unclear as to how the addon is supposed to function when it is a System Wide addon -vs- being a Per Device addon (and it does not seem to function in such a way that those terms would suggest).

i.e.
- "System Wide" sounds like it would mean that there is a single instance of the addon, shared by all devices. However, when tested on a system with two cards, there appeared to be two instances of the addon loaded at the same time (both shown on the menu). Also, I was getting some strange results when calling kx_manager->change_device() from the addon (different from the results when doing the same thing in a per device addon).

- "Per Device" sounds like one of the following scenarios:
One instance of the addon is loaded/used for/by each device (so multiple instances would be running at once).
-or-
One instance of the addon is loaded at a time, and when you change devices, the previous instance is closed, and a new instance started.

I am not sure which of the above (per device addon) scenarios is supposed to be used, but as far as I can tell, there appears to only ever be one instance of the addon loaded, and the only thing that seems to happen when you change devices, is that save_settings() is called (I am not exactly sure what happens when you change devices with a System Wide addon, as I have not had a chance, as of yet, to see the debug output under that scenario (on a multi-card system)).
----------

Again, much of this I could not test myself, since I have only a single card, but with the help of Maddogg6, some testing was done on a mutli-card system, leading to some confusing results.

I will post more info here if/when I have more info.

BTW: It would be good if there was a function to get the number of devices (and device names), rather than having to enumerate them manually.

-Russ

Russ · Sep 9, 2006, 06:40 PM

Another thing that would be useful is a IKX_DEVICE_CHANGED notification (maybe a Generic Event like IKX_DSP_CHANGED), as currently there seems to be no way to detect this. Although save_settings() is called when the device is changed, it appears (again this is hard for me to test) to be called before the device is actually changed, so calling kx_manager->get_current_device() would not tell the addon what the device number is, that it is changing to. So, some kind of notification of a device change, that fires after the change is complete, would be useful.

-Russ

**Eugene Gavrilov** · Sep 13, 2006, 06:30 AM

init:
* tried to fix that. pls check. for global add-ons: p=-1; for per-device: correct device id
+ if addon->init() returns non-zero, addon is no longer loaded (the DLL might be still in memory)

load_settings:
hm.. there was a bug with KX_SAVED_ADDONS flag that was cleared in the default save/restore settings dialog (since there's no such option visible)
note that if KX_SAVED_ADDONS is not set, per-device save/load addon settings are not executed

IKX_DEVICE_CHANGED:
added. it is sent to all add-ons whenever user or another add-on change current device
===
"It would be good if there was a function to get the number of devices (and device names), rather than having to enumerate them manually":
-- at the moment the only way is to:
for(i=0;i<MAX_KX_DEVICES) {
ikx_t= manager->get_ikx(i); if(ikx_t) ikx_t->get_device_name() }

you can also use iKXManager::create_devices_menu() if necessary
==
per-device vs global add-ons:

per-device addon is created for each iKX instance and is present in memory
that is, an example:
there are two add-ons registered: system-wide & per-device
there are 5 audio cards

on kxmixer startup, it will create one system-wide addon and 5 per-device ones
system-wide addon should acquire iKX pointer based on its own logic (either by allowing the user to choose, or by acquiring current device etc..)
per-device addons use the dev_id value specified during their creation
===
due to a bug in per-device/system-wide handling, I added new flag - KXADDON_SYSTEM_WIDE (=2) that needs to be specified for system-wide addons

E.

Russ · Sep 13, 2006, 11:19 PM

Ok, I will test those things in the next update.

So it is clear, as is stands now, load_settings() is called for Per Device addons (it is actually called multiple times for the same addon instance). Also, it does appear to be called for System Wide addons, but only when kxmixer is started with the --startup command line switch.

i.e.
I created a basic does nothing addon, to do some testing with. Here is debug output of that addon on my machine (single card), under some different scanarios. I added a GUID string, that is created in the addon's ctor, as a member variable, to differentiate between different instances of the addon (included in the debug output).

Code:

*** kxmixer --startup (per device addon)
addon: [ctor] [Type:  Per Device]       [af7fbe0b-8060-45d2-bd14-cd718c0d56a1] 
addon: [init] [p= -10] [NumDevices: 01] [af7fbe0b-8060-45d2-bd14-cd718c0d56a1] 
addon: [load_settings]                  [af7fbe0b-8060-45d2-bd14-cd718c0d56a1] 
addon: [ctor] [Type:  Per Device]       [77aea5e4-cef4-4e58-937c-c21a6ad3c7fb] 
addon: [dtor]                           [77aea5e4-cef4-4e58-937c-c21a6ad3c7fb] 
addon: [load_settings]                  [af7fbe0b-8060-45d2-bd14-cd718c0d56a1] 
addon: [save_settings]                  [af7fbe0b-8060-45d2-bd14-cd718c0d56a1] 
*** exit kxmixer
addon: [save_settings]                  [af7fbe0b-8060-45d2-bd14-cd718c0d56a1] 
addon: [save_settings]                  [af7fbe0b-8060-45d2-bd14-cd718c0d56a1] 
addon: [close]                          [af7fbe0b-8060-45d2-bd14-cd718c0d56a1] 
addon: [dtor]                           [af7fbe0b-8060-45d2-bd14-cd718c0d56a1] 

*** start kxmixer normally (from menu) (per device addon)
addon: [ctor] [Type:  Per Device]       [9749233a-f4d9-43a5-ae61-1280ccce9b7f] 
addon: [init] [p= -10] [NumDevices: 01] [9749233a-f4d9-43a5-ae61-1280ccce9b7f] 
addon: [load_settings]                  [9749233a-f4d9-43a5-ae61-1280ccce9b7f] 
addon: [ctor] [Type:  Per Device]       [041c874b-9808-4f29-8a2c-35900bcc91ec] 
addon: [dtor]                           [041c874b-9808-4f29-8a2c-35900bcc91ec] 
addon: [save_settings]                  [9749233a-f4d9-43a5-ae61-1280ccce9b7f] 
*** exit kxmixer
addon: [save_settings]                  [9749233a-f4d9-43a5-ae61-1280ccce9b7f] 
addon: [save_settings]                  [9749233a-f4d9-43a5-ae61-1280ccce9b7f] 
addon: [close]                          [9749233a-f4d9-43a5-ae61-1280ccce9b7f] 
addon: [dtor]                           [9749233a-f4d9-43a5-ae61-1280ccce9b7f] 

*** kxmixer --startup (system wide addon)
addon: [ctor] [Type: System Wide]       [50453cb3-47c3-4520-93da-d518af1ea031] 
addon: [dtor]                           [50453cb3-47c3-4520-93da-d518af1ea031] 
addon: [ctor] [Type: System Wide]       [d0983d3f-e0a7-462c-aacd-62119cd6f8c7] 
addon: [init] [p= -01] [NumDevices: 01] [d0983d3f-e0a7-462c-aacd-62119cd6f8c7] 
addon: [load_settings]                  [d0983d3f-e0a7-462c-aacd-62119cd6f8c7] 
addon: [save_settings]                  [d0983d3f-e0a7-462c-aacd-62119cd6f8c7] 
*** exit kxmixer
addon: [save_settings]                  [d0983d3f-e0a7-462c-aacd-62119cd6f8c7] 
addon: [save_settings]                  [d0983d3f-e0a7-462c-aacd-62119cd6f8c7] 
addon: [close]                          [d0983d3f-e0a7-462c-aacd-62119cd6f8c7] 
addon: [dtor]                           [d0983d3f-e0a7-462c-aacd-62119cd6f8c7] 

*** start kxmixer normally (from menu) (system wide addon)
addon: [ctor] [Type: System Wide]       [860e11d2-2d4d-4641-bdea-55a5b0c5a82c] 
addon: [dtor]                           [860e11d2-2d4d-4641-bdea-55a5b0c5a82c] 
addon: [ctor] [Type: System Wide]       [7b9d097e-6f3a-4939-be61-36338cb94983] 
addon: [init] [p= -01] [NumDevices: 01] [7b9d097e-6f3a-4939-be61-36338cb94983] 
addon: [save_settings]                  [7b9d097e-6f3a-4939-be61-36338cb94983] 
*** exit kxmixer
addon: [save_settings]                  [7b9d097e-6f3a-4939-be61-36338cb94983] 
addon: [save_settings]                  [7b9d097e-6f3a-4939-be61-36338cb94983] 
addon: [close]                          [7b9d097e-6f3a-4939-be61-36338cb94983] 
addon: [dtor]                           [7b9d097e-6f3a-4939-be61-36338cb94983]

Output from a mutli-card system would be more useful (particularly because, as it is now, it seems that Per Device addons load only a single instance, while System Wide addons load 2 or more instances (on multi-card machines), which is the opposite of your description (but I would like to verify this if I have the chance, with testing similair to the above, where I can differentiate between addon instances, etc)) but this is all I have at the moment.

BTW: kx_manger->get_current_device() seems to use a zero based index, while iKX::get_device_num() appears to use a 1 based index. Is this correct?

Also, is the addon code in 3538j and 3538k the same? The reason I ask, is that some of the testing (multi-card) was done using 3538j (all my own personal testing was done with 3538k).

Thanks,
-Russ

**Eugene Gavrilov** · Sep 14, 2006, 04:01 AM

3538l will introduce new add-on code, legacy add-ons won't be binary-compatible
pre-3538l builds contained a serious bug -- system-wide & per-device add-ons were not instantiated properly
--
get_device_num()?.. well, no, it should return 0-based number
--
Also, it does appear to be called for System Wide addons, but only when kxmixer is started with the --startup command line switch
- this is a bug. will fix that
--
sample add-on: a useful tool. please re-run it with 3538l when it is out
or, we can add it to our SDK to demonstrate add-on architecture

E.

Max M. · Sep 14, 2006, 05:19 AM

[color=gray]
L? will this end up somewhen? 38k already differs from 38a more then 37 from 20... the more changes you're trying to put there to give the illusion of "less or more full-fledged version" the more issues arise the more stuff you have to fix then the more far away you're from ending this up. Stop the recursion!

[/color]

**Eugene Gavrilov** · Sep 18, 2006, 03:10 AM

he-he

Russ · Sep 18, 2006, 05:02 AM

@Eugene,
Can you explain what the new addon::activate() function would be used for?

i.e.
What does it mean to "launch" an addon?

Max M. · Sep 18, 2006, 06:12 AM

i guess if an addon has GUI part then the launch() brings that gui on the screen
edit: hmm, or is it activate()? then, hmm.. no more guesses i guess

Russ · Sep 18, 2006, 07:07 AM

Here is the debug output on my machine with 3538L:

Code:

*** kxmixer --startup (per device addon)
addon: [ctor] [Type:  Per Device]                         [159d7f8f-b5b9-4e0c-8166-4c70b8854176] 
addon: [dtor]                                             [159d7f8f-b5b9-4e0c-8166-4c70b8854176] 
addon: [ctor] [Type:  Per Device]                         [bef59662-fa30-4f9e-8898-230bf50be1e8] 
addon: [init] [p: 000] [NumDevices: 01]                   [bef59662-fa30-4f9e-8898-230bf50be1e8] 
addon: [load_settings]                                    [bef59662-fa30-4f9e-8898-230bf50be1e8] 
addon: [save_settings]                                    [bef59662-fa30-4f9e-8898-230bf50be1e8] 
addon: [event - generic] [p1: 0x00000003]                 [bef59662-fa30-4f9e-8898-230bf50be1e8] 
*** exit kxmixer
addon: [save_settings]                                    [bef59662-fa30-4f9e-8898-230bf50be1e8] 
addon: [save_settings]                                    [bef59662-fa30-4f9e-8898-230bf50be1e8] 
addon: [close]                                            [bef59662-fa30-4f9e-8898-230bf50be1e8] 
addon: [dtor]                                             [bef59662-fa30-4f9e-8898-230bf50be1e8] 

*** start kxmixer normally (from menu) (per device addon)
addon: [ctor] [Type:  Per Device]                         [7585bcb3-988d-45da-af43-4f7321b0df9b] 
addon: [dtor]                                             [7585bcb3-988d-45da-af43-4f7321b0df9b] 
addon: [ctor] [Type:  Per Device]                         [256ba578-f597-4305-b574-6f96d3d8fd38] 
addon: [init] [p: 000] [NumDevices: 01]                   [256ba578-f597-4305-b574-6f96d3d8fd38] 
addon: [save_settings]                                    [256ba578-f597-4305-b574-6f96d3d8fd38] 
addon: [event - generic] [p1: 0x00000003]                 [256ba578-f597-4305-b574-6f96d3d8fd38] 
*** exit kxmixer
addon: [save_settings]                                    [256ba578-f597-4305-b574-6f96d3d8fd38] 
addon: [save_settings]                                    [256ba578-f597-4305-b574-6f96d3d8fd38] 
addon: [close]                                            [256ba578-f597-4305-b574-6f96d3d8fd38] 
addon: [dtor]                                             [256ba578-f597-4305-b574-6f96d3d8fd38] 

*** kxmixer --startup (system wide addon)
addon: [ctor] [Type: System Wide]                         [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 
addon: [init] [p: -01] [NumDevices: 01]                   [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 
addon: [load_settings]                                    [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 
addon: [ctor] [Type: System Wide]                         [ab38dbfe-9239-4b24-b286-cc7ef1bcaf80] 
addon: [dtor]                                             [ab38dbfe-9239-4b24-b286-cc7ef1bcaf80] 
addon: [load_settings]                                    [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 
addon: [save_settings]                                    [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 
addon: [event - generic] [p1: 0x00000003]                 [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 
*** exit kxmixer
addon: [save_settings]                                    [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 
addon: [save_settings]                                    [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 
addon: [close]                                            [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 

*** start kxmixer normally (from menu) (system wide addon)
addon: [dtor]                                             [e1f76dcb-a653-449a-85e0-ed0961f7dc9a] 
addon: [ctor] [Type: System Wide]                         [18b0568e-9d4f-40d2-bea0-6b981c30a0c3] 
addon: [init] [p: -01] [NumDevices: 01]                   [18b0568e-9d4f-40d2-bea0-6b981c30a0c3] 
addon: [load_settings]                                    [18b0568e-9d4f-40d2-bea0-6b981c30a0c3] 
addon: [ctor] [Type: System Wide]                         [211f175b-bb3e-4a62-bd25-28d9cf4c60fa] 
addon: [dtor]                                             [211f175b-bb3e-4a62-bd25-28d9cf4c60fa] 
addon: [save_settings]                                    [18b0568e-9d4f-40d2-bea0-6b981c30a0c3] 
addon: [event - generic] [p1: 0x00000003]                 [18b0568e-9d4f-40d2-bea0-6b981c30a0c3] 
*** exit kxmixer
addon: [save_settings]                                    [18b0568e-9d4f-40d2-bea0-6b981c30a0c3] 
addon: [save_settings]                                    [18b0568e-9d4f-40d2-bea0-6b981c30a0c3] 
addon: [close]                                            [18b0568e-9d4f-40d2-bea0-6b981c30a0c3] 
addon: [dtor]                                             [18b0568e-9d4f-40d2-bea0-6b981c30a0c3]

From the above:

addon::init() does now appear to show the correct device number ("p") for Per Device addons. Also, it does appear to be called for both System Wide and Per Device addons when started with kxmixer (with or without using the --startup switch).

addon::load_settings() does now appear to be called for System Wide addons when started with kxmixer (with or without using the kxmixer --startup switch), but now it appears that it is not called for Per Device addons, when started with kxmixer without using the --startup option.

Trying to use kx_manager functions (i.e. kx_manager->get_ikx() ) from within addon::init() causes kX to crash (it did not work previously from within init() either, but it didn't crash). When is it safe to use kx_manager functions from an addon (previously it only seemed to work (correctly), after save_settings() was called the first time)?

BTW: I did see the new 'addon' option in the save settings dialog, and did some quick tests (without actually saving any data from the addon), and load_settings did appear to be called when loading a saved config file that had that option selected.

That is all I have for now...
-Russ

Russ · Sep 18, 2006, 07:03 PM

BTW: Registering the (single) addon still reports that 2 addons where registered, and shows the following debug info from kX:

Code:

kxmixer: add-on: registering 'C:\Program Files\kX Audio Driver\SDK 3538\test addon\Debug\test_addon.kxa'
kxmixer: registered [0] bea42d0e-5073-4219-88cd-1687b69a8055.name:Test_Add-on
iKXPlugin: exception on plugin actions 4
iKX plugin: get_guid(): pp(get_guid) failed [-1]

As I stated previously (in a previous discussion/thread), if I remove the NULL entry in addon.cpp ( in kxaddon_list_t addon_list[]={}), it correctly reports that 1 addon was registered, and the last 2 lines (above) in the debug output are not displayed. I am not sure if that NULL entry is supposed to be there (it is in the included sample addon), as it is not needed for plugins.

**Eugene Gavrilov** · Sep 19, 2006, 01:13 AM

1.
but now it appears that it is not called for Per Device addons, when started with kxmixer without using the --startup option.

this is expected. I read your message dealing with this issue before I managed to fix it. yes, per-device settings are not (yet) restored properly w/o --startup switch
--
NULL registration: yep, that's a bug. I will remove NULL
--
'trying to use iKX interface': I will try to reproduce this
btw, could you pls send your test add-on source code by e-mail (www.kxproject.com/contact.php)? this will speed-up my testing

E.

**Eugene Gavrilov** · Sep 19, 2006, 01:30 AM

'activate() add-on':

first of all, activate() is just another name for manager->launch()
that is, if you launch() kX Addon, kX mixer will call ->activate()
if you launch() kX DSP effect, kX mixer will call ->tweak_plugin()

this is a kind of pre-defined action. this can be triggered by, say, your effect, a kxmixer button etc... that is, you can avoid enumerations and just 'launch' some predefined action from a different kx component based on its GUID and no more information.

kX mixer will never execute launch\activate() by itself, but your custom skin, your DSP plugin or external tool can 'launch' it by GUID.
I will also probably add remoteIR, kxctrl and kxmixer bindings to execute launch() effect
(that is, by clicking some particular button, hardware key, command line option)

that is, activate() is the same term as launch() in kX Manager API and it is triggered by:
- click on kxmixer button with 'action=' (in kxskin.ini)
- another addon's or DSP plugin calling manager->launch()
- in the future:
* remote IR button (if assigned) (as an option to direct remoteir notification)
* kxctrl --launch {GUID} call (command line)
* kxmixer --launch {GUID} call (command line)
* kx scripts notification
etc..
(not yet defined)

for most non-interactive addons it is safe to ignore activate()
if you add your add-on to kX menu, it is safe to use the same handler for activate() and menu selection

E.

Russ · Sep 19, 2006, 02:40 AM

Ok, so activate(), (in an addon) is basically, whatever I want it to be.

I will send you my test addon code, but it really is not much different from the bundled sample addon (I basically just added debug info).

This is the code that doesn't work in init() (but it does work after save_settings() is called the first time).

Code:

int nDevices = 0;    
for (nDevices=0; nDevices<MAX_KX_DEVICES; nDevices++)
{
    if (kx_manager->get_ikx(nDevices) == (iKX*)NULL)        
        break;                
}

-Russ

Sep 9, 2006, 12:42 AM	#1
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,506 Rep Power: 61	Bugs with addon api... There still (3538k) appears to be some bugs with the addon api, but some of them only show up on mutli-card systems, so it is hard (for me) to figure out exactly what is happening -vs- what is supposed to happen with an addon on multi-card systems (since I have only a single card). Issues: Per Device Addons (only): ---------------------- The value of "p" in init() is supposed to be the device number, but on my system the value is always -10. (-1 for System Wide addons, which is expected). Up until save_settings() is called the first time, kx_manager->get_current_device() also results in a value of -10. Only after save_settings() is called the first time, does the function appear to return the current device. (it does appear to return the current device for System Wide addons during init() (as far as I can tell anyway)). ---------- System Wide addons (only): ---------------------- load_settings() is never called. ---------- Both: ---------------------- Registering the addon reports that 2 addons were registered, even though there is only a single addon. The return value from init() seems to make no difference. I tried returning a value of -1 (as well as other non-zero values, for testing purposes) and the addon continued to load normally. It is unclear as to how the addon is supposed to function when it is a System Wide addon -vs- being a Per Device addon (and it does not seem to function in such a way that those terms would suggest). i.e. - "System Wide" sounds like it would mean that there is a single instance of the addon, shared by all devices. However, when tested on a system with two cards, there appeared to be two instances of the addon loaded at the same time (both shown on the menu). Also, I was getting some strange results when calling kx_manager->change_device() from the addon (different from the results when doing the same thing in a per device addon). - "Per Device" sounds like one of the following scenarios: One instance of the addon is loaded/used for/by each device (so multiple instances would be running at once). -or- One instance of the addon is loaded at a time, and when you change devices, the previous instance is closed, and a new instance started. I am not sure which of the above (per device addon) scenarios is supposed to be used, but as far as I can tell, there appears to only ever be one instance of the addon loaded, and the only thing that seems to happen when you change devices, is that save_settings() is called (I am not exactly sure what happens when you change devices with a System Wide addon, as I have not had a chance, as of yet, to see the debug output under that scenario (on a multi-card system)). ---------- Again, much of this I could not test myself, since I have only a single card, but with the help of Maddogg6, some testing was done on a mutli-card system, leading to some confusing results. I will post more info here if/when I have more info. BTW: It would be good if there was a function to get the number of devices (and device names), rather than having to enumerate them manually. -Russ

Sep 18, 2006, 07:03 PM	Thread Starter #11
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,506 Rep Power: 61	BTW: Registering the (single) addon still reports that 2 addons where registered, and shows the following debug info from kX: Code: kxmixer: add-on: registering 'C:\Program Files\kX Audio Driver\SDK 3538\test addon\Debug\test_addon.kxa' kxmixer: registered [0] bea42d0e-5073-4219-88cd-1687b69a8055.name:Test_Add-on iKXPlugin: exception on plugin actions 4 iKX plugin: get_guid(): pp(get_guid) failed [-1] As I stated previously (in a previous discussion/thread), if I remove the NULL entry in addon.cpp ( in kxaddon_list_t addon_list[]={}), it correctly reports that 1 addon was registered, and the last 2 lines (above) in the debug output are not displayed. I am not sure if that NULL entry is supposed to be there (it is in the included sample addon), as it is not needed for plugins. Last edited by Russ; Sep 18, 2006 at 07:16 PM.

Sep 19, 2006, 02:40 AM	Thread Starter #14
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,506 Rep Power: 61	Ok, so activate(), (in an addon) is basically, whatever I want it to be. I will send you my test addon code, but it really is not much different from the bundled sample addon (I basically just added debug info). This is the code that doesn't work in init() (but it does work after save_settings() is called the first time). Code: int nDevices = 0; for (nDevices=0; nDevices<MAX_KX_DEVICES; nDevices++) { if (kx_manager->get_ikx(nDevices) == (iKX*)NULL) break; } -Russ

Sep 9, 2006, 06:40 PM	Thread Starter #2
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,506 Rep Power: 61	Another thing that would be useful is a IKX_DEVICE_CHANGED notification (maybe a Generic Event like IKX_DSP_CHANGED), as currently there seems to be no way to detect this. Although save_settings() is called when the device is changed, it appears (again this is hard for me to test) to be called before the device is actually changed, so calling kx_manager->get_current_device() would not tell the addon what the device number is, that it is changing to. So, some kind of notification of a device change, that fires after the change is complete, would be useful. -Russ

Sep 13, 2006, 06:30 AM	#3
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,106 Rep Power: 73	init: * tried to fix that. pls check. for global add-ons: p=-1; for per-device: correct device id + if addon->init() returns non-zero, addon is no longer loaded (the DLL might be still in memory) load_settings: hm.. there was a bug with KX_SAVED_ADDONS flag that was cleared in the default save/restore settings dialog (since there's no such option visible) note that if KX_SAVED_ADDONS is not set, per-device save/load addon settings are not executed IKX_DEVICE_CHANGED: added. it is sent to all add-ons whenever user or another add-on change current device === "It would be good if there was a function to get the number of devices (and device names), rather than having to enumerate them manually": -- at the moment the only way is to: for(i=0;i<MAX_KX_DEVICES) { ikx_t= manager->get_ikx(i); if(ikx_t) ikx_t->get_device_name() } you can also use iKXManager::create_devices_menu() if necessary == per-device vs global add-ons: per-device addon is created for each iKX instance and is present in memory that is, an example: there are two add-ons registered: system-wide & per-device there are 5 audio cards on kxmixer startup, it will create one system-wide addon and 5 per-device ones system-wide addon should acquire iKX pointer based on its own logic (either by allowing the user to choose, or by acquiring current device etc..) per-device addons use the dev_id value specified during their creation === due to a bug in per-device/system-wide handling, I added new flag - KXADDON_SYSTEM_WIDE (=2) that needs to be specified for system-wide addons E.

Sep 14, 2006, 04:01 AM	#5
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,106 Rep Power: 73	3538l will introduce new add-on code, legacy add-ons won't be binary-compatible pre-3538l builds contained a serious bug -- system-wide & per-device add-ons were not instantiated properly -- get_device_num()?.. well, no, it should return 0-based number -- Also, it does appear to be called for System Wide addons, but only when kxmixer is started with the --startup command line switch - this is a bug. will fix that -- sample add-on: a useful tool. please re-run it with 3538l when it is out or, we can add it to our SDK to demonstrate add-on architecture E.

Sep 14, 2006, 05:19 AM	#6
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,606 Rep Power: 66	[color=gray] L? will this end up somewhen? 38k already differs from 38a more then 37 from 20... the more changes you're trying to put there to give the illusion of "less or more full-fledged version" the more issues arise the more stuff you have to fix then the more far away you're from ending this up. Stop the recursion! [/color]

Sep 18, 2006, 03:10 AM	#7
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,106 Rep Power: 73	he-he

Sep 18, 2006, 05:02 AM	Thread Starter #8
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,506 Rep Power: 61	@Eugene, Can you explain what the new addon::activate() function would be used for? i.e. What does it mean to "launch" an addon?

Sep 18, 2006, 06:12 AM	#9
Max M. h/h member-shmember Join Date: Dec 2002 Location: Evil Empire Posts: 2,606 Rep Power: 66	i guess if an addon has GUI part then the launch() brings that gui on the screen edit: hmm, or is it activate()? then, hmm.. no more guesses i guess

Sep 19, 2006, 01:13 AM	#12
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,106 Rep Power: 73	1. but now it appears that it is not called for Per Device addons, when started with kxmixer without using the --startup option. this is expected. I read your message dealing with this issue before I managed to fix it. yes, per-device settings are not (yet) restored properly w/o --startup switch -- NULL registration: yep, that's a bug. I will remove NULL -- 'trying to use iKX interface': I will try to reproduce this btw, could you pls send your test add-on source code by e-mail (www.kxproject.com/contact.php)? this will speed-up my testing E.

Sep 19, 2006, 01:30 AM	#13
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,106 Rep Power: 73	'activate() add-on': first of all, activate() is just another name for manager->launch() that is, if you launch() kX Addon, kX mixer will call ->activate() if you launch() kX DSP effect, kX mixer will call ->tweak_plugin() this is a kind of pre-defined action. this can be triggered by, say, your effect, a kxmixer button etc... that is, you can avoid enumerations and just 'launch' some predefined action from a different kx component based on its GUID and no more information. kX mixer will never execute launch\activate() by itself, but your custom skin, your DSP plugin or external tool can 'launch' it by GUID. I will also probably add remoteIR, kxctrl and kxmixer bindings to execute launch() effect (that is, by clicking some particular button, hardware key, command line option) that is, activate() is the same term as launch() in kX Manager API and it is triggered by: - click on kxmixer button with 'action=' (in kxskin.ini) - another addon's or DSP plugin calling manager->launch() - in the future: * remote IR button (if assigned) (as an option to direct remoteir notification) * kxctrl --launch {GUID} call (command line) * kxmixer --launch {GUID} call (command line) * kx scripts notification etc.. (not yet defined) for most non-interactive addons it is safe to ignore activate() if you add your add-on to kX menu, it is safe to use the same handler for activate() and menu selection E.