Difference between revisions of "Adding Encoders"
| Line 7: | Line 7: | ||
==Encoders directly connected to GPIO Pins== | ==Encoders directly connected to GPIO Pins== | ||
| − | This is the original approach used from the start the Encoder were connected directly to GPIO pins on the Raspberry Pi. | + | This is the original approach used from the start the Encoder were connected directly to GPIO pins on the Raspberry Pi. |
| + | |||
| + | === Connecting via the GPIO Pins. === | ||
| + | |||
| + | The raspberry Pi has a 40 pin connector that provides access to a level of connection not generally available to the PC world. This allows Digital devices to be connected to a Raspberry Pi and the Pi can both receive and transmit information to these devices as digital Data. +3.3V or 0v in electrical terms. | ||
| + | |||
| + | This connector will probably exist as a standard for a considerable length of time, such is the electronic infrastructure that has grown around it. Indeed competitor boards, would dare use anything else so it's become ubiquitous, in a similar fashion to the IBM edge connectors carried on long after the company had stopped making PC's themselves. | ||
| + | |||
| + | [https://pinout.xyz/ Here's a site devoted to it.] | ||
| + | |||
| + | [[File:20250216 15h10m42s grim.png|thumb|Pi GPIO]] | ||
==Encoders connected using a MCP23017 chip== | ==Encoders connected using a MCP23017 chip== | ||
Revision as of 15:13, 16 February 2025
Encoders can be added to the Raspberry Pi to provide zynthian with an interface designed to drive the Graphical User Interface, and act as parameter controllers for any device managed by the zynthian. This is one of the zynthians key features and allows control of almost any parameter of the Audio engines that it manages.
There are a number of ways of implementing the basic zynthian encoder interface, and these have developed alongside the project. The techniques used in the early Version One days have been supplanted by more recent design and a software environment has been constructed that allows these differing approaches to be integrated with no difference between the implementations.
1 Encoders directly connected to GPIO Pins
This is the original approach used from the start the Encoder were connected directly to GPIO pins on the Raspberry Pi.
1.1 Connecting via the GPIO Pins.
The raspberry Pi has a 40 pin connector that provides access to a level of connection not generally available to the PC world. This allows Digital devices to be connected to a Raspberry Pi and the Pi can both receive and transmit information to these devices as digital Data. +3.3V or 0v in electrical terms.
This connector will probably exist as a standard for a considerable length of time, such is the electronic infrastructure that has grown around it. Indeed competitor boards, would dare use anything else so it's become ubiquitous, in a similar fashion to the IBM edge connectors carried on long after the company had stopped making PC's themselves.
2 Encoders connected using a MCP23017 chip
As an interface grows ( when 4 user definable switches were added to V3 (?) we had already moved away from the direct encoder route in favour of a much more efficient way of reading encoders and switches, which passed off some of the effort to another piece of silicon. The MCP23017 16 port I2C multiplexer. This board meant the communication between the Raspberry Pi and this 20 pinned chip could be handled by only a few wires at the Pi end, and a standard form of communication called I2C.
The zynaptik-3 board from zynthian provides all the interfaces for encoders and the extra switches introduced, along with MIDI interfaces and Control voltage and digital ins and outs which represents the official implementation of this sort of approach.
3 Other nefarious methods
Other methods can be accomodated using the zynthian's inbuilt Control Device interface.
4 But what is an encoder?
It's a rotating control designed to provide similar functionality to a control known as a potentiometer which most people meet as a volume control. A way of easily controlling some parameter within an electronic device.Which is why the zynthian likes them so much.
The zynthian simply controls the Linux audio subsystem, (Jack) and it then uses the MIDI standard provided by almost all Linux audio devices to control those engines. This is very helpful because a cleverly defined GUI (and it is one) can by easy selection of different pages present virtually any audio control in the same manner. The four Encoders provide 4 parameters per page, all of which respond. This is exactly what a performing interface requires. It provides as much control as 4 encoders can when behaving like 4 volume controls. It is highly responsive. Allowing for subtle and careful parameter control. Bending a synth filter for example. But it is important to recognize that the audio Engine involved may not be prepared for such fast change. Altering a time constant in a looper over a wide range will probably have irritating sonic sound effects, as such things occur and the Engine simply can't keep up.. That's down to the Engine. zynth just delivers the information you tell it to the parameter it has selected in the GUI.
But You might well want more than 4 parameters and some of the engines provide an incredible number. Well this is where the other element of the humble Encode comes into play. The press switch component.
By pressing down on the top of an encoder a completely separate switch can be operated without any alteration of the rotating component (hopefully). This used to select the page of parameter you are to use, which is demonstrated by a grey screen activated by a short push of the encoder. This is a basic Zynthian function and it is used to indicate selection in the zynthian world.