Linux in musical instruments

[chysn]

The Linux kernel is small and efficient, and it does a lot of things that are just tedious to do from scratch. And it will be significantly more stable and secure than something that a small team of developers makes themselves. It's a really good starting point for an embedded non-trivial OS in just about any domain.

[Gerry Havinga]

It'll run Linux to host JUCE to display what's being shown on the LCD.

Honestly I got somewhat mixed feelings about embedded Linux in a musical instrument. Not because of the features it offers to the instruments developers but simply because of basic computer security concerns.

In a few years time from release the instruments may not have upgraded software and will be a ticking time bombs just waiting to attack other computers in the home or studio without the owner being able to do anything about it.

One certainly develops an appreciation for smaller embedded solutions though these can have similar issues too. But as the OS is smaller and not widely used its less likely to be a target for malware. But of cause nothing is immune to government enforced "features".

Security concerns will always be an issue as soon as some kind of networking and computer to computer interfacing (USB included) is involved. A good hardened and nailed down, compiled for the designated hardware platform, only using those kernel modules and options absolutely needed, modern Linux kernel is practically unbreakable. Don't forget the majority of Internet related servers and appliances do run some version of Linux. There are several big time router and network security appliance manufacturers who have based a complete product line on top of the Linux kernel.

I see the really big advantage of using a Linux kernel, combined with the FOSS (Free and Open Source Software) philosophy, is the emergence of an ecosystem of software and hardware. Cheaply and widely available to all to tinker and experiment with. Within such an ecosystem occasionally amazing "products" will emerge that push sound design, composing, user interfaces and so on into a completely new direction.

Over the last 30 years this has happened to the good old Unix marketplace. Mainframe hardware runs Linux nowadays, and even Microsoft has finally embraced the combined commercial and FOSS philosophy. It is just a matter of time before this will also happen in the electronic music hardware and software world. I am certainly looking forward to it. Currently my home office work area is "littered" with Raspberry Pi's , Arduino's and several synths all connected together one way or the other ;-).

@moderators: Perhaps a nice idea to start a "Linux" / "Development" thread (did I spell that right) here. This forum really would be a nice place to exchange ideas.

[dslsynth]

Very good points, chysn and Gerry Havinga! Of cause there are many many good reasons for using Linux. My only concerns are USB security, long term maintenance of the Linux OS within the product and the ever present nasty topic of zero day vulnerabilities.

Its also important to know that for all practical considerations USB is a network protocol with no firewall so a device could look like one thing and behave like another. Such as an USB flash drive compromising a system even though it just looks like a complete standard portable storage facility.

Computer security is very hard. Wish it wasn't so!

[BobTheDog]

The only secure computer is one that is turned off and unplugged from power.

[dslsynth]

The only secure computer is one that is turned off and unplugged from power.

Spot on! Especially these days given the general cybersecurity situation! . o O ( )

[Gerry Havinga]

The only secure computer is one that is turned off and unplugged from power.

Not entirely true anymore .... some power needs to be provided, but server could be "off": https://www.ssh.com/vulnerability/intel-amt/

[Gerry Havinga]

Thanks Chysn to start this thread.

I have a little hobby project going, developing a hardware MIDI step sequencer using a Teensy and a Raspberry Pi. The Pi obviously runs Linux. As I am not really a hardware, electronics circuit, designer I do get stuck occasionally ... 

At this moment I have a 4 step sequencer working, with 4 rotary encoders which have tri-color LCDs on board. No other feedback yet, just the encoders and the "moving" LEDs. Now I want to scale up to 16 steps and continue developing the software. As each LED inside the rotary encoder needs a wire and ground, I end up with 4 wires for each rotary encoder just to drive the LEDs. But lighting the rotary encoders with different colors depending on what MIDI event is sent is so cool, I don't want to give up on that feature.

Does any of you have any ideas how best to scale up driving those 16*3 LEDs?

Additionally, reading through the threads the last week I saw Paul Dither mention JUCE  which peaked my interest. At the moment the Raspberry Pi code is written in Python, which makes it a bit more tricky to keep time. Perhaps JUCE would be a better alternative...... so many options!

[chysn]

Thanks Chysn to start this thread.

For the record, I did not start it. My post was chosen by a moderator as the departure point for a thread that maybe went too far off-topic.

Your project sounds like fun. I've got a couple Raspberry Pis in the house, but so far I've done my music projects with Arduino. Arduinos are like three bucks each, so it's viable to do one-off projects and superglue them into project cases forever. But I'm sort of interested in looking into the Pi now.

[tumble2k]

Gerry, there are better hardware guys than me on this forum, but IIRC the issue with encoders is that you can't simply scan them like pots or switches. You need to watch for interrupts on the encoder. You can use a port expander (Adafruit has some helpful information here: https://www.adafruit.com/product/732) that allows you to receive interrupts.

Linux has an i2c-dev driver, and you can use i2cset and i2cget at the command line to read and write registers in the port expander. The i2c lines are available on the expansion port.

[BobTheDog]

Thanks Chysn to start this thread.

Does any of you have any ideas how best to scale up driving those 16*3 LEDs?

In what way, to reduce output pin count?

[Gerry Havinga]

Gerry, there are better hardware guys than me on this forum, but IIRC the issue with encoders is that you can't simply scan them like pots or switches. You need to watch for interrupts on the encoder. You can use a port expander (Adafruit has some helpful information here: https://www.adafruit.com/product/732) that allows you to receive interrupts.

Linux has an i2c-dev driver, and you can use i2cset and i2cget at the command line to read and write registers in the port expander. The i2c lines are available on the expansion port.

Thanks tumble2k, I do have a solution for that. The Teensy is doing the hard work of checking the interrupts generated by activity from the rotary encoders (4 at the moment). It is "translating" the pulses into a simple serial USB "command" to the RaspberryPi. It sends an address + direction field to a Python script that is keeping track of which note is being sent over the MIDI bus. At the same time the Teensy is powered by the Pi.

I believe this will scale to 16 encoders, a Teensy has just enough pins available. In worse case I could use a bit-shifter or port expander to expand the ports to connect to the encoders.

The challenge I am facing is that each rotary encoder has 3 LEDs on board.  I want to be able to address each LED independently, for example when it is sending notes they light up blue, when adjusting velocity they light up red and so on. As the RaspberryPi is working out notes / velocity / gate and so on it needs to be able to drive the LEDs.

[Gerry Havinga]

Thanks Chysn to start this thread.

Does any of you have any ideas how best to scale up driving those 16*3 LEDs?

In what way, to reduce output pin count?

Kind of yes. I am looking for a simple way to address each LED (16*3 for the encoders). For example use the i2c bus on the Pi to sent a command / address and the corresponding LED will switch on. Or something similar  . Of course with a port expander the Pi might be able to do all this self. But 16*3 and additional LEDs that need to go on requires a lot of I/O ports..... And it needs to be reasonably fast, to reach 250 BPM (less than 240 milliseconds).

[tumble2k]

Here's a crazy idea. Use a matrix type of configuration. Use 6 pins for the rows and 8 pins for the columns. The row lines are connected to the V+ side of the LEDs, the column lines are connected to the current limiting resistor. To turn an LED on you pull the corresponding row line high and the column line low. You'd need 14 pins to handle 48 LEDs.

[BobTheDog]

Thanks Chysn to start this thread.

Does any of you have any ideas how best to scale up driving those 16*3 LEDs?

In what way, to reduce output pin count?

Kind of yes. I am looking for a simple way to address each LED (16*3 for the encoders). For example use the i2c bus on the Pi to sent a command / address and the corresponding LED will switch on. Or something similar  . Of course with a port expander the Pi might be able to do all this self. But 16*3 and additional LEDs that need to go on requires a lot of I/O ports..... And it needs to be reasonably fast, to reach 250 BPM (less than 240 milliseconds).

There are a selection of i2c and SPI led drivers.

As I guess you want DIP then you could get away with two MAX 6947s and just use 5 pins https://www.maximintegrated.com/en/products/power/display-power-control/MAX6957.html

If you can do SMT soldering then there is a lot more choice.