Trill Square and OLED

This site is best viewed in a modern browser with JavaScript enabled.

Trill Square and OLED

dipaloka

I've never used c++ before so I expect there's probably a much cleaner version of this implementation, but I managed to use chat-gpt to generate the necessary code so that an OLED display would visualise an octophonic speaker layout, with a circle (representing a sound source) that moves via an Hslider and Vslider in Pd (sent over OSC)

I amended the .cpp with the following:

function to draw speakers on an imaginary circle inside the square frame:

void drawSpeakerNumbers(U8G2 &u8g2, int squareSize, int xOffset) {
    // Speaker positions in degrees
    int speakerAngles[] = {245, 295, 335, 25, 65, 115, 155, 205};

    // Circle and speaker number properties
    int circleCenterX = (xOffset + squareSize / 2) + 2; // Nudge the X position 
    int circleCenterY = ((64 - squareSize) / 2 + squareSize / 2) - 8; // Nudge the Y position
    int speakerRadius = static_cast<int>(squareSize * 0.45); // Reduce the radius slightly

    // Draw speaker numbers on the circumference
    u8g2.setFont(u8g2_font_ncenB08_tr); // Choose a suitable font
    for (int i = 0; i < 8; i++) {
        float angleRad = speakerAngles[i] * (M_PI / 180.0);
        int numberX = circleCenterX + speakerRadius * cos(angleRad) - 4;
        int numberY = circleCenterY + speakerRadius * sin(angleRad) + 4;
        u8g2.drawStr(numberX, numberY, std::to_string(i + 1).c_str());
    }
}

addition to the parsemessage section:

} else if (msg.match("/drawXY")) {
    float xValue, yValue;
    if(args.popFloat(xValue).popFloat(yValue).popFloat(largeNumber).isOkNoMoreArgs()) {
        printf("received /drawXY float %f float %f float %f\n", xValue, yValue, largeNumber);

        // Normalize the X and Y values to fit within the square dimensions
        int squareSize = displayHeight;
        int xPos = static_cast<int>(xValue * (squareSize - 1)) + (displayWidth - squareSize);
        int yPos = static_cast<int>(yValue * (squareSize - 1));

        u8g2.clearBuffer(); // Clear the display buffer
		
		// Draw the large number on the left side of the screen
        u8g2.setFont(u8g2_font_inb24_mf); // Change to a larger font
        int numberWidth = u8g2.getStrWidth(std::to_string(static_cast<int>(largeNumber)).c_str());
        int squareX = displayWidth - squareSize;
        int numberX = (squareX - numberWidth) / 2;
        int numberY = displayHeight / 2 - 10;
        u8g2.drawStr(numberX, numberY, std::to_string(static_cast<int>(largeNumber)).c_str());

		
        // Draw a square frame on the display, aligned to the right
        u8g2.drawFrame(displayWidth - squareSize, 0, squareSize, squareSize);

        // Draw the speaker numbers
        drawSpeakerNumbers(u8g2, squareSize, displayWidth - squareSize);

        // Draw a small circle at the specified X and Y values
        int circleRadius = 2; // Adjust the circle radius as desired
        u8g2.drawCircle(xPos, yPos, circleRadius, U8G2_DRAW_ALL);

        u8g2.sendBuffer(); // Update the display with the new buffer contents
    } else {
        error = kWrongArguments;
    }

This worked surprisingly well, albeit the screen doesn't update as instantaneously as I expected, but it's good enough

Next I wanted to use a trill square for XY input instead of using the Pd sliders. I used this - https://learn.bela.io/using-bela/bela-techniques/running-a-program-as-a-service/ - to run the OLED cpp script in the bg and amended the Pd patch to unpack the XY floats into the OSC message.

It does work but theres between 2-3 second lag time from when I touch the XY pad to the OLED being updated, and it's very jumpy.

I was wondering if there's anything I can try to attempt to
a) make the display update in something closer to real-time
b) improve any of the chat-gpt generated code

giuliomoro

dipaloka It does work but theres between 2-3 second lag time from when I touch the XY pad to the OLED being updated, and it's very jumpy.

I think you are sending data from Pd much faster than the refresh rate of the display. As a consequence of that, a queue of frames to draw starts building up which causes the delay you are witnessing. You should throttle the data going out of your Pd patch so that they go out slightly slower than the refresh rate of the screen. The refresh rate of the screen is not predetermined but it will depend on the CPU usage. I expect it to be always slower than 20Hz. I'd try starting sending one message every 100ms and if that is smooth enough, then increase that a bit.

In addition to this you can also try using the only-latest branch of O2O which tries to work around this by discarding older values and avoid the build up of a queue. See https://forum.bela.io/d/314-is-anyone-successfully-using-i2c-oled-lcd/139 for more details.

dipaloka

alt text

dipaloka

Pd patch:
alt text

dipaloka

works like a charm! thank you giulio

video here incase anybody would like to see: imgur.com/a/cNWD09L

giuliomoro

Nice. What prompt did you use to generate that code? Did you have to provide context?

dipaloka

yes, it was a process, many many prompts. took about an hour and a half altogether.

i started by pasting in the original .cpp file and asked it to analyse and provide a summary.

it came back with:

This C++ code is an implementation of an OSC (Open Sound Control) message receiver that controls multiple I2C OLED displays using the U8g2 library. The code supports optional I2C multiplexing, allowing multiple displays to be controlled through a single I2C bus by using a TCA9548A I2C multiplexer.

Here's a summary of the key features:

Includes necessary libraries, such as signal.h, OscReceiver.h, U8g2LinuxI2C.h, vector, and algorithm.

A global vector, gDisplays, stores display configurations, including the U8G2 object and an optional I2C multiplexer channel number.

A global variable, gActiveTarget, is used to store the currently active display.

If I2C multiplexing is enabled, the code includes the TCA9548A.h library and initializes a TCA9548A object, gTca.

TargetMode enumeration is used to define different targeting modes for the OSC messages.

interrupt_handler function is used to handle the termination of the program when a SIGINT or SIGTERM signal is received (e.g., Ctrl-C).

switchTarget function is used to switch the active display target, handling the I2C multiplexer channel selection if required.

parseMessage function is the core function for processing received OSC messages, updating the display content based on the message received.

main function initializes the I2C multiplexer (if enabled), initializes the displays, sets up the interrupt handlers, and starts the OSC receiver. The program continues to run until a termination signal is received.

The code listens for specific OSC messages, and based on the messages received, it updates the content on the active display. The supported OSC messages are:

/target - Select the active display (only valid in stateful target mode).
/targetMode - Change the target mode (single, each, or stateful).
/osc-test - Display "OSC TEST SUCCESS!" on the active display.
/number - Display a large number on the active display.
/display-text - Display up to three lines of text on the active display.
/parameters - Display three horizontal bars, each representing a float parameter value.
/lfos - Display three ellipses, each representing a float parameter value.
/waveform - Display a waveform based on a series of float values.

Next prompt: Please can you use the above code as a guideline to create new display functionality that listens for the OSC message '/drawXY'

Please write the code that will be added to the 'parseMessage' function for processing received OSC messages.

The OSC message will be two numbers representing X and Y values. These X and Y values should be able to update the OLED display in real-time, based on the data being sent via OSC.

Please represent the X and Y values inside of a square frame.

Response:

To add the new display functionality for the OSC message '/drawXY', you can add a new case inside the parseMessage function to handle this specific message pattern. Here is the code to process the '/drawXY' OSC message:

cpp
Copy code
// ...
} else if (msg.match("/drawXY")) {
    float xValue, yValue;
    if(args.popFloat(xValue).popFloat(yValue).isOkNoMoreArgs()) {
        printf("received /drawXY float %f float %f\n", xValue, yValue);

        // Normalize the X and Y values to fit within the display dimensions
        int xPos = static_cast<int>(xValue * (displayWidth - 1));
        int yPos = static_cast<int>(yValue * (displayHeight - 1));

        // Draw a square frame on the display
        u8g2.drawFrame(0, 0, displayWidth, displayHeight);

        // Draw a point at the specified X and Y values
        u8g2.drawPixel(xPos, yPos);
    } else {
        error = kWrongArguments;
    }
// ...
This code snippet first checks if the message matches the '/drawXY' pattern. It then tries to pop two float values from the message as the X and Y values. If successful, the X and Y values are normalized to fit within the display dimensions. A square frame is drawn around the entire display, and a point is drawn at the specified X and Y values. If the arguments are not as expected, an error is set.

Make sure to add this case within the parseMessage function, in the section where you check for other message patterns using msg.match().

This generated a rectangle frame, but it worked!

Then there was a lot of back and forth to get it to correctly produce a square and align it to the right hand side.

alt text

dipaloka

There were at least another 30 or so prompts after that to get the speaker layout correctly aligned, numbers in the correct order etc, but it did get there in the end.

Maybe if someone with more knowledge of cpp was interacting with it they could do a very specific prompt and get the end result much quicker, but i was very much fumbling in the dark!

The net thing I'd like to do is have the circle get larger/smaller by reading the 'size' float.

Will share an update when its ready