[Microbit-Python] Current state of play - a summary and straw man

David Whale david at thinkingbinaries.com
Tue Oct 13 13:56:34 CEST 2015


If we could get this module built into the build, it would probably work
out of the box over USB, which would be a complete game changer for things
like SonicPi (which apparently supports MIDI).

https://developer.mbed.org/cookbook/USBMIDI

David


___________________________________________________________
David Whale, B.Sc (Hons), MIET
*Software Engineer and IET Schools Liaison Officer, Essex*

email:  dwhale at theiet.org
twitter: @whaleygeek
blog:  blog.whaleygeek.co.uk

Co-author of the new book "Adventures in Minecraft" <http://amzn.to/ZGfxZG>
- lets get kids coding!


On 13 October 2015 at 12:11, Nicholas H.Tollervey <ntoll at ntoll.org> wrote:

> Hi David,
>
> On 12/10/15 23:49, David Whale wrote:
> > Regarding MIDI
> >
> > All the MIDI needs to connect to an external MIDI synth (e.g. a keyboard
> > with a MIDI IN port) is a UART Tx on one of the pins running at
> > 31250bps,n,8,1. Damien, is there a DAL api or something in the
> > MicroPython that exposes the on-pins UART? This would be a MIDI-OUT from
> > the micro:bit
> >
>
> Damien states in his reply the MicroPython supports UART. Not sure what
> information you need to start playing around.
>
> > MIDI-IN could be interesting, it would mean you could press a button on
> > an external keyboard synth, and a note-on message would come into the
> > micro:bit - what you would do with it then I'm not sure, so perhaps this
> > is less valuable?
> >
>
> This is VERY valuable since MIDI is used by VJ / DJ type people to
> signal all sorts of events in multimedia displays. Someone at the BBC
> got very excited when I mentioned we were only looking at MIDI.
>
> >
> > The messages are very simple and well defined (mostly 2 byte messages).
> > There is a small single chip circuit (opto isolator) that is required to
> > make the electrical connection.  You can then play any note and change
> > any controller (e.g. shake the micro:bit to do a pitch bend could be
> > real fun!)
> >
> > MIDI over USB (e.g. so the micro:bit is presented as a MIDI device to
> > the PC/Mac) is much harder, because it requires the USB descriptor in
> > the interface chip to be reprogrammed and we don't have access to that,
> > so I think we should forget that idea.
> >
> > I spoke to Martin Wooley about perhaps MIDI over bluetooth (there is a
> > profile for it), but he didn't seem keen in making any changes to the
> > existing profiles, preferring the innovation to happen at the PC end.
> >
> > So, plug your micro:bit into a small chip and then into a 5-pin DIN plug
> > in the back of your synthesiser could be really great, it might also
> > open up SonicPi access by using a MIDI/USB adaptor into the PC/Mac/Pi.
> >
> > Mostly the code would be a set of constants for the message types and
> > note numbers, perhaps with a few wrapper functions in python (note_on,
> > note_off, play, set_patch, control_change, sysex).
> >
> > I sense the only way to make this happen would be for me or someone to
> > write a quick spec for the API, then anyone could actually write the
> code.
> >
> > Given the API is so thin, if there is a good API for UART, this could
> > easily be a python frozen module as it's then easy for anyone to write
> > and test and contribute to the mix.
> >
>
> Exactly, although making it "native" would be better.
>
> >
> > It does beg the question whether we should consider a 'redirect' option
> > from the music module Matthew is writing, so you can either play beeps
> > through the speaker, OR send MIDI note messages, using the same lovely
> > API. Note MIDI has controllers (like pitch bend) that would be excellent
> > to expose for things like 'accelerometer tilt varies pitch bend or
> > modulation wheel'.
> >
>
> Agreed.
>
> > If timing is tight, it would be possible I think to write this as an
> > example py program instead, and bring it in as a frozen module later
> > perhaps. I have a huge amount on at the moment I'm not sure I could
> > commit to making all this work in time for a V1 release window.
> >
>
> Hmm... ok. What can we do to help make this happen?
>
> N.
>
> > David
> >
> >
> > ___________________________________________________________
> > David Whale, B.Sc (Hons), MIET
> > *Software Engineer and IET Schools Liaison Officer, Essex*
> >
> > email:  dwhale at theiet.org <mailto:dwhale at theiet.org>
> > twitter: @whaleygeek
> > blog:  blog.whaleygeek.co.uk <http://blog.whaleygeek.co.uk>
> >
> > Co-author of the new book "Adventures in Minecraft"
> > <http://amzn.to/ZGfxZG> - lets get kids coding!
> >
> >
> > On 12 October 2015 at 22:59, Damien George <damien.p.george at gmail.com
> > <mailto:damien.p.george at gmail.com>> wrote:
> >
> >     Yes, I think we need some direction and goals to get uPy on the
> >     microbit to a "v1.0" state.
> >
> >     We've had a lot of good ideas, discussion and contributions.  I think
> >     we are close to having a very usable API.
> >
> >     > * Music API - first draft of Matthew's native API is merged into
> master.
> >     > Requires further development to allow it to work in the
> background. I'll
> >     > be adding musical examples over the course of this week and
> testing it
> >     > from a musician's perspective.
> >
> >     I think the music module is wonderful.  It's so easy at the REPL to
> do:
> >
> >     music.tune(pin0, ['c', 'd', 'e', 'f', 'g', 'a', 'b', 'c'])
> >
> >     or even:
> >
> >     music.tune(pin0, [chr(ord('c') + i) for i in range(8)])
> >
> >     or better still:
> >
> >     music.tune(pin0, list('cdefgabc'))
> >
> >     Yes it needs work to have non-blocking mode.  And builtin tunes would
> >     be awesome.
> >
> >     > * Larry's game related work - I think this is hugely important.
> Kids
> >     > love games and showing off their work to each other. If we can
> make it
> >     > super easy to facilitate such hacking then we're doing something
> >     > marvellous.
> >
> >     Yes, it's great to have Larry's experience with game writing to make
> >     a good API.
> >
> >     > * Marks' image related work - again, this is hugely important
> because
> >     > being able to see the result of your code is a great inspiration to
> >     > kids. The easier and more capable we make this the better it'll be
> for
> >     > all concerned.
> >
> >     Yep.  Even with the additional features added here, we still have a
> >     really easy entry point to simply scroll a message or animate a
> >     sequence of images.
> >
> >     > * Damien's suggestion of inline assembler which sounds like it'd
> be a
> >     > wonderful thing for the hacker/maker audience the BBC are also
> hoping to
> >     > tempt as a secondary market.
> >
> >     I can add this if we think it'll be attractive.  There are 2 options:
> >
> >     1. A simple "machine_code" function that takes raw bytes and turns
> >     them into a function.  Very hard to use, eg: fun =
> >     machine_code(b'\x12\x34\x56') and you have to find out the correct
> >     byte values by assembling offline with an arm assembler, then looking
> >     at the output.  Really hard to use (but then that might give it a
> cool
> >     factor!).
> >
> >     2. The proper inline assembler that already exists, where you write
> >     code like:
> >
> >     @micropython.asm_thumb
> >     def f(r0, r1):
> >         label(loop)
> >         add(r0, r1)
> >         bne(loop)
> >
> >     This is easier to hack, but since it's verbose you'll run out of
> >     memory (in the compile stage) if you try to write long functions.  It
> >     also takes up flash space (not too much though) and maybe in the
> >     future we need this flash space for other things?
> >
> >     Regarding attracting the hacker/maker audience: I think it's
> important
> >     to point out that starting with the microbit is an entry point to
> >     learning MicroPython, and then people who want more can buy a more
> >     capable board that runs uPy (eg pyboard).
> >
> >     Oh, and uPy on the microbit also supports I2C and UART interfaces,
> for
> >     those that want to interface with other electronic components (temp
> >     sensors, etc).
> >
> >     > * David's MIDI related suggestions. I'm not clear what would be
> involved
> >     > for this - I presume we could use USB/serial to send MIDI
> information to
> >     > a MIDI device running elsewhere. David, it'd be helpful to learn
> how you
> >     > see this working.
> >
> >     I don't have any experience with MIDI, so also don't see how this
> >     would work (and can't really test it...).
> >
> >     > * Damien and I discussed turning the display into some sort of
> generic
> >     > graphical equaliser for arbitrary data.
> >
> >     It would be neat, but I think this would be a lower priority (unless
> >     the BBC really likes the idea...).
> >     _______________________________________________
> >     Microbit mailing list
> >     Microbit at python.org <mailto:Microbit at python.org>
> >     https://mail.python.org/mailman/listinfo/microbit
> >
> >
> >
> >
> > _______________________________________________
> > Microbit mailing list
> > Microbit at python.org
> > https://mail.python.org/mailman/listinfo/microbit
> >
>
>
>
>
> _______________________________________________
> Microbit mailing list
> Microbit at python.org
> https://mail.python.org/mailman/listinfo/microbit
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/mailman/private/microbit/attachments/20151013/08886d59/attachment-0001.html>


More information about the Microbit mailing list