Several EMU e-DSP Control bug

diabLe · Jul 23, 2009, 08:18 PM

hi all

thanks for your fantastic driver

i've 2 EMU 1820 and i can't control each separatly trougth the e-DSP Control ,
ex : it's NOT possible to "reload firmware" for each card, that reload always the same card
it's not possible to setup in/out sensitivity separatly , it affect the TWO cards at same time

i'm using the 3545b , under XP SP2 (x86) with 2Go ram

it would be fantastic if it can help to improve the KX

if i can help anyway , please contact me by email

cheers

**Eugene Gavrilov** · Jul 24, 2009, 01:23 AM

if you are a skilled C++ programmer, or at least are familiar with this language, have a look at the edspctrl and E-DSP Control AddOn source code (it is included with the SDK that comes with the driver).
I'm sure you can easily find the bug, if it is present there.
If yes, send me a message by e-mail (kxproject.com/contact.php) and I will correct it.

E.

Russ · Jul 24, 2009, 03:16 AM

I think one of the problems may be that the addon and the GUI each appear to have there own iKX pointer, and they are not kept in sync with each other as to the currently selected device (the addon appears to only set the current device during initialization).

i.e.
Most of the GUI functions use the iKX pointer from CKXDialog (which is updated when a device is selected in the GUI), but reload firmware calls init_firmware(), which is an addon function (thus uses the addon's iKX pointer), without first setting the addon's iKX pointer to the currently selected device.

I do not know, that would seem to explain the issue with reloading the firmware, I am not sure about the issue with input/output sensitivity (and I do not have any EMU cards, so I cannot test anything).

diabLe · Jul 25, 2009, 11:35 PM

unfortunatly i'm not familiar with C++ or any other language ... but if it can help someone with the same problem, you can setup each card separatly by desactivate one of them from the windows's system property then, reboot and reactivate , and do the same for each others ... you'll just not allowed to dynamic setup.

Russ · Jul 25, 2009, 11:46 PM

Is it just the input/output sensitivity setting that affects both cards at the same time, or is it all the settings (except reloading firmware) in the addon?

diabLe · Jul 26, 2009, 10:25 AM

i don't use midi, and i don't know about the digital input type selecting .. i don't use that stuff, selecting the clock offer only 48k for the moment so i can't test, and selecting source headphone's DAC is for 192khz mode only. selecting the active soundcard by the box's menu is right but it's not updated in that window ,( updating the DSP page or mixer page ).

Russ · Jul 26, 2009, 07:32 PM

OK, I was just wondering as it would help to narrow down where problems may exist in the code, etc.

---
I think there may still be some issues with per device addons (I think a system wide addon might be a better fit here anyway). A menu item is added for each card, but it seems the same addon instance handles the (menu) events for all of them. I guess this is why it does not seem to make any difference which item you choose from the menu (I will test some more when I have a chance).

Russ · Jul 27, 2009, 05:02 AM

I did some more testing (as much as I could without having any EMU cards) and I think the following should fix most of the issues:

Code:

int iEDSPControlAddOn::event(int event,void *p1,void *p2)
{
    switch(event)
    {
    ...
        case KXADDON_EVENT_GENERIC:
        {
            int item=(int)p1;
            switch(item)
            {
            ...
/***********************************************************/
                case IKX_DEVICE_CHANGED:
                {
                    ikx = kx_manager->get_ikx();
                    if(edsp_dialog)
                        edsp_dialog->select_device();
                }
                break;
/***********************************************************/
...

I think that should just leave the issue with the menu (which I guess is not really an issue (here) since it makes sense for it to show the currently selected device (again, maybe a system wide addon would make more sense?)).

BTW: I did send E. an email about this...

Russ · Jul 27, 2009, 05:51 PM

@diabLe,

Are you sure that those settings affected both cards at the same time? or could it be that you just could not tell which card the setting was being applied to?

diabLe · Jul 28, 2009, 09:19 AM

hi RUSS,

i've re-tested to be sure and ... i found something ,
by selecting via the submenu "active soundcard" and then open the (right ) edsp control , it affect only one card .... in fact it's a GUI problem only, the edsp control is not refreshed by selecting the other device via the "bluebox" ( but firmware reload is always not working ).

Russ · Jul 28, 2009, 09:32 AM

OK, good, that is what I thought... so the code I posted should fix it.

diabLe · Jul 28, 2009, 09:39 AM

i'm sorry, but how can i test the code to confirm ?

Russ · Jul 28, 2009, 09:56 AM

I suppose I could post a version with the changes so you can test it...

(temp link - removed) E-DSP
(extract the file to wherever you want it to stay, double click on the file to register the addon, and then restart kX Mixer)

Other than that you would have to wait for E. to release an update (or compile it yourself).

diabLe · Jul 28, 2009, 11:17 AM

well, the EDSP Control has gone away .... so i can't try anymore

Russ · Jul 28, 2009, 11:23 AM

It went away? Hmm, maybe it did not register correctly...
Check the following registry key:
HKEY_CURRENT_USER\Software\kX\Addons

Delete anything in that key.
Restart kX Mixer (i.e. Quit kxmixer, not just close, etc).
Re-register the addon.
Restart kX Mixer again.

diabLe · Jul 28, 2009, 11:33 AM

i did that , it didn't came back

Russ · Jul 28, 2009, 11:52 AM

Hmm, I had some strange issues with that when I was testing too. At one point it seemed to not like the menu position for some reason. Try this one instead: (temp link - removed).

This one places the addon under the "Add-Ons" menu.

If that doesn't work... then I do not know (I really cannot test it without commenting out all of the EMU specific stuff (which I did in previous testing and it worked for me))... Does it come back if you re-register the original addon?

diabLe · Jul 28, 2009, 12:20 PM

the EDSP2 doesnt work anymore, but it set the ADC of the 1st card to -10dBv !!

re-registering the original is right to recover EDSP control

Russ · Jul 28, 2009, 12:26 PM

Quote:

Originally Posted by diabLe

the EDSP2 doesnt work anymore

What do you mean by that? Can you be more specific?

Quote:

Originally Posted by diabLe

but it set the ADC of the 1st card to -10dBv !!

Is that what you were trying to do? or it did that own its own?

diabLe · Jul 28, 2009, 12:34 PM

"the EDSP2 doesnt work anymore" <-- the edsp control menu doesn't appear

setting to -10dBv did that by itself

( i need to go to work, so i'll not be here anymore today , sorry, and thx for your support

)

Russ · Jul 28, 2009, 12:47 PM

Quote:

Originally Posted by diabLe

"the EDSP2 doesnt work anymore" <-- the edsp control menu doesn't appear

OK, the word "anymore" confused me... It sounded like it did work, and then stopped working. So, you were not able to access the settings panel in either version, right?

Quote:

Originally Posted by diabLe

setting to -10dBv did that by itself

Hmm, I have no idea why it would do that, unless that is the default setting, or that setting was saved previously.

I have no way of testing the actual functionality of any of the settings. I can only verify that it shows the correct card when you change devices, etc (which should indicate that the settings are being applied to that card, etc), and print out debug info.

I also do not know why it will not show on the menu for you... If you cannot access the panel, than we cannot really test anything... I am not sure what else I can do (it seemed OK to me, as much as I could test anyway)... Sorry

**Eugene Gavrilov** · Jul 28, 2009, 03:14 PM

it seems the problem is a bit more complex...

"IKX_DEVICE_CHANGED" notification is not the best place to change ikx pointer, since there are two kX add-ons uploaded. iEDSPControlAddOn is instantiated for each card, thus, it should never change its ikx pointer.

the iEDSPControlAddOn::activate() function creates EDSP Dialog instance, but does not pass the desired device number, that's why 'activate' will always open edsp window with 'current' device, regardless of the menu item selected.

EDSP Dialog is bound to the addon by pointer, but accesses ikx hardware by using internal pointer, which is not constant.

I will try to fix this in the next driver release.

E.

Russ · Jul 28, 2009, 05:40 PM

I understand that it is supposed to be a per device addon, and normally you would not want to change the ikx pointer for that type of addon, but part of the problem is (as I said previously), that only one addon instance is handing the menu events for each addon instance. So (until that bug is fixed) even if the device number is passed to the dialog in activate(), the same addon instance is going to handle the event, so you will still get the same result, regardless of which item was chosen from the menu. Changing the ikx pointer was basically a workaround for that problem (I guess I should have said it was a workaround, instead of a fix... but I did say that the menu thing was still an issue

).

i.e. (with the original code)
I added a device number variable to the addon, which is assigned the value of p in init(). In the code that generates the menu text, I added this device number (so that I am able to know which item is which on the menu), and I added debug output to the KXADDON_EVENT_MENU notification that prints the device number. In my testing, it (KXADDON_EVENT_MENU) always printed the same device number (in my case, it always printed "1").

The other issue is that you can do device selection within the addon's GUI (as well as in kxmixer, etc), but it does not generate a select_device() call, so the dialog does not get refreshed until some other action generates the select_device() call (which is why I added the select_device() call to the IKX_DEVICE_CHANGED notification).

**Eugene Gavrilov** · Jul 28, 2009, 07:15 PM

why do you think the same addon instance handles the event?
if I'm not mistaken, kX mixer sends different events to different add-ons
(because menu_id is generated on per-addon basis)
so, if you choose the first e-dsp control, the first add-on will get 'activate' event
if you choose the second e-dsp control, the second add-on will get 'activate' event

but: since they both launch edsp GUI in the same way, the GUI applet will keep working with the same device (but 'reset microcode' command will be sent to the correct device)

moreover, changing device in E-DSP Control is useless, because it does not process this event properly (and it cannot re-associate itself with a different add-on)

I'm planning to fix this the following way:
* pass device number from the addon to EDSP GUI during instantiation
* disable device selection in EDSP GUI
* show port number in the kx menu ("E-DSP Control [d800]")

Although this is not the best solution, it should work. And most people don't have two E-mu cards installed anyway

Let me know what do you think.

E.

Russ · Jul 28, 2009, 07:45 PM

Right, when I added the device number to the menu text, it showed (I have 2 cards):

E-DSP Control: 01
E-DSP Control: 00

...which indicates that the menu item is generated by each addon instance.

But, when I printed out (debug output) the device number in the KXADDON_EVENT_MENU notification, it printed "01" as the device number (I also included some other info such as the card name, and again it was always the same), regardless of which menu item I chose, and regardless of which card was the currently selected device in kxmixer.

I think it is only the KXADDON_EVENT_MENU notification that has the problem, as I do see the notification for KXADDON_EVENT_GENERIC sent to both addon instances when I change devices in kxmixer, etc. (i.e. debug output prints both device numbers with that notification).

Your plan sounds good provided that the menu works correctly (otherwise it seems people will only be able to configure one of the cards (probably whichever one is the default when Windows starts)).

Russ · Jul 28, 2009, 08:49 PM

I just checked something else. I had unregistered my addon (PluginQL) while testing this, and I just re-registered it to test something, and it seems that the same E-DSP Control addon instance is trapping the menu events from my addon as well.

i.e.
If I choose the first menu item from my addon, it launches the E-DSP Control Panel instead of doing what it is supposed to do (and prints out the debug info from that addon (E-DSP) instance), and the other menu items from my addon (which normally do what they are supposed to do) do nothing.

**Eugene Gavrilov** · Jul 28, 2009, 09:52 PM

Russ, thanks for helping me with this problem.
Unfortunately, I don't have two cards installed, so I cannot test all this easily..
I tried to fix the bug in 3548 - and also included certain parts of the kxmixer source code (including addonmgr.cpp/h files) - so, I hope this sheds light on this bug.

Print to the debug console 'menu_base' variable for both instances of your add-on.
For each instance, menu_base should be unique, and should be within the interval of 0..MAX_ADDON_MENU_ITEMS incremented by MAX_ADDON_MENU_ITEMS for each addon.

Check that addon::menu() adds the menu item with correct menu_base value.

E.

Russ · Jul 28, 2009, 10:27 PM

Currently (3545b) "menu-base" shows 1100 both before and after "menu->add" for both instances of the E-DSP addon (making the menu id "1101" for both instances, which is also the value that "p1" has in the event handler when either item is selected).

That also appears to be the base value that my plugin (PluginQL) gets assigned.

I have to go do a few things, but I willl check out 3548 the first chance I get.

Russ · Jul 30, 2009, 03:36 AM

I have only been able to do a little testing with 3548 thus far, but it seems there are still issues with the menu handling.

Both menu items still bring up the control panel for the same card.

"menu_base" never appears to get auto-incremented internally, so all addons get the same menu_base, and thus the same starting menu id's.

Even if you try to force a unique id for each menu item (i.e. by doing something like: menu_base+1+ikx->get_device_num()), the same addon instance still handles the menu events for both id's (even though each menu item was generated from different addon instances).

Russ · Jul 30, 2009, 09:22 AM

I took a look at the addonmgr code and now I understand how it is supposed to work.

The problem is definitely the menu_base. I can see that the code is supposed to increment the menu_base by 10 for each addon, but for some reason (I did not see any obvious reason) the value assigned to each addon is not incremented by 10 (or at all). The menu_base has to be not just unique (between addons), but also 10 apart because the menu processing code checks the menu id, and enumerates through each addon to see if the id is within the range of it's menu_base+10, and sends the event only to the addon with that range. If they all have the same menu_base, then the first addon in the list is always going to handle the message (which is what is happening now).

As a test, I added code to init() to force the menu_base to be 10 apart for each addon instance:
i.e.
menu_base += p * 10;

With the above change, the menu handling worked correctly, and each E-DSP menu item brought up a different control panel (like it is supposed to do).

I noticed an important clue:

If I run multiple per device addons: The menu_base is incremented by 10 for each per device addon (but not for the per device instances).

If I run multiple system wide addons: The menu_base is incremented by 10 for each system wide addon.

If I run a per device addon and a system wide addon, the menu_base is the same. I suspect if I run multiples of both, the menu_base will be the same for both for the first instance of each kind, and the same for each additional addon of each kind, but incremented by 10 (from the first instance of each, but not each other).
[EDIT] This is confirmed. I ran the below test and the results where as posted. [/EDIT]

i.e. (if the above is not clear)
If 3 of each kind of addon were running at the same time, on a system with 2 cards:

System_Wide_Addon_1: menu_base = 1100
System_Wide_Addon_2: menu_base = 1110
System_Wide_Addon_3: menu_base = 1120

Per_Device_Addon_1
- Instance 1 (1st card): menu_base = 1100
- Instance 2 (2nd card): menu_base = 1100
Per_Device_Addon_2
- Instance 1 (1st card): menu_base = 1110
- Instance 2 (2nd card): menu_base = 1110
Per_Device_Addon_3
- Instance 1 (1st card): menu_base = 1120
- Instance 2 (2nd card): menu_base = 1120

So, from the above, it seems as though maybe a different (or new instance of the) addon manager (or addon list or something) is used for per device addons, and system wide addons, and per device instances.

Jul 23, 2009, 08:18 PM	#1
diabLe HardwareHeaven Junior Member Join Date: Nov 2006 Location: FRANCE, NANCY Posts: 36 Rep Power: 0	Several EMU e-DSP Control bug hi all thanks for your fantastic driver i've 2 EMU 1820 and i can't control each separatly trougth the e-DSP Control , ex : it's NOT possible to "reload firmware" for each card, that reload always the same card it's not possible to setup in/out sensitivity separatly , it affect the TWO cards at same time i'm using the 3545b , under XP SP2 (x86) with 2Go ram it would be fantastic if it can help to improve the KX if i can help anyway , please contact me by email cheers Last edited by diabLe; Jul 23, 2009 at 08:55 PM.

Jul 24, 2009, 01:23 AM	#2
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,119 Rep Power: 75	Îòâåò: Several EMU e-DSP Control bug if you are a skilled C++ programmer, or at least are familiar with this language, have a look at the edspctrl and E-DSP Control AddOn source code (it is included with the SDK that comes with the driver). I'm sure you can easily find the bug, if it is present there. If yes, send me a message by e-mail (kxproject.com/contact.php) and I will correct it. E.

Jul 24, 2009, 03:16 AM	#3
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug I think one of the problems may be that the addon and the GUI each appear to have there own iKX pointer, and they are not kept in sync with each other as to the currently selected device (the addon appears to only set the current device during initialization). i.e. Most of the GUI functions use the iKX pointer from CKXDialog (which is updated when a device is selected in the GUI), but reload firmware calls init_firmware(), which is an addon function (thus uses the addon's iKX pointer), without first setting the addon's iKX pointer to the currently selected device. I do not know, that would seem to explain the issue with reloading the firmware, I am not sure about the issue with input/output sensitivity (and I do not have any EMU cards, so I cannot test anything). Last edited by Russ; Jul 25, 2009 at 03:40 PM. Reason: typo

Jul 25, 2009, 11:35 PM	Thread Starter #4
diabLe HardwareHeaven Junior Member Join Date: Nov 2006 Location: FRANCE, NANCY Posts: 36 Rep Power: 0	Re : Several EMU e-DSP Control bug unfortunatly i'm not familiar with C++ or any other language ... but if it can help someone with the same problem, you can setup each card separatly by desactivate one of them from the windows's system property then, reboot and reactivate , and do the same for each others ... you'll just not allowed to dynamic setup.

Jul 25, 2009, 11:46 PM	#5
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug Is it just the input/output sensitivity setting that affects both cards at the same time, or is it all the settings (except reloading firmware) in the addon? Last edited by Russ; Jul 26, 2009 at 12:04 AM.

Jul 26, 2009, 10:25 AM	Thread Starter #6
diabLe HardwareHeaven Junior Member Join Date: Nov 2006 Location: FRANCE, NANCY Posts: 36 Rep Power: 0	Re : Several EMU e-DSP Control bug i don't use midi, and i don't know about the digital input type selecting .. i don't use that stuff, selecting the clock offer only 48k for the moment so i can't test, and selecting source headphone's DAC is for 192khz mode only. selecting the active soundcard by the box's menu is right but it's not updated in that window ,( updating the DSP page or mixer page ).

Jul 26, 2009, 07:32 PM	#7
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug OK, I was just wondering as it would help to narrow down where problems may exist in the code, etc. --- I think there may still be some issues with per device addons (I think a system wide addon might be a better fit here anyway). A menu item is added for each card, but it seems the same addon instance handles the (menu) events for all of them. I guess this is why it does not seem to make any difference which item you choose from the menu (I will test some more when I have a chance). Last edited by Russ; Jul 26, 2009 at 07:44 PM.

Jul 27, 2009, 05:02 AM	#8
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug I did some more testing (as much as I could without having any EMU cards) and I think the following should fix most of the issues: Code: int iEDSPControlAddOn::event(int event,void p1,void p2) { switch(event) { ... case KXADDON_EVENT_GENERIC: { int item=(int)p1; switch(item) { ... /*********************************************************/ case IKX_DEVICE_CHANGED: { ikx = kx_manager->get_ikx(); if(edsp_dialog) edsp_dialog->select_device(); } break; /********************************************************/ ... I think that should just leave the issue with the menu (which I guess is not really an issue (here) since it makes sense for it to show the currently selected device (again, maybe a system wide addon would make more sense?)). BTW: I did send E. an email about this... Last edited by Russ; Jul 27, 2009 at 05:21 AM.*

Jul 27, 2009, 05:51 PM	#9
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug @diabLe, Are you sure that those settings affected both cards at the same time? or could it be that you just could not tell which card the setting was being applied to?

Jul 28, 2009, 09:19 AM	Thread Starter #10
diabLe HardwareHeaven Junior Member Join Date: Nov 2006 Location: FRANCE, NANCY Posts: 36 Rep Power: 0	Re : Several EMU e-DSP Control bug hi RUSS, i've re-tested to be sure and ... i found something , by selecting via the submenu "active soundcard" and then open the (right ) edsp control , it affect only one card .... in fact it's a GUI problem only, the edsp control is not refreshed by selecting the other device via the "bluebox" ( but firmware reload is always not working ).

Jul 28, 2009, 09:32 AM	#11
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug OK, good, that is what I thought... so the code I posted should fix it.

Jul 28, 2009, 09:39 AM	Thread Starter #12
diabLe HardwareHeaven Junior Member Join Date: Nov 2006 Location: FRANCE, NANCY Posts: 36 Rep Power: 0	Re : Several EMU e-DSP Control bug i'm sorry, but how can i test the code to confirm ?

Jul 28, 2009, 09:56 AM	#13
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug I suppose I could post a version with the changes so you can test it... (temp link - removed) E-DSP (extract the file to wherever you want it to stay, double click on the file to register the addon, and then restart kX Mixer) Other than that you would have to wait for E. to release an update (or compile it yourself). Last edited by Russ; Jul 28, 2009 at 12:06 PM.

Jul 28, 2009, 11:17 AM	Thread Starter #14
diabLe HardwareHeaven Junior Member Join Date: Nov 2006 Location: FRANCE, NANCY Posts: 36 Rep Power: 0	Re : Several EMU e-DSP Control bug well, the EDSP Control has gone away .... so i can't try anymore

Jul 28, 2009, 11:23 AM	#15
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug It went away? Hmm, maybe it did not register correctly... Check the following registry key: HKEY_CURRENT_USER\Software\kX\Addons Delete anything in that key. Restart kX Mixer (i.e. Quit kxmixer, not just close, etc). Re-register the addon. Restart kX Mixer again.

Jul 28, 2009, 11:33 AM	Thread Starter #16
diabLe HardwareHeaven Junior Member Join Date: Nov 2006 Location: FRANCE, NANCY Posts: 36 Rep Power: 0	Re : Several EMU e-DSP Control bug i did that , it didn't came back

Jul 28, 2009, 11:52 AM	#17
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug Hmm, I had some strange issues with that when I was testing too. At one point it seemed to not like the menu position for some reason. Try this one instead: (temp link - removed). This one places the addon under the "Add-Ons" menu. If that doesn't work... then I do not know (I really cannot test it without commenting out all of the EMU specific stuff (which I did in previous testing and it worked for me))... Does it come back if you re-register the original addon? Last edited by Russ; Jul 28, 2009 at 12:35 PM.

Jul 28, 2009, 12:20 PM	Thread Starter #18
diabLe HardwareHeaven Junior Member Join Date: Nov 2006 Location: FRANCE, NANCY Posts: 36 Rep Power: 0	Re : Several EMU e-DSP Control bug the EDSP2 doesnt work anymore, but it set the ADC of the 1st card to -10dBv !! re-registering the original is right to recover EDSP control

Jul 28, 2009, 12:34 PM	Thread Starter #20
diabLe HardwareHeaven Junior Member Join Date: Nov 2006 Location: FRANCE, NANCY Posts: 36 Rep Power: 0	Re : Several EMU e-DSP Control bug "the EDSP2 doesnt work anymore" <-- the edsp control menu doesn't appear setting to -10dBv did that by itself ( i need to go to work, so i'll not be here anymore today , sorry, and thx for your support )

Jul 28, 2009, 03:14 PM	#22
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,119 Rep Power: 75	Îòâåò: Several EMU e-DSP Control bug it seems the problem is a bit more complex... "IKX_DEVICE_CHANGED" notification is not the best place to change ikx pointer, since there are two kX add-ons uploaded. iEDSPControlAddOn is instantiated for each card, thus, it should never change its ikx pointer. the iEDSPControlAddOn::activate() function creates EDSP Dialog instance, but does not pass the desired device number, that's why 'activate' will always open edsp window with 'current' device, regardless of the menu item selected. EDSP Dialog is bound to the addon by pointer, but accesses ikx hardware by using internal pointer, which is not constant. I will try to fix this in the next driver release. E.

Jul 28, 2009, 05:40 PM	#23
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug I understand that it is supposed to be a per device addon, and normally you would not want to change the ikx pointer for that type of addon, but part of the problem is (as I said previously), that only one addon instance is handing the menu events for each addon instance. So (until that bug is fixed) even if the device number is passed to the dialog in activate(), the same addon instance is going to handle the event, so you will still get the same result, regardless of which item was chosen from the menu. Changing the ikx pointer was basically a workaround for that problem (I guess I should have said it was a workaround, instead of a fix... but I did say that the menu thing was still an issue ). i.e. (with the original code) I added a device number variable to the addon, which is assigned the value of p in init(). In the code that generates the menu text, I added this device number (so that I am able to know which item is which on the menu), and I added debug output to the KXADDON_EVENT_MENU notification that prints the device number. In my testing, it (KXADDON_EVENT_MENU) always printed the same device number (in my case, it always printed "1"). The other issue is that you can do device selection within the addon's GUI (as well as in kxmixer, etc), but it does not generate a select_device() call, so the dialog does not get refreshed until some other action generates the select_device() call (which is why I added the select_device() call to the IKX_DEVICE_CHANGED notification). Last edited by Russ; Jul 28, 2009 at 06:21 PM. Reason: clarification

Jul 28, 2009, 07:15 PM	#24
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,119 Rep Power: 75	Îòâåò: Several EMU e-DSP Control bug why do you think the same addon instance handles the event? if I'm not mistaken, kX mixer sends different events to different add-ons (because menu_id is generated on per-addon basis) so, if you choose the first e-dsp control, the first add-on will get 'activate' event if you choose the second e-dsp control, the second add-on will get 'activate' event but: since they both launch edsp GUI in the same way, the GUI applet will keep working with the same device (but 'reset microcode' command will be sent to the correct device) moreover, changing device in E-DSP Control is useless, because it does not process this event properly (and it cannot re-associate itself with a different add-on) I'm planning to fix this the following way: * pass device number from the addon to EDSP GUI during instantiation * disable device selection in EDSP GUI * show port number in the kx menu ("E-DSP Control [d800]") Although this is not the best solution, it should work. And most people don't have two E-mu cards installed anyway Let me know what do you think. E.

Jul 28, 2009, 07:45 PM	#25
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug Right, when I added the device number to the menu text, it showed (I have 2 cards): E-DSP Control: 01 E-DSP Control: 00 ...which indicates that the menu item is generated by each addon instance. But, when I printed out (debug output) the device number in the KXADDON_EVENT_MENU notification, it printed "01" as the device number (I also included some other info such as the card name, and again it was always the same), regardless of which menu item I chose, and regardless of which card was the currently selected device in kxmixer. I think it is only the KXADDON_EVENT_MENU notification that has the problem, as I do see the notification for KXADDON_EVENT_GENERIC sent to both addon instances when I change devices in kxmixer, etc. (i.e. debug output prints both device numbers with that notification). Your plan sounds good provided that the menu works correctly (otherwise it seems people will only be able to configure one of the cards (probably whichever one is the default when Windows starts)). Last edited by Russ; Jul 28, 2009 at 07:53 PM.

Jul 28, 2009, 08:49 PM	#26
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug I just checked something else. I had unregistered my addon (PluginQL) while testing this, and I just re-registered it to test something, and it seems that the same E-DSP Control addon instance is trapping the menu events from my addon as well. i.e. If I choose the first menu item from my addon, it launches the E-DSP Control Panel instead of doing what it is supposed to do (and prints out the debug info from that addon (E-DSP) instance), and the other menu items from my addon (which normally do what they are supposed to do) do nothing. Last edited by Russ; Jul 28, 2009 at 08:57 PM.

Jul 28, 2009, 09:52 PM	#27
Eugene Gavrilov kX Project Lead Programmer and Coordinator Join Date: Dec 2002 Posts: 3,119 Rep Power: 75	Îòâåò: Several EMU e-DSP Control bug Russ, thanks for helping me with this problem. Unfortunately, I don't have two cards installed, so I cannot test all this easily.. I tried to fix the bug in 3548 - and also included certain parts of the kxmixer source code (including addonmgr.cpp/h files) - so, I hope this sheds light on this bug. Print to the debug console 'menu_base' variable for both instances of your add-on. For each instance, menu_base should be unique, and should be within the interval of 0..MAX_ADDON_MENU_ITEMS incremented by MAX_ADDON_MENU_ITEMS for each addon. Check that addon::menu() adds the menu item with correct menu_base value. E.

Jul 28, 2009, 10:27 PM	#28
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug Currently (3545b) "menu-base" shows 1100 both before and after "menu->add" for both instances of the E-DSP addon (making the menu id "1101" for both instances, which is also the value that "p1" has in the event handler when either item is selected). That also appears to be the base value that my plugin (PluginQL) gets assigned. I have to go do a few things, but I willl check out 3548 the first chance I get. Last edited by Russ; Jul 30, 2009 at 07:42 AM. Reason: removed irrelevant info

Jul 30, 2009, 03:36 AM	#29
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug I have only been able to do a little testing with 3548 thus far, but it seems there are still issues with the menu handling. Both menu items still bring up the control panel for the same card. "menu_base" never appears to get auto-incremented internally, so all addons get the same menu_base, and thus the same starting menu id's. Even if you try to force a unique id for each menu item (i.e. by doing something like: menu_base+1+ikx->get_device_num()), the same addon instance still handles the menu events for both id's (even though each menu item was generated from different addon instances). Last edited by Russ; Jul 30, 2009 at 10:16 AM. Reason: clarification

Jul 30, 2009, 09:22 AM	#30
Russ HardwareHeaven Extreme Member Join Date: Jan 2005 Posts: 5,561 Rep Power: 62	Re: Several EMU e-DSP Control bug I took a look at the addonmgr code and now I understand how it is supposed to work. The problem is definitely the menu_base. I can see that the code is supposed to increment the menu_base by 10 for each addon, but for some reason (I did not see any obvious reason) the value assigned to each addon is not incremented by 10 (or at all). The menu_base has to be not just unique (between addons), but also 10 apart because the menu processing code checks the menu id, and enumerates through each addon to see if the id is within the range of it's menu_base+10, and sends the event only to the addon with that range. If they all have the same menu_base, then the first addon in the list is always going to handle the message (which is what is happening now). As a test, I added code to init() to force the menu_base to be 10 apart for each addon instance: i.e. menu_base += p * 10; With the above change, the menu handling worked correctly, and each E-DSP menu item brought up a different control panel (like it is supposed to do). I noticed an important clue: If I run multiple per device addons: The menu_base is incremented by 10 for each per device addon (but not for the per device instances). If I run multiple system wide addons: The menu_base is incremented by 10 for each system wide addon. If I run a per device addon and a system wide addon, the menu_base is the same. I suspect if I run multiples of both, the menu_base will be the same for both for the first instance of each kind, and the same for each additional addon of each kind, but incremented by 10 (from the first instance of each, but not each other). [EDIT] This is confirmed. I ran the below test and the results where as posted. [/EDIT] i.e. (if the above is not clear) If 3 of each kind of addon were running at the same time, on a system with 2 cards: System_Wide_Addon_1: menu_base = 1100 System_Wide_Addon_2: menu_base = 1110 System_Wide_Addon_3: menu_base = 1120 Per_Device_Addon_1 - Instance 1 (1st card): menu_base = 1100 - Instance 2 (2nd card): menu_base = 1100 Per_Device_Addon_2 - Instance 1 (1st card): menu_base = 1110 - Instance 2 (2nd card): menu_base = 1110 Per_Device_Addon_3 - Instance 1 (1st card): menu_base = 1120 - Instance 2 (2nd card): menu_base = 1120 So, from the above, it seems as though maybe a different (or new instance of the) addon manager (or addon list or something) is used for per device addons, and system wide addons, and per device instances. Last edited by Russ; Jul 30, 2009 at 08:03 PM.