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

[David Whale]

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

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?


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.


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'.

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.

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 12 October 2015 at 22:59, Damien George <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
> https://mail.python.org/mailman/listinfo/microbit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/mailman/private/microbit/attachments/20151012/9261859e/attachment.html>