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

[Nicholas H.Tollervey]

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
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://mail.python.org/mailman/private/microbit/attachments/20151013/35fe80be/attachment.sig>