Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support 18 clients #97

Open
madwort opened this issue Mar 7, 2021 · 5 comments
Open

Support 18 clients #97

madwort opened this issue Mar 7, 2021 · 5 comments
Labels
enhancement New feature or request

Comments

@madwort
Copy link
Collaborator

madwort commented Mar 7, 2021

Might attempt to do an 18-way session for LIO first Sunday of April - would need to up the patching limit from 11 in order to do that!

@madwort madwort added the enhancement New feature or request label Mar 7, 2021
@sandreae
Copy link
Collaborator

I'm pretty sure all the connecting logic is ready for dealing with more clients, it's generating the ladspa plugins where we need some automation instead of a hard coded list. I had a brief go here using a numpy function to spread positions (based on number of clients) over a range. It could be a good way to go, most of the changes were in get_panning_positions which is looking smart.

def get_panning_positions(self, number_of_clients):
if number_of_clients == 0:
return []
if number_of_clients == 1:
return [0]
if number_of_clients == 2:
# Just map points between -0.5 and 0.5 for shallow 2 client panning
return list(np.linspace(-0.5, 0.5, number_of_clients))
if number_of_clients == 3:
# Fixes the strange case of 3 clients
panning_positions = list(np.linspace(-0.5, 0.5, number_of_clients))
panning_positions + (panning_positions[0] - 0.01)
panning_positions + (panning_positions[2] - 0.01)
return panning_positions
return list(np.linspace(-1, 1, number_of_clients))

Problem here is that the positions aren't ordered in any way, so some of out routing logic is probably (definitely) broken. I'm not sure if that only effects the special 1 / 2 / 3 client situations though. More thought and testing needed 👍

@madwort
Copy link
Collaborator Author

madwort commented Mar 12, 2021

Problem here is that the positions aren't ordered in any way

not sure I follow what you mean here. In the current version, they're ordered by how close they are to 0, we could replicate that with e.g.

>>> sorted(np.linspace(-1, 1, 15), key=lambda x: abs(x))
[0.0,                 0.1428571428571428, -0.1428571428571429, 0.2857142857142856, -0.2857142857142858, 
 0.4285714285714284, -0.4285714285714286, -0.5714285714285714, 0.5714285714285714, 0.7142857142857142, 
 -0.7142857142857143, 0.857142857142857, -0.8571428571428572, -1.0,                1.0]

(compare to unsorted)

>>> np.linspace(-1, 1, 15)
array([-1.        , -0.85714286, -0.71428571, -0.57142857, -0.42857143,
       -0.28571429, -0.14285714,  0.        ,  0.14285714,  0.28571429,
        0.42857143,  0.57142857,  0.71428571,  0.85714286,  1.        ])

and then the current logic might not have to change toooooo much?!

@madwort
Copy link
Collaborator Author

madwort commented Mar 12, 2021

or could do a deeper refactor, of course!

@sandreae
Copy link
Collaborator

Problem here is that the positions aren't ordered in any way

Haha, yeh, what did I even mean there....? They're ordered, well, in order. So I meant we'd need to do what you suggested 👍

@sandreae
Copy link
Collaborator

or could do a deeper refactor, of course!

What do you have in mind? 😏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants