If you flesh out your ideas about what the contraption will contain it might lend itself to different solutions
i.e. is it hand held
is the sound produced at the device or piped somewhere
the reason to say that is because some solutions may make more sense (e.g. if it became evident that bluetooth might be useful)
I’d say one thing ahead of time - try to factor in a way to scale your input such that you aren’t literally tied to a mechanism which monitors midi clock pulses or any scheme based on that - it would be better to have a system where you have enough resolution in your rotational division that you can comfortably express a range of song tempos without it getting glitchy, so maybe introduce some smoothing
i’d aim to define a system which reported 0.00 to 1.00 for one revolution, then scale that independently to taste into bpm
Another idea which may be simpler conceptually, but in practice may result in a narrower range of playable tempos is to take a step back from midi and think of a way to create pulse clicks, this would be significantly easier to engineer - then lean on a small device like a korg SQ1 which would translate incoming pulses to midi clock (or diy something) - if the SQ1/device can be hacked or partially visible you have access to transport start/stop too
Lastly - wrt the STEIM software, i’ve used that or a predecessor before - those folk know what they’re doing - so you have a good chance of having support still for e.g. the wii remote integration … you can establish pitch(angular rotation, not frequency) and roll of an embedded wii controller (centred within your barrel) and if expressed in degrees is a small conversion away from whichever way you want to process this to a stream of midi clock pulse messages
Lastly - there are apps on iphones/ipads etc which do work on the level of linear accelerations, now whether there is an algorithm also determining pitch/roll i’m less familiar (it’s doable, but not trivial maths) - maybe lemur/touchosc etc offer that - or if that route is a dead end, perhaps an embedded raspberry pi could be something to explore and think about involving Pd (probably not wrt wii) but just as a starter for other ideas - if not via arduino
in Max it would be possible to create a midi score that didn’t lean on midi clock at all, you’d just need a scheme to ‘translate’ input from a rotational component to progression along a timeline of sorts - i.e. relate incoming clicks/resistance/whatever to an accumulative position along a timeline
(wrt resistance, i was thinking if an endless SIN/COS potentiometer (as used by elektron) could be axially mounted - then you would monitor two resistances to track both the complete rotations and phase/angle of the arm - then you’re reducing the ‘breakable’ complexity of teh machine down to a simple part (or even a stepped encoder could be used)
you also may want to incorporate a fail safe, so tempo can be faked if your mechanism failed
another ‘food for thought’ notion is whether it could be advantageous/doable to specify MIDI song position pointer data instead of midi clock as this might afford you the ability to radically play with tempo and possible go in reverse (not 100% sure if feasible)
hth - just a few ideas to maybe help you scope your solution or inspire some other approaches
