display simple text from PureData?

giuliomoro

IKR. It all started because @bela_robert ordered an SSD1306 to make a tutorial from my post in the other thread as you requested, then he received an SH1106, so we took the opportunity to jump to something that actually worked.

Remork

cool. look forward to that!
meanwhile, anybody have any idea how to correctly display characters like é, ü, ö and the like?
right now those create gibberish on screen.

Remork

hmm. ok, i just found out that for the character "é", for example, pd's [list fromsymbol] (which i thought was an ASCII converter) turns it into (195 169). turning everything messy, because the OSC parser thinks it's two characters.
whereas, if i change those two numbers to (130) - the correct ASCII code - and send them over, it displays fine.

god this never ends

giuliomoro

New library has UTF8 support and it works with OSC from Supercollider. Didn't try Pd

Remork

the thing is, i doubt if it's the library's fault - it CAN and will display those characters correctly, when called correctly. which Pd isn't doing.
looks like i'm going to have to run all the artist/title strings through a sieve to catch and replace combo's like (195 169).

giuliomoro

or (not sure if it's more or less work) load the text file from OSC2OLED4Bela and then only send an ID in the OSC message.

Remork

hmm. yeah, that sounds logical.
thing is, i hardly know what i'm doing in C++, so i'd have to copy/paste and struggle my way through that again.. not sure if that 'd be faster. :/

Remork

i just put some of those characters in my startup message, so
print_str("è É ü ö é");
that came out garbled as well. none of them displayed correctly.
so reading the file from OSC2OLED4Bela isn't going to make much difference, i'm afraid.

funny thing is that the É was displayed as -ë, so i KNOW they're in there somewhere.

Remork

well, feel free to try the

Remork print_str("è É ü ö é");

command with a SDD1306 oled - i don't have mine hooked up atm.. maybe it's the SDD1309 going wild, i dunno..

Remork

ok, i think Pd is running Unicode instead of ASCII.
still doesn't quite explain why i can't use those characters in a string straight from C++.

giuliomoro

Maybe the library?
What's your display chip again, and what's the resolution?

Remork

chip is a SDD1309, 128x64.
i'm using the // Standard ASCII 5x7 font that was in there for the SDD1306.
but then again, like i said, if i send the correct ASCII values over osc the display is correct.
so it's going wrong further upstream i think.

pondering making my own OSCformat workaround - or converting the whole textfile to ASCII and read straight from there 🙂

Remork

Remork pondering making my own OSCformat workaround

ended up doing this. took me a google-session to understand the syntax, but it went well.
couple of hours well spent. let's hope that new O2O you guys are cooking up makes it so i'll NEVER HAVE TO DO THIS AGAIN. 🙂

giuliomoro

you can try this one out if you want

https://github.com/giuliomoro/O2O

You'll need to create a constructor for your screen, e.g..: add at the top of the document (after the #includes):

class U8G2_SSD1309_128X64_NONAME0_F_HW_I2C_LINUX : public U8G2 {
  public: U8G2_SSD1309_128X64_NONAME0_F_HW_I2C_LINUX(const u8g2_cb_t *rotation) : U8G2() {
    u8g2_Setup_ssd1309_128x64_noname0_f(&u8g2, rotation, u8x8_byte_linux_i2c, u8x8_linux_i2c_delay);
  }
};

and replace

U8G2_SH1106_128X64_NONAME_F_HW_I2C_LINUX u8g2(U8G2_R0);

with

U8G2_SSD1309_128X64_NONAME0_F_HW_I2C_LINUX u8g2(U8G2_R0);

Then use u8g2.drawUTF8(). If you want to try stuff out from main(), you'll be fine, but for OSC to work you'll need to use the latest dev from the Bela branch.

But again, this may be more of a time sink than anything else if the issue is elsewhere. Though I am confused when you say that it doesn't work even directly from C++ ...?

giuliomoro

I don't think I have a SSD1306 to try it out with. I am fairly convinced that OLEDs don't know anything about fonts (unlike, e.g.: LCDs): it's all in the library, which assembles the image and then sends a bitmap to the display.

Using O2O with a SH1106 and the below

#include "u8g2/cppsrc/U8g2lib.h"

const unsigned int SH1106_addr = 0x3c;
U8G2_SH1106_128X64_NONAME_F_HW_I2C_LINUX u8g2(U8G2_R0);

int main(int main_argc, char *main_argv[])
{
	u8g2.setI2CAddress(SH1106_addr);
	u8g2.initDisplay();
	u8g2.setPowerSave(0);
	u8g2.clearBuffer();
	u8g2.setFont(u8g2_font_10x20_tf);
	u8g2.setFontRefHeightText();
	u8g2.setFontPosTop();
	u8g2.drawUTF8(0, 22, "è É ü ö é");
	u8g2.sendBuffer();
	return 0;
}

I get:
alt text

I get almost the same thing just slightly shifted pretending my SH1106 is an SSD1306. The two are actually pretty similar and depending on the library, treating one as the other may result in just a slight offset (e.g.: u8g2 that O2O uses) or complete confusion (e.g.: the library you are using):

#include "u8g2/cppsrc/U8g2lib.h"

const unsigned int SH1106_addr = 0x3c;

class U8G2_SSD1306_128X64_NONAME_F_HW_I2C_LINUX : public U8G2 {
  public: U8G2_SSD1306_128X64_NONAME_F_HW_I2C_LINUX(const u8g2_cb_t *rotation) : U8G2() {
    u8g2_Setup_ssd1306_i2c_128x64_noname_f(&u8g2, rotation, u8x8_byte_linux_i2c, u8x8_linux_i2c_delay);
  }
};

U8G2_SSD1306_128X64_NONAME_F_HW_I2C_LINUX u8g2(U8G2_R0);

int main(int main_argc, char *main_argv[])
{
	u8g2.setI2CAddress(SH1106_addr);
	u8g2.initDisplay();
	u8g2.setPowerSave(0);
	u8g2.clearBuffer();
	u8g2.setFont(u8g2_font_10x20_tf);
	u8g2.setFontRefHeightText();
	u8g2.setFontPosTop();
	u8g2.drawUTF8(0, 22, "è É ü ö é");
	u8g2.sendBuffer();
	return 0;
}

Using the SSD1309 lines I sent you above gives me a "Remote I/O error", which I blame on the fact that I don't actually have an SSD1309.

Remork

and just out of curiosity, what happens in the old version of O2O, with the font i'm using?
is it just on my 1309, or is the font a bit messed up for those characters on a 1306 as well, is what i mean..

giuliomoro

is it just on my 1309, or is the font a bit messed up for those characters on a 1306 as well, is what i mean..

OSC2OLED4Bela doesn't support my SH1106, so I cannot test that unfortunately!

Remork

i'm actually well beyond the whole thing now, as i wanted my line breaks on screen different -
i'm aiming to spread 6 lines of text over the full display height instead of 8 lines.
because you can never overengineer something to death quite enough

Remork

so now i have Pd running a ton of background stuff to drive the display correctly.
but i'm averaging around 15% cpu, and i'm not getting any dropouts or mode switches with new selections, so it seems to be fine. if it ain't broke..

giuliomoro

Remork i just made a simple [RandomRandomizer] patch to seed Pd's random object differently at startup.
if not, every time i reboot, the random shows its true face as the pseudo-random it is.. every random string is the same then.. boring!

sometimes people would use an analog input reading to seed a random algorithm.

Remork but i'm averaging around 15% cpu, and i'm not getting any dropouts or mode switches with new selections, so it seems to be fine. if it ain't broke..

🔝

Remork

by the way, i just made a simple [RandomRandomizer] patch to seed Pd's random object differently at startup.
if not, every time i reboot, the random shows its true face as the pseudo-random it is.. every random string is the same then.. boring!

so i used [realtime] to check the time between boot time and the first long button press (that's needed to open the OSC connection from Pd), and ran that through a [mod 136] object, 136 being the number of items in my array to randomly choose from. so now it's a lot less likely to have the same standard seed at startup.

happy with the whole thing, just about to wrap it up.

i actually might run the audio output through reed relays as well, to avoid that nasty pop-to-the-speakers in the beginning.. seems to occur well before my display 12v line is pulled high, so i can just use that same signal and same schematic.

giuliomoro

Remork i actually might run the audio output through reed relays as well, to avoid that nasty pop-to-the-speakers in the beginning.

you could try adding a 4k7 pulldown to ground from each of the HP out channels to ground. We added that in the latest revision of the cape, but it may not be 100% effective.

Remork

giuliomoro you could try adding a 4k7 pulldown to ground from each of the HP out channels to ground. We added that in the latest revision of the cape, but it may not be 100% effective.

good enough!

« Previous Page Next Page »