Skip to content

Crash at initialisation when usb_midi is disabled in boot.py #33

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

Closed
x-magic opened this issue Jan 20, 2022 · 5 comments
Closed

Crash at initialisation when usb_midi is disabled in boot.py #33

x-magic opened this issue Jan 20, 2022 · 5 comments
Assignees

Comments

@x-magic
Copy link

x-magic commented Jan 20, 2022

I know this is not a common use case but certainly can be addressed somehow.

When I disabled usb_midi in boot.py:

import usb_midi
usb_midi.disable()  # Midi interface

Then initialise adafruit_macropad in code.py:

from adafruit_macropad import MacroPad
macropad = MacroPad()

It throws an IndexError:

Traceback (most recent call last):
  File "code.py", line 13, in <module>
  File "adafruit_macropad.py", line 172, in __init__
IndexError: tuple index out of range

Which references

# Define MIDI:
self._midi = adafruit_midi.MIDI(
midi_in=usb_midi.ports[0],
# MIDI uses channels 1-16. CircuitPython uses 0-15. Ergo -1.
in_channel=midi_in_channel - 1,
midi_out=usb_midi.ports[1],
out_channel=midi_out_channel - 1,
)

Well this makes sense. As macropad lib also initialise hid devices and similar, I haven't tried if I disable HID would it crashes the library, too.

And of course if I simply get rid of adafruit_midi library, macropad lib crashes as well.

Maybe those things should really be modular? Thanks

@fivesixzero
Copy link
Contributor

Since this is similar to #35 I did some testing to see if this could be addressed in a similar way. It looked like a len check on usb_midi.ports might be enough to see if its enabled or not.

I tested this out as a fix and it worked out well, so I've submitted the patch in PR (#37). I just noticed this got assigned to you, @makermelissa, so I hope I didn't step on any toes here by just tackling this real quick.

@ladyada
Copy link
Member

ladyada commented Jan 27, 2022

thanks! we'll look to review :)

@fivesixzero
Copy link
Contributor

Looks like this is all wrapped up with #37. Thanks to @dhalbert for the review and suggesting a slightly different, more effective approach. :)

@dhalbert
Copy link
Contributor

Fixed by #37.

@x-magic
Copy link
Author

x-magic commented Jan 30, 2022

Thank you everyone!

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

No branches or pull requests

5 participants