[sdiy] DOTCOM Analog Sequencer.. Final choice..

[Jean-Pierre Desrochers]

After all the nice posts and replies I just received
from you all I thought about a final choice: pots or encoders possibility..
I also checked many videos and C source codes on how to manage rotary encoders
with a microchip PIC. The first thing that came out after a while was
'At first I wanted to make it.. simple'.
Because of all the involved multiplexing hardware on the encoder's
data pins (yes I'd prefer many encoders over many switches)
and the hard work of managing the debouncing of the encoder's contacts
(capacitors or software) I went back to the idea of using pots BUT in the following way:
By reading the cursors values (0-1023 A/D 10 bits) and rescaling
to 96 steps (semitones). 64 notes is a too small span while 128 is too much.
For my needs 96 would be an adequate span choice.
Rescaling not by shifting the bits but using the schmith trigger filtering approach.
'Dead zones' like audiobanshee liked to call them (see below) would be applied
and each of the pot steps would have its next accepted change value
moving according to the cursors movement position. 
Doing so all the pots reading are passed through a filtering function
that removes any bouncing and scale the final value to 0-95.

And about displaying the note values:
What is the benefit of displaying an 'adjusted' value of let'S say 43
to a note like C or D# if this value could be shifted
by a master 'tuning' pot or encoder anyway ?
Displayed notes would need to be 'non shiftable' static ones ?

*******************************
-----Message d'origine-----
De : rsdio at audiobanshee.com [mailto:rsdio at audiobanshee.com] 
Envoyé : 25 juillet 2020 03:14
À : Jean-Pierre Desrochers
Cc : synth-diy at synth-diy.org
Objet : Re: [sdiy] DOTCOM Analog Sequencer.. next project startup..


On Jul 24, 2020, at 6:52 AM, Jean-Pierre Desrochers <jpdesroc at oricom.ca> wrote:
> The need to be able to change any CV 'on the fly' when playing a 
> sequence is paramount.
> What I forgot to say is whether pots or encoders are used I need to be 
> able to change each step durations on each columns.

You could have a button for each step, and if a button is held for more than one second then that step becomes the last.

> The possible sequences would be:
> 32/1    (32 monophonic notes on one row, fixed step duration)
> 16/2    (16 monophonic notes on one row, adjustable step duration for each
> note)
> 8/3      (8 trio of notes on 3 rows, adjustable step duration for each note
> trio)
> 
> And also play forward/backward or even randomly the sequence.

You'll probably want some dedicated transport buttons for Play, Reverse, and Random.

> Since rotary encoders have 3 to 4 data wires each the multiplexing of 
> each one after the other will be a challenge compared to standard pots

It's actually easier because the two types are quite different.

Standard pots are analog, requiring an analog multiplexer and an A/D. You have to worry about noise, and therefore you have to leave a dead zone between each note so that the noise doesn't cause the note value to constantly change. This is possible, but it takes a lot of tweaking. Without a display, you still won't be able to look at the indicator on the knob and tell *exactly* which note is selected.

Rotary encoders using binary signaling, so noise is practically not an issue at all. Instead of an analog multiplexer, you use a diode matrix to scan the wires. I recommend keeping the quadrature pairs on the same column, so you can read both at the same time. The 3rd wire is usually the button press for the encoder, and those can be read separately. You should design for an RC filter on the quadrature wires, even if you end up with 0 Ω and no cap. I find that a little filtering helps stop bounce on the cheaper encoders, but your scan rate has to account for the filtering, and cheap encoders can't be rotated very quickly because the bounce for longer than each step lasts. You don't need the same dead zones as an analog pot, because encoders transition through 4 states for each step, and that allows jitter between micro states without changing the final value. Some encoders have 2 states per step, some have 4 states per step. If the encoder has no detents, then that count doesn't really matter. Some brands of encoders even allow a choice of the number of detents for a full turn. I've used up to 8x8 diode matrices, but you probably don't need 64 wires (although that would allow 21 encoders with buttons). Keep in mind that the matrix doesn't need to use 8-bit rows. If you need fewer that 64 wires then cut down on the GPIO pins needed. Also, since only one column is active at a time, you can use something like a 3-to-8 or 2-to-4 decoder to reduce the number of GPIO pins needed. Don't skimp on the diodes, though. I designed one product capable of scanning 1024 switch wires for a client, but I don't know what the largest controller was to actually take advantage of that much range.

I should probably point out that I always use microprocessors with plenty of GPIO, so I don't need to deal with serial I/O expanders. In other words, I've never touched an Arduino.

I don't know about encoders with 4 data wires, other than the 4-bit encoders which are absolute position rather than relative position, and also very expensive. I'm sure you'll have a data sheet for whatever encoder you choose.

> but would
> give the ability to achieve large CV span.
> 96 notes span would be nice on each CV controllers !

Yes! 128 notes would probably be overkill, but 96 would be excellent. As someone suggested, you could have coarse and fine, such as jumping by octaves in one mode, or half steps in another.

96 notes on an analog pot would require 95 dead zones, and quiet enough noise specs to get 191 unique codes out of the full range. That's more than the 128 that many products attempt.

> I'm hesitating to use a row of switches with only one encoder Instead 
> of multiple encoders…

You can always have two or three encoders, but still have 32 steps. That's better than just one encoder, but a lot easier to fit on a panel and in a budget than 32 encoders.

> Hmmm..

I like the idea of a display for every note value. I'd even want that if there were analog pots instead of (an) encoder(s).

There are Noritake fluorescent displays that are 1 to 4 characters tall, and 40 or 80 characters wide. Depending upon how you arrange the controls, you could fit a lot of note values on one display, and just line up the buttons (and knobs) with the display characters. That would be a bit easier that wiring 32 individual note displays. If one display can't handle all the notes, then two or three might, or you could use a 4-line-tall display and stack characters.

> ************************************
> 
> I'm starting to think about my next DOTCOM analog module:
> a 16 steps sequencer (maybe 32 steps).
> So far I'd have 2 choices for the final number of steps CV adjustments.
> 
> - Standard CV pots sequenced with gates
>  pros: cost is cheap, the note value is physicaly kept by each pots
>  cons: bad note precision on large span (I'd like a 61 notes span on 
> each CV adj),
>              span must be kept not too large..
> 
> - Rotary encoders
>  pros: Very large CV span can be achieved on each steps (beyond 61 notes), 
>             quantization easy to be achieved on each steps adjustments. 
>  cons: expensive (are they all ?), need for data memory to keep every 
> note values (micro-processor needed)

I don't think they're all expensive. I use some Bourns encoders that are $0.845 each in your quantity. You could read all of those with 15 GPIO pins. Make it 16 GPIO pins and your button matrix could include 8 non-encoder buttons for the transport and other tasks.

> All the gates could be generated by the same micro or from a precise 
> adjustable master clock
> 
> What do you think from your past experiences ?

I would totally use a microprocessor with a UART so that MIDI could be an easy option. Sure, the point is analog CV, but why not allow preset selection and remote saving or loading of sequences?

> Jean-Pierre

Sounds like a fun project! I'm hooked on ARM now, particularly the Texas Instruments TM4C129x Family (32-bit), but that's probably too expensive. I still use the Microchip PIC18F (8-bit) when I need the cheapest option. I've also had good luck with the MSP430 (16-bit).

Brian Willoughby