Additional panning algorithms (VBAP, DBAP)? "Plugins"?

[spluta]

I think we go with specified num_speakers and simd_out_size.

Implement that and then try to give it a 7 or something. I would be surprised if it compiled.

BTW - in your example, I had to reverse the mouse_y output because the top of the screen is 0 and the bottom is 1.

[drewmfarrar]

Sounds good, will do. Ah, good to know. Is there an easy way to print in mojo for debugging purposes?

[spluta]

self.world[].print(thing, thing, thing)

it prints every 10 blocks by default, but you can specify any number of blocks.

[tedmoore]

@drewmfarrar

At least for myself, this would reduce the likelihood of making a mistake when using a new panning function.

Reducing “exposure to error” is pretty much always good design.

@drewmfarrar

The only issue is that a user might not provide a valid simd_out_size and this will throw the same kinds of errors that the current solution causes. Though maybe some error handling would help? I’m not really familiar with how Mojo’s error handling works. It’d be great if it could catch the error at compile time and spit out an error.

You can do:

comptime assert boolean_expression, error_string

See: constrained | Mojo

[spluta]

I just made it so that TGrains can accommodate any N channel panning algorithm.

If the user creates a custom grain and then uses next_multi_channel as the next function for the grain, they can put dbap or the future vbap implementation inside the function and pan each grain individually around the multi-channel space.

[drewmfarrar]

A few updates:

The vbap2d function should be working properly now! Scaling up the math for 3d should be pretty easy but I want to make sure that the 2d implementation is good first.

Also, the fake mouse isn’t working on WSL at the moment, though there must be some reason for this. I can do a bit of tinkering and see if I can’t figure out why. I’m assuming it’s some funky interaction with WSLg? Currently the values jump back to center every time the slider is moved. I don’t think this is a huge deal, I can try to find a workaround and document it.

edit: Actually, the fake mouse is working now? I’m not sure why that was happening but it’s no longer an issue.

edit again: The fake mouse is broken again! No idea what breaks it…

[spluta]

re: fake mouse

I wonder if this is a timeout issue in python? sometimes the mouse also doesn’t work. i think this is because compilation takes too long and then the mouse startup doesn’t happen.

One solution is to compile the executable separate from running it:

MMMAudio.compile(“MyVBAPExample”, “examples”)

Then when you run it there is no delay for compilation.

[drewmfarrar]

Tried to precompile the executable and still no luck. I think this might be a different issue for WSL. My Linux desktop doesn’t have this issue. I don’t think it’s worth the effort to support WSL mouse support out of the box though (assuming that Mojo will eventually come to Windows…). I can make a bandaid fix for myself and then if others are trying to use WSL they can reach out to me and I can make it available.

[tedmoore]

@drewmfarrar

I don’t think it’s worth the effort to support WSL mouse support out of the box

That seems fine to me. I think MMMAudio probably doesn’t need to provide “mouse” support “out of the box” for any system (there might be other dependencies not needed too). Keeping the necessary dependencies slim might be wise.

The nice thing about mouse support as it currently exists is that there is a dedicated Messenger path to get the mouse value onto the audio thread, but patching a Messenger path is quite straight forward so might not be a big loss.

If one wants to turn on the pyautogui mouse but MMMAudio doesn’t require it as a dependency, I could imagine something like this,

import pyautogui # user needs to install and import it

MMMAudio.pyautogui_mouse(true) # turn it on, or with false, off

Or instead of passing in true a callback function is passed in that gets the x and y position on every update?

That way it’s not on by default, but MMMAudio still has a really slick way to use it.

[drewmfarrar]

I really like the idea of passing a callback function in, being able to change the mouse mapping on the python side instead of the mojo side would save some time when making changes. I think requiring the mouse to be turned on or off would fix the weirdness happening on the WSL end as well (I think it’s getting conflicting mouse and GUI info). It could possibly look like this:

def mouse_mapping(x, y) -> List:
   from numpy import interp
   return [inter(x, [0, 1], [-1, 1]), interp(y, [0, 1], [1, -1])]

MMMAudio.mouse(mouse_mapping)

MMMAudio.fake_mouse(mouse_mapping)

It would keep the formatting consistent between both mouse and fake mouse implementations and limit the chance of crosstalk.

[tedmoore]

Seems reasonable to me.

[spluta]

I like it. As long as the default behavior feels the same it would be a nice improvement.