Categories
Blog Music

Prototype rig for new module

Today I mocked up a rig for a rhythm module I’ve been dreaming up for ages called ‘Chains’. The three vertical bars are SoftPot linear touch-sensitive potentiometers and the screen will give visual feedback on what’s going on internally.

dsc_0341

The five inputs on the left will handle clock, reset and two individual analogue inputs which can be recorded to each chain – I’ll need some kind of toggle switch here to select.  The fifth input is an idea I’m keen to play around with: quantisation and anti-quantisation. The idea is 0V will leave a recording as-is, +5v will pull an event to the nearest 16th or 32th note, but -5v will push it away by the same amount. I have no idea if this will work but it’s there to try as the whole idea is ways of making rhythm more organic.

There are space for a few more inputs as needed but I’m going to start simple. Most of the interaction is done through the buttons under the screen. I’m using big, clear buttons for actions rather than fiddling around with a rotary encoder as this needs to be fast and intuitive for live interaction. The buttons will handle things like record, clear, motif load/save. I also need something for motif length adjustment – maybe individual tempo too – and I’m sure there will be more idea so the sixth button is for experimentation or may end up being a dreaded ‘shift’ button so I can double up operations on the five other buttons.

Finally the outputs on the right simply dump out whatever is on a particular chain at that point in time, be it CV or gate info. I’m glad I built this on cardboard because it gave me a better sense of positioning the controls away from the pots, it’s fun developing UX physically (well, it’s not really UX if you’re a purist, but it’s a step up for me dreaming things up and expecting them to work first time!).

dsc_0342

From the back the board is a scramble. I’m using the bigger Arduino as a mock up purely because I don’t know how many inputs or outputs I’ll need for now, it’s overkill. The final version I’d like to bake into an AVR but I’m thinking that being able to upload firmware will be a massive boon for rapid development if I ever made this thing commercially.

Categories
Blog Code

Designing clean API for AVR round-robin ADC – part 2

I’ve been learning more C++ 11/14 and I initially wanted to build a nice API using variadic templates. When used correctly one can build a clean API with templates that compile down to very small code. Unfortunately AVRGCC does not yet support C++ 11/14 so I can’t follow that route.  Here’s my bullet point summary of the day’s findings:

  • Early template classes experiments messy/confusing.
  • C++0x14 does not work on AVR right now anyway.
  • Linked lists simply don’t optimise away.
  • Virtual methods don’t optimise away.
  • Best approach seems to be general class.
  • Static functions in a namespace compile even smaller than class.

My strategy here was to start with a nice OOP design and rapidly iterate ideas using Compiler Explorer to see where it took me.  I built with AVR gcc 4.5.3 with the flags -Winvalid-pch -Wall -Wno-long-long -pedantic -Os -ggdb -gstabs -mmcu=atmega328p -fdata-sections -ffunction-sections -fsigned-char

Test 1 : Linked lists

My starting point was a singly linked list of AdcInputs. The AdcManager polling the next via interrupt whilst traversing the list. The derived classes would present a nice API.

adcinput

Given my code sample I was hoping the compiler would be clever enough to optimise a lot away, but I am storing data in virtual classes so there’s a lot of vtable setup, calls and the pointers in the linked list are still used in code:

adcinputtest1

Tests 2 – (n-1) : No man’s land

Here’s where it gets a bit messy going through my notes because I didn’t keep copies of all of my in-progress code. In summary I realised that virtual classes and linked lists were not the way to go and experimented with template magic and functors before settling on a simple solution of a central do-it-all manager class.

The problem was making a reasonably friendly access interface out of it. For my applications there are only a few variations on the types of ADC interface, they mostly store a uint8_t as the value – with the edge case of using 10 bit resolution – so would it be possible to cram all the other data into another byte? I could use say 2 bits to store the type of interface and the remaining 6 could be used by each interface’s implementation. For example, storing a ‘pushed’ state for a SoftPot.  In total that gives me a standard 2 byte struct for each interface which I can simply store in an array for the manager.

The bit wrangling ideas came strongly from this hybrid data structures video. They use a heavily templatized method to access bits whilst remaining robust enough to avoid memory stamping.  I’d like to that more in future but for now I’m just using plain old bit fields.

Swapping out the linked lists for a fixed array adds memory overhead because that chunk of memory is always used. However I select AVR chips based on spec; if I only need 3 inputs then I look for the closest match chip rather than an overspecced AtMega328.

This code is an experiment during this stage.  It’s not pretty but I’m sharing it because it helped me realise the value of using static correctly in optimisation. Here’s what happens when you remove the static keyword from AdcRunner::update():

adcinputtest2

Test 3 : template accessors

With the manager ‘class’ now simply being a bunch of static functions, I’m using a templatized base class to give the user access to each one. Here’s the core class. ADC_TYPE is an enum that defines my fixed set of ADC interfaces. The interface stores a reference to data which is handled by the manager. The idea is as a client you use these objects on the stack merely as accessors to the manager’s data, and that the manager uses these objects to update its data correctly.

template <Type ADC_TYPE>
class AdcInput
{
public:
  AdcInput(Data& data) : m_data(data) { }
  static Type getType()        { return ADC_TYPE; }
  static uint8_t getTypeBits() { return (uint8_t)getType() & 0x03; }
protected:
  Data& m_data;
};

Here’s an example concrete implementation softpot input.  It has accessors for getting the value and determining if it is pressed.  The update method will be called from the manager, it’s a bit ugly but it’s in progress.

class Softpot : public AdcInput<kSoftPot>
{
public:
  Softpot(Data& data) : AdcInput(data) { }
  uint8_t getValue()   { return m_data.value; }
  bool isPressed()     { return (m_data.info & (1 << 4)) != 0; }
  void adcUpdate(); // TBC... this is how the manager updates this data
};

Here’s some code to get a feel for the API

  init_adc();
  add_adc<Pot>(0);
  add_adc<Softpot>(1);
  
  Pot p1 = get_adc<Pot>(0);
  Softpot p2 = get_adc<Softpot>(1);

  for (;;)
  {
    uint8_t val = 0;
    if (p2.isPressed())
      val = p1.getValue() + p2.getValue();
    else
      val = p1.getValue() - p2.getValue();
  }

 

adcinputtest3

The full version of the test code and compiled output is here and the generated output is on the right.

The current problem with this is that there is no fail-safe on getting the wrong type of object. For example in the above code I have a pot on 0 and a softpot on 1, but there is nothing stopping me trying to read 0 as a softpot. This is not the right place to use exception handling. One option is to store a block of clearly invalid data like 0xFFFF, which you can pick up in debug, but it irks me.

Next step is to try this in action on the AVR and look at the generated assembler with the interrupt handler in place. I have no doubt it will be a little bit longer than writing the code in plain C but I wanted to experiment with something more scalable, and I’ve learned a few things on the way hence this blog post.

Also learned today

  • Today I needed a nice UML editor so I turned to Stack Overflow for advice.  I initially tried Umler, then ArgoUML because I like the developers but it’s a real fiddle (no cut/paste/undo!) so I went Dia which immediately felt nice.  Also jogged my UML memory with this guide.
  • It’s hard to keep blog posts short. Bear with me on this, I’m learning the ropes!
Categories
Projects

Back in the swing of things

I’m not sure how but over the past few months the subscriptions have shot up on my youtube channel. It’s motivated me to get back into making. A young viewer asked if it’s possible to make robot arms so I dusted off the bricks and made a little tutorial.

This is not really one of my arts projects but I’m putting it on the front page just because I’ve been out of the loop for ages and I want to keep busy.

Categories
Blog Code

Designing clean API for AVR round-robin ADC – part 1

softpotSeveral of my recent 8 bit microcontroller projects need multiple analogue inputs. I want a nice API that allows me to have different interfaces for getting analogue values, for example reading a straightforward pot as 0-255 or 0-1023, or a SoftPot membrane potentiometer where I may also want to track whether or not it’s
currently pressed.

adc_simple

Reading analogue inputs on AVR chips takes time and the lazy approach to reading an analogue value is to set up the registers to read a value and simply wait for it to come in.  You do something like this:

    ADMUX |= _BV(MUX0);
    ADMUX |= _BV(ADLAR);
    ADCSRA |= _BV(ADPS1) | _BV(ADPS0) | _BV(ADEN);
    while (ADCSRA & _BV(ADSC));	// !

That while loop is just eating cycles whilst we’re waiting for the ADC to return a result.

adc_interruptThe best way to avoid this wait is to set up the ADC to start reading a value and when it’s ready send an interrupt to get the result.

The interrupt can either use the value immediately or stash it away in a stored value so it can be picked up later on in the main loop.

This approach saves wasting cycles but still has a problem: the ADC can only read one value at a time and I need multiple inputs.

adc_roundrobin

The workaround for this is to make the interrupt run continually and constantly read each ADC value in turn.

The poll requests requests a value for a certain analogue input and when the ADC interrupt is fired off, it re-polls for the next one.  This runs perpetually whilst interrupts are enabled.

The interrupt can act on the values immediately or – if we’re not concerned about keeping everything perfectly in sync – the values can simply be stored in data so it can be picked up in the main thread.

In the next post I’ll explain how I iterated this round-robin in building a fast and clean API for AVR chips.

Categories
Blog

Brain/Project Bootstrap

Since my PhD collapsed I’ve was out of action on the making front. I’ve taken some time to clear my head and now I’m getting the urge to create things again. It’s coming on strong and the problem is when this happens I get dozens of ideas at once, and then I start them all at once, so it all falls apart pretty quickly!

To get past this I’ve resolved to take the path of the the self-indulgent project dev blog. Whatever happens on dev days gets written, the good bits and the bad bits – and there are a lot of bad bits. I’m hoping that this will give me a healthier perspective on ‘failure’ days where I’m going in circles making an API that it turns out I didn’t need, or when I get one of those days where Windows/installers failing seems to waste a whole day *

So for starters, here’s what went well today. I drove up to Nottingham to get myself a signal generator I can gut to make a music interface.  Here’s whats I gots:

marconi-panel

It will anger radio hams that I’m gutting such a beautiful thing but it’s bought more as spares and I’d probably fry myself if I tried to wire it up to the mains. I’m aiming to make this into an exploratory audience-based music interface, largely focused on rhythm. This is exactly the sort of thing my PhD was focused on – dammit – but putting frustrations aside I’m going to just going to build what I can an see where it takes me.

The unit is a Marconi CT452A and it weighs 65lbs. The insides are incredible, I was expecting straightforward vernier potentiometers on the controls but it is heavily mechanical with springs, chains and gears.  I’ve not opened the main electronics section but there are a number of exposed valves and massively enlarged transformer, caps and bridge rectifier.  It’s an old selenium one from General Electric:

marconi-super-diode

So the first part of this project – the pick up – is done. Next I need to strip back the innards and see how easily I can interact with those controls.

What didn’t go so well today was I was planning to do a bit of sight-seeing in Nottingham, but I got there so late I missed the castle. I made it the famous pub ‘Ye Olde Trip To Jerusalem’ though and the contemporary arts gallery, which was typically pretentious, but in the foyer I found an awesome book on Kubrick by Tashen. Actually one good thing there was a dark corridor with sound in the walls, I’d love to have been in a bigger version of it:

dsc_0326

I drove today to ‘Black Box Thinking’ by Matthew Syed on audible, which is part of the motivation for me getting into writing this. It’s really good.  Another good thing was this morning I managed to squeeze one more desk into the workshop which is a hugs win as every other surface is covered in half-finished projects.

* Footnote: on failed APIs and Windows-waste days. I will blog a little about these later because despite being an annoyance it’s wrong to consider them a fail or waste; I learn a lot from these things, the problem is just I don’t write it down anywhere so I forget!  I’ll aim to post about the API experiments tomorrow, it’s an interface for reading Pots and SoftPots on AVRs.

Categories
Blog Code

Self-generating C++ from embedded Ruby

Disclaimer to protect my CV: this is not something I do professionally!

I often need to generate pitch or sample lookup tables for my AVR projects. I usually generate these C++ headers with little ruby scripts.  An evil thought struck me during a long drive… I don’t like these separate little scripts, I want the script inside the header, so if you #include it you get the data, but if you run it with ruby it rebuilds itself.

The thought preoccupied me for the journey.  Preprocessor macros start with a hash, and ruby uses hashes as comments, so you can hide ruby code in a #if 0 block.

The problem was then how to stop ruby from parsing the C++ the file contains. That’s simple enough, you can hide =begin and =end in #if blocks.

The file reading and writing itself is handled using gsub() and some careful regexing. It searches for the tailing end of the table declaration and the hash of the #if that trails it, and the replaces that block with generated values.

Just to be a swine I’ve condensed the Ruby to be borderline unreadable. Save this as ‘notes.h’ and run it through ruby:

#if 0
# Run 'ruby notes.h' and this rebuilds itself.
i=IO.read($0);IO.write($0,i.gsub(/(\]\s=\s{).+?#/m,"\\1 \n #{1024.times.collect{|n|(((44100.0*64.0)/(2.0**(n.to_f/(12*16))*110.0))).to_i}.join(",\n ")}\n};\n#"))
=begin
#endif
uint16_t freq[1024] = {
  25658,
  25565,
  // ... the rest here will be regenerated
  641,
  638
};
#if 0
=end
#endif

Note the regex can’t just search for the ‘] = {‘ verbatim because it would pick up the first instance of that expression in the gsub itself; this code is reading its own text and it would replace the regex! I bypass this by swapping spaces for \s ‘]\s=\s‘.

Here the evil ends.  #include "notes.h" works fine and you can rebuild any time – and risk trashing everything if you have made the tiniest typo :)  Not a good way to approach development but a fun puzzle.  The next challenge is to do this with compile-time table generation using variadic templates.

Categories
2016

Berlin TBC

Featuring miniature music machines this December.

Categories
2015

AARC

Diverge @ ORT Birmingham

Ryan and I getting into our polyrhythmic headspace with LEGO sequencers and synths.  The full performance is on youtube or a you can see a snippet on vimeo.

Categories
2015

Mechanical Calculator Workshop

Innovative Learning Week @ Edinburgh University

Demonstrating how machines do maths, and building LEGO adders in a workshop.  My designs for this workshop are available on github.

 

Categories
2014

Wired Next Generation

Talking at Tobacco Dock exploring ideas in playful ways can help develop new insights and creative tools.  The presentation is available at WIRED UK.