Hypersphere slow motion explanation
#silent #digital #animation of a #hypersphere. 2.5-min.

❛❛ In #math, a hypersphere or 3-sphere is a 4-dimensional #analogue of a #sphere, and is the 3-dimensional n-sphere. In 4-dimensional #Euclidean #space, it is the set of #points equidistant from a fixed central #point. ❜❜

🔗 https://www.youtube.com/watch?v=XFW769hqa1U 2012 Jul 04
🔗 https://Wikipedia.org/wiki/N-sphere … #nSphere
🔗 https://Wikipedia.org/wiki/3-sphere … #3Sphere

#Community #TimeTravel #Research #Topology #Geometry #Kronodon

In this posts I describe a version of the Arduino Euclidean Gate Sequencer that implements the same user interface and most of the features of HAGIWO’s brilliant build.

• Part 1 covered all the theory and main functions of the code.
• Part 2 included some hardware suggestions for connecting it to other devices.
• Part 3 added a rotary encoder and I2C display and demonstrated by Arduino Clock Generator Shield PCB.
• Part 4 reimplements HAGIWO’s original with a few tweaks and updates.

Also see the Arduino Clock Generator Shield PCB design.

https://makertube.net/w/vPXHnd69UifLhHyQangUr4

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Arduino, see the Getting Started pages.

Parts List

• Arduino Uno.
• Arduino Clock Generator Shield PCB.
• Drum trigger hardware.

In principle this could use the same hardware as described in Part 3 but I’m using my PCB as it makes everything a lot easier to test and use.

Introduction and Core Functionality

There is a really good demonstration of HAGIWO’s build in this video: https://www.youtube.com/watch?v=lkoBfiq6KPY

HAGIWO’s screen is shown above and has the following features:

• 6 channel outputs each with 16 steps.
• 16 different Euclidean patterns, represented by polygons on the display.
• Patterns can be offset by up to 16 steps.
• Patterns can have the number of steps reduced or limited down to a single step.
• Channels can be muted.
• There is a random mode that sets all parameters in a random, but still musically useful, way.

The menus are navigated by means of a rotary encoder and switch and it expects an external clock signal, as it is designed for use in a Eurorack setup.

I’m not bothered about the random mode, but I want to implement a built-in clock source with its own tempo control, similar to that shown in Part 3.

The Code

HAGIWO’s code is implemented in a single loop function, using IO interrupts with the Enc rotary encoder library, which means the encoder has to be on pins 2 and 3 on an Uno.

I want to keep my timer-driven GATE outputs and will be polling the encoder using the library from Matthias Hertel (https://github.com/mathertel/RotaryEncoder) which means essentially I’m going to be doing a re-implementation rather than a port of HAGIWO’s code to my hardware.

I’ve reused all the user interface design elements though (apart from the random mode) even though the implementation has been tweaked slightly.

Once again I have two main threads of code:

• A 10mS tick that handles the GATE outputs and timings subject to the current selected tempo. I will also be using this to poll the rotary encoder too.
• The main Arduino Loop() function which will manage the user interface, update the display and adjust the sequencer parameters as required.

By keeping the GATE handling in an interrupt routine it will not be affected by the slower I2C updates of the display.

I did wonder about a third level – perhaps a multiple of the main tick, to give me a thread for the encoder and one for the GATES, but it seems to work fine using the same 10mS tick for both.

The core sequencer parameters are:

• seqTempo – tempo in beats per minute.
• seqPatterns[] – pattern number for each channel (gate).
• seqOffsets[] – start offset for each channel.
• seqMute[] – if TRUE then channel is muted.
• seqLimits[] – end step for each channel.
• seqCounter[] – current playing step for each channel.

Timer Functions:

• timerSetup() – initialise the TimerOne library with a 10mS tick to call timerLoop().
• timerLoop() – calls the sequencerLoop() and uiScan() each tick.

Sequencer Functions:

• sequencerSetup() – sets up the first patterns, tempo and any sequencer parameters that aren’t pre-initialised in code.
• sequencerLoop() – uses tempoTickCnt to decide if a sequencer step is to be enacted or not and output the GATEs as required. Called from the timerLoop().

Gate Functions (all called from the sequencerLoop()):

• gateSetup() – initialses the IO for GATE outputs.
• gateClear() – turns off all GATEs.
• gateOutput() – turns on all active GATEs.
• gateUpdate() – works out which GATEs should be on for a particular step in a pattern using patternStepOn().

Pattern Functions:

• patternStepOn() – returns TRUE if the indicated step of the current active pattern shows a GATE should be on for this channel.
• patternRefresh() – caches the current active patterns for each channel, taking into account any seqOffset[] setting.

User Interface and Menu Functions:

• uiSetup() – initialise the OLED display and encoder.
• uiScan() – high speed elements of the interface, called from the timer interrupt and used to scan the encoder.
• uiLoop() – lower speed elements of the interface, called from the Arduino’s main loop and handles the updates to the sequencer parameters from the encoder by calling updateMenu().
• uiRequest() – used to signal a display refresh is required. Used when something changes due to the encoder or the playing step display needs updating.
• uiUpdate() – redraws the screen to represent the current state of the interface and sequencer parameters.
• updateMenu() – handles the main menu logic using the encoder increment/decrement and switch functions.

The main menu logic from the updateMenu() function has to manage 7 selection states as follows:

• State 0: channel update
• State 1: pattern update
• State 2: offset update
• State 3: limit update
• State 4: mute on/off
• State 5: reset sequence back to starting step
• State 6: tempo update

Most of the states will add the (positive or negative) increment to the appropriate sequencer parameter and bounds check the result.

The exceptions are mute and reset which act immediately – mute being a toggle, and reset simply setting all seqCounters[] back to 0.

uiLoop() will act on the encoder switch using it to choose between moving between menus and selecting the functionality of one of the menu items.

uiUpdate() is the function that closely mirrors HAGIWO’s original as it has to reproduce the interface on the display. As already mentioned, I’ve not implemented a random mode, but I have added a tempo indication which I show by adding a blocked-out rectangle across the centre of the display with the current bpm tempo value shown.

I’ve also added code so that the currently selected menu item has a solid triangle when in parameter changing mode. This is mostly as HAGIWO’s original used an independent switch, so the sub-menu mode was active as long as the switch was pressed. As I’m using a switched encoder, I want the switch to be a latched toggle between modes rather than only active when pressed.

There is one bug that I can’t quite see why it happens. When showing the tempo there is a block of interference on the bottom right-hand corner. I’m using display.print() at the coordinate point indicated for the tempo text, so I’m not sure what is causing that. Once the tempo display disappears as the menu selection moves on, it goes away…

This seems to be a result of setTextSize(2) and using print(). I’ve no idea why, but switching over to using drawChar() directly for the three digits seems to solve the issue! Still no real idea why to be honest but must be some weird buffer bug in the libraries somewhere I guess.

Update – Nov 2024

I realised what the issue is likely to be. The SSD1306 library has to allocate a chunk of memory on startup, as part of the display.begin() call and if that fails, but the code continues on anyway, then its behaviour will be quite unpredictable.

It requires the following amount of memory to run (from Adafruit_SSD1306.cpp):

So for 128×64 that is 1136 bytes of memory. I would imagine there is some kind of overrun going on – if not then it is probably something related to that.

Either way, I’ve added a test on startup to ensure that the display.begin() calls succeeds before proceeding just in case – something I should have been doing anyway.

Apart from these changes, I believe the interface is working as to HAGIWO’s original.

Find it on GitHub here.

Closing Thoughts

Once again the video shows my Arduino Clock Generator Shield PCB running the above code, driving my Arduino Drum Trigger to MIDI Shield PCB which is hooked up to a Roland TR-505.

When I first started messing around with Euclidean rhythms and thinking about an encoder and screen-based interface, I did think I’d just pick up and use the code from HAGIWO’s project pretty much “as is”. But in the end it was just the interface design I reused and reimplemented everything else myself so I could tweak and adjust things in the way I wanted.

So I consider this is another wheel dutifully reinvented here.

As always though, major thanks to HAGIWO for the project that inspired this one and for publishing the designs and code online for others to learn from.

Kevin

https://diyelectromusic.com/2024/10/28/arduino-euclidean-gate-sequencer-part-4/

#arduinoUno #euclidean #gate #midi #oledDisplay #rotaryEncoder #ssd1306 #stepSequence

Arduino Euclidean Sequencer with OLED display

https://makertube.net/w/vPXHnd69UifLhHyQangUr4

This is another variant of my Arduino Euclidean Gate Sequencer this time using a rotary encoder and I2C display rather than a potentiometer for control.

• Part 1 covered all the theory and main functions of the code.
• Part 2 included some hardware suggestions for connecting it to other devices.
• Part 3 added a rotary encoder and I2C display and demonstrated by Arduino Clock Generator Shield PCB.
• Part 4 reimplements HAGIWO’s original with a few tweaks and updates.

https://makertube.net/w/s1cMmrCzW7tGm16NQQKH9w

Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

If you are new to Arduino, see the Getting Started pages.

Parts List

• Arduino Uno.
• Switched Rotary Encoder – either a KY-040 module or an unmounted encoder.
• 128×64 OLED I2C SSD1306 display.
• Optional: LEDs and associated (e.g. 220Ω or 1K) resistors.
• Breadboard and jumper wires.

The Circuit

The above diagram shows how to connect two variants of rotary encoder. On the left is a common KY-040 switched encoder module. On the right is a common switched encoder directly connected to solderless breadboard. Only one encoder should be connected to D4, D5 with the switch on D6.

Note if it turns out the encoder is incrementing/decrementing values in the opposite way to what is expected, then usually the simplest thing to do is swap the IO pin assignments for the A and B connections in the code.

The diagram also shows how to connect a 128×64 I2C OLED display. These are the very common SSD1306 based displays. Note that the pinouts on these can vary with GND/VCC swapped or SCL/SDA swapped, but they must be connected to 5V, GND and A4 (SDA) and A5 (SCL).

The clock generator outputs are on D8-D13. I’ve not added an LED to D13 as it is wired to the internal LED, but that can be added too if required.

I’ve put together an Arduino Clock Generator Shield PCB which includes buffered outputs, a rotary encoder and I2C display connections.

The Code

This expands on the original code that is fully described in part 1 here.

There are two main threads of code as follows:

• 10mS “tick” interrupt routine to ensure accurate GATE timings.
• Back “loop” handling the encoder and display.

In order to ensure a responsive encoder the display is only updated when something actually needs to change.

Once again I’ve opted for Matthias Hertel’s simple RotaryEncoder library which can be found here: https://github.com/mathertel/RotaryEncoder. A detailed explanation of how it works can be found here. I’ve found this seems to work best for me for the cheap encoders I tend to buy. One the correct encoder type has been found I’ve found this to be very reliable, especially when simply polling IO pins for an encoder. There is a little more on the rationale for choosing this library in a previous project here: Arduino MIDI Rotary Encoder Controller.

For the I2C display, I’m using the SSD1306 implementation of the Adafruit GFX library which can be found here:

• https://github.com/adafruit/Adafruit_SSD1306
• https://github.com/adafruit/Adafruit-GFX-Library

All of these should be installable from the Arduino Library Manager.

The core principles of operation are as follows:

• The display will show the tempo in beats per minute and which pattern is used for each of the 6 GATE outputs.
• Clicking the encoder will change the focus between tempo and any of the six GATEs allowing them to be changed.
• Note: although the tempo is in bpm the number of GATE pulses is actually running at 4 pulses per beat. This means that every 16-pulse sequence, regardless of pattern, will take 4 beats in time to run through.

This is the display I have. I’ve used a larger font for the tempo and underlining to show the active focus of the interface.

The display is managed by having lists of the coordinate points for “cursor” which map what I’ve used for positioning the text.

Then when the encoder triggers a change, the main interface code essentially runs the following algorithm:

I did wonder if the encoder should be polled in its own timer-driver routine. For performance, many people might enable hardware pin interrupts, but these are only available on pins 2 and 3 on an ATMega328. But as the interface loop is essentially not doing much else, it will poll the encoder pretty quickly (at least compared to the speed a person can turn it) and performance is further enhanced by only writing out to the display if something has actually changed.

There are three #defines for the encoder IO pins. If the encoder seems to be doing the opposite to what is expected, just swap over the pins for ENC_A and ENC_B.

The display is assumed to have an I2C address of 0x3C but that can be changed. It is also built for a 128×64 display but a 128×32 display could also be used if the coordinates for the text and cursors mentioned previously are changed accordingly.

There are two sets of IO pin definitions in the code. One provides a consecutive set of GATES on D8-D13 and one uses D2,D3,D10-D13 to match the requirements of my Arduino Clock Generator Shield PCB.

Find it on GitHub here.

Closing Thoughts

The video shows my Arduino Clock Generator Shield PCB running the above code, driving my Arduino Drum Trigger to MIDI Shield PCB which is hooked up to a Roland TR-505.

The only change required is for the GATE pins, which are slightly different for the PCB.

Kevin

https://diyelectromusic.com/2024/10/27/arduino-euclidean-gate-sequencer-part-3/

#arduinoUno #define #defines #euclidean #gate #midi #oledDisplay #rotaryEncoder #ssd1306 #stepSequence