Remork where nuromantix managed to drive a display from pd, but the link to the pd patch in response #10 is dead.

the final result of that was this: https://blog.bela.io/2018/03/27/opal-rhythm-computor-dmx-krew/

Look at what @crosswick and @RafaeleAndrade have been doing: https://forum.bela.io/d/314-is-anyone-successfully-using-i2c-oled-lcd/73.
Basically you could use https://github.com/giuliomoro/OSC2OLED4Bela stand alone program which gets OSC inputs and outputs it to an OLED display. This is a Bela project, but doesn't actually do any audio rendering,
so you can have it running alongside the your Bela-Pd program, which would then send the OSC to the other one.

Makes sense?

Otherwise, and for reference, the canonical way of making this work as a "single" Bela-Pd project is:

      giuliomoro Makes sense?

      sort of 🙂
      i get the idea. the actual implementation and steps needed are a bit of a blur, but that'll probably clear up when i dive into it. will have to read up on the different standards though, see what fits the needs.
      * a whole new woooorld

        so i'm looking at datasheets over at Mouser, for I2C- compatible OLEDs.
        for this particular project, i would like to use a display that's as large as possible (unlike most projects, i guess.)
        most of what i find seems to use things like SSD1322 or US2066. am i correct in thinking that the linked SSD1306 library isn't going to work with those?

          18 days later

          Remork be impossible to use with Bela?

          probably so.

          See the list of used pins [very hard to find].
          At least these:

            "P9.28", /* pwm: eCAP2_in_PWM2_out */
  "P9.29", /* ft5336: gpio3_15 */
  "P9.31", /* ft5336: gpio3_14 */

          are already being used by Bela for audio I/O purposes.
          Maybe some could be remapped. The last two are used as GPIOs so most other pins could be used instead. but the first one seems to have a pretty specific use case. Maybe P9.42A could be used instead. Using alternative pins would involve bending out the pins of the screen cape so that they do not enter the BBB's header and then jumper them with wires. The other issue is that the software support for the screen seems to be patchy. From what I understand they want you to install their image, which is clearly bonkers.

          If there is a way to simply install the drivers AND P9.42A works then maybe it can be done.

              hah. gotcha.
              the only answer for me would be 'nevermind' then.
              thanks for clearing that up.

              ordered me some OLEDs, so i'll probably be back to ask more questions than you can answer.

                Remork ask more questions than you can answer.

                Challenge accepted. If you are on Bela, do not get an SPI one. If on BelaMini, SPI is fine.

                  4 days later

                  Remork s members-only content.. can't even open that link.)

                  I know right, but what can I say? Push for the manufacturer to make their documentation more readily available and accessible? Prefer other manufacturers that do? (registration to Element14 is free, by the way)

                    didn't mean anything by it, just seemed a bit surprising for a community-based brand.
                    i wouldn't mind registering if i thought it'd make sense to do so.
                    but tbh, i wouldn't know where to start looking for what i need - and even if i found it i'm not sure i would fully understand. once you start about what pins are already in use and remapping them, my eyes glaze over and i'm in Malibu with a coconut cocktail, mentally. (i try to learn, though.)
                    plus, chances of me using a BBB without the Bela are just about zero - i only use them because it's where Belas live. i have a hard enough time getting my head around the Bela 🙂

                    and so as long as there's people like yourself kind enough to help people like myself out.. [humbled]

                    8 days later

                    so i got the displays in.
                    since most of this is going well over my head, i decided to take a few tiny steps at first.
                    so i hooked up the one with the SSD1306 controller, leaving the SSD1309 for what it is for now.

                    i uploaded these files to my Bela Mini:

                    and i'm just running that as is, not even sending it OSC messages yet.
                    it seems to work - in that i got the 'OSC TEST!' message on the display. which was quite astonishing 🙂
                    changed that message in render.cpp line#165, played around with that a little, and then noticed that the text wrap was off.
                    now i'm sure that has to do with the fact that i have a 102x64 display hooked up instead of a 128x64..
                    i'm plowing through the code and the datasheets, and managed to change the column address to range from 13 to 114 as per the display datasheet. now the wrap seems to be fixed, but i'm losing a whole lot of characters from the beginning of the string. i'm sure it's just something small somewhere. more testing tomorrow!

                        seems promising for now! I haven't really looked into the content of the library: I try to avoid actually reading the code any time I can get away with it and focus instead on the integration/wrapping of it with the rest.

                        Remork 13 to 114 as per the display datasheet.

                        What change did you make there? ( a diff would be very useful in these cases). If you are losing the first 13 characters, it may be that the library already handles that initial offset elsewhere and you may have to set the range to 0 : 102 or similar (this is just a blind guess, without looking at the library code. Tell me where you changed it and I will have a look)

                            giuliomoro I try to avoid actually reading the code any time I can get away with it

                            LOL 🙂 you and me both, hah. but i do want to understand what i'm doing, so if i can muster up the courage, i don't really mind. on some days.

                            i'm gonna start fresh from those files, and adjust just a single parameter at a time.. see if that makes more sense.
                            if i can't work it out, i'll yell.

                              in SSD1306_OLED.h, there's these settings for display sizes:

                              #define SSD1306_128_64 (default)
                              //#define SSD1306_128_32
                              //#define SSD1306_96_16

                              setting WxH to 128x64, 128x32 and 96x16, respectively.
                              i had hoped it would be as simple as modifying those values (SSD1306_LCD_WIDTH and SSD1306_LCD_HEIGHT) to the size of the display i'm using, aka 102x64.
                              but no such luck - very garbled results.

                              if i go back to the default settings and run a teststring ("0123456789abcdefghijkl.." etc) to start at cursor(0,0), i lose pixels at both ends of the display. if i start at cursor(13,0), the first line starts ok. which is consistent with the datasheet: https://docs.rs-online.com/1ff8/A700000006657120.pdf, using columns 13 - 114 (page6, top right.)

                              i just noticed that setting the start and end column is possible, but is not included in 'display_Init_seq()'.
                              i will try adding those.
                              nevermind. it's included in the 'display()' routine. doesn't fix my problem though..
                              setting start and end to 13 and 114, the wraparound is now correct - but i'm back where i started losing a huge amount of characters at the start of the string, and it's adding spaces between characters where there shouldn't be any. also it seems to be starting at line 24 rather than 0 (aka letters start on 'third row' with ch size 1.)

                              (sigh. maybe just buy me some proper I2C 128x64 SSD1306 OLEDs.. )

                              could this have anything to do with the sequence in which everything runs?
                              right now it's initialization - clear display - set string - and then display().
                              the latter which: 1. Resets the column and page addresses. 2. Displays the contents of the memory buffer.

                              as i understood it, setting the columns also sets the RAM locations.
                              so is it possible that i need to set the columns, thén set the string to correctly allocated memory, and then display buffer contents?

                              hmm.
                              the display is indeed acting like a cut-out version of a full 128x64 display.
                              if i set everything to default (so size 128x64), the graphic examples (testdrawcircle() etc) work ok, but as i said i'm losing text on both sides.
                              if i set start and end column to 13 and 114, everything goes haywire 🙂

                              if i set start and end column and drop SSD1306_LCDWIDTH to the required 102, it's more promising!
                              but not quite there.. see pic. this is the "testdrawcircle()" from the examples.
                              the weird thing is that the whole animation is ok, but then when the animation ends the top of the screen is being blacked out.
                              alt text

                              if i run an example with multiple actions (draw lines etc), in between stages it does the same thing.

                              now the only thing that recurs everywhere is "Display()".
                              this sets the start/end column/page, which i believe to be correct (otherwise the circles wouldn't be centered?).

                              but it also calls "transfer()", which it does at the end, and which transfers the buffer onto the display.
                              could it be i have to adjust the size of the buffer somewhere? that it is writing empty blocks last, using only 102x64 of a 128x64 size buffer, or something?