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

ll.midi_out varname problems / convert numbered arguments to patcherargs #155

Open
chausch opened this issue Jul 23, 2024 · 3 comments
Open
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@chausch
Copy link
Member

chausch commented Jul 23, 2024

since ll.midi_out has numbered arguments adding a @varname without providing an argument nr 1 & 2 messes up the patch.

i propose changing the patch to use patcherargs 'device' and 'port' instead, so a varname can be applied without problems.

application case: to use multiple named midi outs.

@jpsteccato what do you think? i haven't used ll.midi_out before but would need to make that change in order to make use of it. any conflicts with patches of yours?

@chausch chausch added the bug Something isn't working label Jul 23, 2024
@chausch chausch added the enhancement New feature or request label Jul 23, 2024
@chausch
Copy link
Member Author

chausch commented Jul 23, 2024

ok nevermind, i managed to work around the issue, however i have another problem: the addressing via variables of the device & channel menus seems to work going out of ll.midi_out, but not the other way round.

pattr is only sending the value from the first output of umenu, but ll.midi_out seems to expect the device name as a string. possible solution: create a duplicate of the umenu inside of ll.midi_out that helps to convert index integers to name strings.

@jpsteccato
Copy link
Contributor

I think I can make the change to use named patcher arguments like you suggested that is backwards compatible with numbered args.

As for the Port and Channel, I don't think you should need to use the index number at all. @chausch If you use umenus with "Store as Symbol" attribute on, does the store and recall of port & channel work for you?

@chausch
Copy link
Member Author

chausch commented Aug 8, 2024

thanks @jpsteccato – in the meantime i worked around the issue with a custom implementation for a custom patch, but maybe we should reevaluate the issue & solution and collect important points in the discussion section?

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

No branches or pull requests

2 participants