display simple text from PureData?

thanks for going through the steps and summarising them for others! You may want to do the final stretch and make a pull request on my repository including these changes (for the very first change: add the line commented-out, same as SSD1306_128_32 and SSD1306_96_16 currently are).

yes you'd need to:

• register for a GitHub account
• go the repo URL
• click "fork"
• you now have a "fork" of the repo that you have write permission to
• change the files there (ideally on your computer via a client, but you can also edit directly on github)
• commit the changes (push if you are doing this on your computer and not through GitHub's web interface)
• go to the home page of your repo and you will see a button to click to create a pull request

if that sounds like too much, I can try and apply those changes myself and then you can download the updated repo and test it.

Remork bool setup(BelaContext **context, void *userData)

one * too many. PS: use ``` around your code.

There are two fundamental issues here:

Remork i was hoping bela would know what the context was

There is nothing special about a variable of type BelaContext* named context. It is not defined "somewhere" and you cannot access it globally. You can operate on a it it gets passed to the function you are in. It is passed to setup(), render(), cleanup(). From one of those functions, you can pass it to other functions if needed, but you are not allowed to cache it for longer than the lifetime of the function. In other words, with the exception of setup() and cleanup(), you cannot use the BelaContext outside the audio thread.

Remork digitalWrite(context, 0, gResetPin, 0);
usleep(1000);
digitalWrite(context, 0, gResetPin, 1);

Had you written these lines within the audio thread (e.g.: within render(), or a function called by it(, what you'd have as a result is probably:
- a mode switch (usleep() is not a Xenomai-safe function)
- several dropped blocks (you are telling your thread to do nothing for 1ms, which is 44 samples, but it will actually sleep for a bit longer)
- the first digitalWrite() line would have no effect

The last statement may be the confusing one. Unlike other physical computing platforms (e.g.: Arduino), on Bela a call to digitalWrite() (or any of the other read/write functions, for what matters), does not actually go and write the value. Rather, it sets its value in memory, so that after the execution of render() is completed, the value you set for each specific frame is written to the digital output. Your first call sets the memory buffer to 0 for all frames (for a block size of 16, that'd be frames 0 to 15). Your second call sets the memory buffer to 1 for all frames, effectively overwriting all the others. The value for that channel in the buffer at the end of the render() function would therefore be 1 and that's the value that will be written to the output.

In order to obtain a delay of 1 ms between writing a 0 and writing a 1 to a Bela digital channel from within the audio thread, you should "count samples", i.e.: write a 0 to each frame for 44 samples (997us) (possibly across multiple calls to render()), then write a 1. This example and this video should help clarify the issue.

HOWEVER

IIUC, you are doing this as a modification to OSC2OLED4Bela. As you will have noticed, that one is not a "Bela program" as such (i.e.: it contains a main() function, which doesn't call the Bela API, so it doesn't have setup(), render() and cleanup(). This is in fact just a program that uses some of the Bela libraries, but does not actually run a Bela audio thread, but is conveniently built and run through the Bela IDE. The fact that it doesn't call the Bela API and doesn't run a Bela audio thread is actually a requirement for it to be able to run at the same time. All of this means that you should not actually call any of the digitalWrite() or pinMode() functions, because those operate on Bela's digital channels and can only work as part of the Bela audio thread. What you need to do instead is to pick a digital pin not used by Bela (or by anything else) and use the Gpio class (#include <Gpio.h>) . See this page (https://learn.bela.io/using-bela/technical-explainers/other-uses-of-gpio-pins/) for more information.

Remork i'm thinking i can use a digital pin to toggle the reset before (or at the beginning of) display_Init_seq(); , or even before connecting the I2C. and i could use a digital pin to control the 12v line with a mosfet or something.

this should work, with the above adjustments.

Remork and there was me thinking this would be relatively straightforward 0_0

it's not too hard, really ... this should be all you need

#include <Gpio.h>

// globals
int gResetPin = ...; // TODO: find a free pin
Gpio gResetGpio;

...

// inside some init function:
gResetGpio.open(gResetPin, Gpio::OUTPUT);

// when needed:
gResetGpio.write(false);
usleep(1000);
gResetGpio.write(true);

Remork giuliomoro it's not too hard, really

didn't want that to sound bad ... I just wanted to follow up from the previous post, which was pointing to a lengthy explanation and an API documentation, with a barebones practical example

Remork phfew. that is beautiful.

indeed!

Remork in terms of timing - does this sort of 'background' thread start up first, compared to Audio/Pd?

probably a bit later. I'd recommend that you don't rely on any particular startup order. Just have one ping the other until the other responds, then you'll know they are both alive.

Remork spread some of the heavier lifting needed at startup

For most application, "startup" heavy lifting is "free": you'll get mode switches, dropouts, whatever, doesn't matter: you haven't started yet! If anything, it's better to avoid spreading it out so that it completes as fast as possible ... if - on the other hand - you are trying to do the "startup heavy lifting" while at the same time playing some audio (e.g.: a power on tone), then the "spreading" can definitely help!

this is clearly over-engineering, but you could have a Bela digital in connected to the pin you are toggling from OSC2OLED4Bela and monitor that pin from within the Pd patch

giuliomoro This is actually easier said than done, as I see now that there are no OSC-sending capabilities in there at the moment, so you'd need to add a OscSender object and also UdpServer should be modified to use recvfrom() in order to be able to retrieve the address from which a message was received and use that for a response.

Actually, without any changes to the libraries, you could just hardcode a port number to send messages to in OSC2OLED4Bela and have a OscSender object send to it in response to a /ping or something like that ...