How to inject a new argument for each generated listener instance?

[digable1]

Hi,

I'm not sure if this is an issue or operator error (perfectly willing to stipulate it could be the latter if that's the reality).

I'd really like to follow the "press button, generate listeners" pattern with an Input's addListener for "noteon" and channels = [1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16] (I'll deal with EventEmitter.ANY_EVENT separately).

Well that almost works: I get 16 listeners for "noteon" (they're all enabled).

And I get 16 calls to the listener callback when running, presumably one per channel.

The problem: Each call in the callback's MessageEvent.message.channel has a value of 1.

I was expecting a value of 1 - 16 depending on the listener instance making the callback. So I have no way of binding the specific instantiated listener to the appropriate callback instance. And I can't set an argument value in addListener(...) to the channel I want each instance to care about because it's the same arguments for each instantiation since I'm asking WEBMIDI.js to handle the instance creation for me, plus I'd have to inject the argument after the instances are created.

Yes I'm lazy - I was thinking of one call to Input.addListener() with an injected argument as opposed to 16 calls to InputChannel.addListener(...). But is InputChannel.addLister(...) the way I have to go?

The idea: Is there a way of injecting extra arguments after the creation of the instances in Input.addListener(...)?

Update: I've worked around this by creating the listener one channel at a time - and it's doing what I want. But I still suggest it's cleaner and should be possible to do the "per instance" injecting of an argument with multiple channels. Plus I'm still not not sure why I was getting 16 invocations of the listener for channel 1 when I specified 1 - 16 (yes I know undefined does the same thing)

Thanks!

[djipco]

Do you have a small working example that demonstrates the problem? I just tried it on my side and it works fine.

[digable1]

It turns out that my conditional checks for looping through the instantiated listeners and only doing the one that matched the channel in the listener was completely wrong. Which is why I observed the above behavior.

So, the original analysis above is a complete red herring! My first "small working example" behaved correctly, just as you observed.

So here's the new analysis after a deeper dive (there is an actual esoteric issue, but it's also really bad software development practice - bad enough to probably flunk any computer science test at the 101 level):

1. I go through my listeners created with addListener(...) after the fact, modifying my 'assigned channel' element in arguments[]. This is what I was using to bind a listener channel with a specific instance. Note: I didn't see where this information was located in the Listener object, but I could be blind (no comment about deaf and dumb).
2. When I did that assignment to one element in the array for one channel listener instantiated with addListener(...), all instantiated listeners for the specified channels are also set to that value!

So I did my impression of mimicking a mock subset of a Listener, and tried to replicate this behavior. And while I haven't gone through your code, I have a speculation based on the attached "small-ish working example":

listener_demo.zip

The take-away: Do you initialize the arguments array via an Array.fill(...) or a mechanism that does not instantiate each element of the arguments[]?

Of course, ideally, there should either be a way of the listeners identifying the channel they might be associated with for this sort of binding or a way of injecting changes in arguments[] after instantiation - avoiding the putrid code small of mutating after instantiating. But hopefully you see the use case that sent me down this rabbit hole.

In the meantime, going back to the "single-channel" instantiation that also avoids this issue and all is well with this part of the world.

[djipco]

I appreciate you taking the time to prepare an example but it looks much larger than necessary to demonstrate an issue that sounded quite specific in your first message. Honestly, at this point, I'm just not sure what you are asking or what the problem is. Perhaps you could break it down and identify what the result is in contrast to what you expected it to be?

[digable1]

Synopsis:

I would like to populate the arguments after instantiation - and ideally provide direct access to these arguments in the MessageEvent payload available from the actual listener.

In the meantime, I'm keep a Map<event-name, Listener | Array to provide this capability within the listener (via MessageEvent.type). But if it's an array of Listener objects, what index of that array applies to which channel?

1. One approach was to inject into the arguments[] array after a multi-channel instantiation call to Input.addListener(...). This is what I can't can't seem to currently do, even from a hacky direct-mutation perspective iterating through the original created array of the array of Listener objects.
2. The demo illustrates that this doesn't work and I possible reason why (I was trying to figure out why this happened, it felt like such a newbie misunderstanding - which it could still be. Therefore I'd like to treat the arguments[] array as mutable - even if it's through a defined API (actually the ideal).

So if I want to change the value of arguments[3] after instantiation, I don't want the same value being applied to the rest of the Listener objects being created - which it currently is.

That help at all?

[djipco]

Okay, I think I now understand what you want to do. Let me break this down because there is a lot to unpack. When you add a listener, you can pass an objects with additional options. One of the options is an array of arguments to pass to the function that is called when the event is triggered. You can put anything you want in this array. For example:

const opts = {arguments: ["foo", "bar"]}
WebMidi.inputs[1].addListener("noteon", (e, arg1, arg2) => console.log(arg1, arg2), opts);

This would print foo bar in the console when a noteon is triggered.

Now, if I understood you correctly, you want to modify these arguments after the listener is created. This is also possible. Here's how you would do it:

const opts = {arguments: ["foo", "bar"]}
const listeners = WebMidi.inputs[1].addListener("noteon", (e, arg1, arg2) => console.log(arg1, arg2), opts);
listeners[0].arguments = ["Hello", "World!"];

This would print Hello World! in the console when a noteon is triggered on channel 1 BUT it will print foo bar for all other channels.

Your question is: But if it's an array of Listener objects, what index of that array applies to which channel? The answer is that the listeners are created in numerical order. So, listeners[0] is for MIDI channel 1, listeners[1] is for MIDI channel 2, etc. The library uses forEach() to loop through the 16 MIDI channels internally and the spec says that forEach() works in ascending order. So, it should be safe to rely on.

As you already know, the message payload does not include the additional arguments. This is by design. The arguments are simply passed as additional parameters to the callback function.

In any case, you can still retrieve the arguments within the callback. I hope this makes things clearer.

[digable1]

That's just it - that solution doesn't work.

1. Let's see I use Input.addListener(...), with the options.channels array at [ 3, 5 ], meaning I want a listener for midi channels 3 and 4. And arguments are populated with [ "foo", "bar" ]
2. As you know (it's your project), I now have an array of Listener objects, length 2, which I decided to put in a constant "listeners"
3. Let's say I want the arguments for channel 5's Listener to be [ "Hello", "World!" ] - which means I'm changing listeners[1].arguments to [ "Hello", "World!" ] to follow your example.
4. "listeners[1].arguments = [ "Hello", "World!" ] also sets listeners[0].arguments to [ "Hello", "World!" ] - as my demo points out. Not the desired behavior.

One take-away: I did not see that the listeners are indeed created in sequential order in the documentation. Did I not look hard enough? If that is truly published behavior, that knowledge would indeed handle my use case. Did I miss this, or can I request it be published if you truly mean to define this behavior in this manner?

[djipco]

In all honesty, I did not go through your entire code. However, I believe the situation can be illustrated with these 5 lines:

const opts = {channels: [3, 5], arguments: ["foo", "bar"]};
const listeners = WebMidi.inputs[1].addListener("noteon", (e, arg1, arg2) => console.log(arg1, arg2), opts);
listeners[1].arguments = ["Hello", "World!"];
console.log(listeners[0].arguments);
console.log(listeners[1].arguments);

When I run this code, I get the following in the console:

foo bar
Hello World!

Is this not what you are getting?

[djipco]

I did not see that the listeners are indeed created in sequential order in the documentation.

I added a mention in the documentation to clarify that the array of listeners returned by Input.addListener() follows the order that the channels were specified in.

[djipco]

I went back to your code and I think I spotted the problem. The problem is that you are not replacing the arguments array but rather mutating a single value inside it. It is akin to doing this (going back to my previous example):

const opts = {channels: [3, 5], arguments: ["foo", "bar"]};
const listeners = WebMidi.inputs[1].addListener("noteon", (e, arg1, arg2) => console.log(arg1, arg2), opts);
listeners[1].arguments[0] = "Hello";
listeners[1].arguments[1] = "World!";
console.log(listeners[0].arguments);
console.log(listeners[1].arguments);

In this case, the result will be:

Hello World!
Hello World!

This simply illustrates that all listeners are passed the same reference to the original arguments array. So, if you change one element of that array (which is the same for all listeners), the value will be changed for all.

If you want to change the value for a single listener, you need to overwrite the reference with a reference to a new array.

[digable1]

That's exactly what I also discovered! And indeed that's it!

[djipco]

I'm sorry I didn't think of that earlier. This is a classic JavaScript reference problem. It does have the advantage, though, of letting you work locally or globally in such a case.

[digable1]

And I'm embarrassed that I didn't catch it either - I am far from being a newbie...I really am! Honest!

[djipco]

No worries. I, too, have had more than my share of such oversights (which can be so frustrating). That's just the hard reality of a programmer. I'm just glad we could nail it down.

In the end, our discussion did bring value to the library by having me clarify the documentation regarding the order of the listeners in the returned array (which, to be honest, I had never really considered).

Cheers!