Hawkeye

Thanks, FantomXR! Yes, the displays are very "sharp" and can be read without problems from 40-50 centimeters. Unfortunately, the cam sensor captures a bit of flicker, in reality, they are really great - just like a high-res computer screen :-). Regarding the "positional memory" of your hands: the main labels are intentionally used as "pathfinders" to find the region of interest (e.g. filter), then your hands remember which of the four encoders to grab after a while - it works quite good so far - we will have to wait and see how it works on a bigger synth with multiple pages/banks :-) Many greets, Peter J: no worries with the soldering! Regarding the 3V3 supply, a standard LM317 works very well here - it fits on 2x2cm vector board. A switcher with an additional 3.3v output is not mandatory, but of course you can use it! For 5V, i used a LM2596 switcher, that i had leftover, just as you recommended! It works great, you can feed it with any input voltage up to 30v and it is efficient.

That makes sense! Fighting the "not enough space" battle since years, too! ;-) Methinks (depending on the displays), with a bit of trickery, a reinitialization sequence could be triggered - but it would take some code modifications - and it should probably be avoided, that the displays are receiving updated data during the plugin-process, before the initialization. Might be done with a key, that, when hold obtains the display mutex, after release initializes the displays, then releases the mutex. Dunno if the apps like stealing a mutex for so long, it is experimental and quite some work -> if you can have separate displays, it would be easier, but for science reasons, i'd say it is worth a try! ;-) Many greets, Peter

Probably (re)initializing the displays might be problematic - why not build two control surfaces? You might benefit from different key labels for the MBNG, anyways? Other than that, the SEQ CS can surely be used - it is a good idea, a relatively easy build, large displays, enough encoders and many tactile switches for functions! Many greets, Peter

Thx! After some more tinkering*, the first demo is up - hope you enjoy it :-) (* when using more than 6 displays, a separate 3V3 regulator is necessary, as well as a proper 5V power supply is recommended - the USB connection alone may not be sufficient anymore. But of course, we have 1024 LEDs (multiplexed), a lot of displays and other stuff on there :-)) Many greets, Peter

You could start with drums first, then you have a beat to synchronize your synth recordings to. If you want to start with synths first, then you probably have a free drum midi channel and use the metronome to drive e.g. a short hihat. Many greets! Peter

Thank you! :) Next planned steps: * finalize the missing two LEDring boards (does not look bad, nearly done) * wait for more displays (on the ship from china) * move the 3v3 powersupply away from the STM32F4 - the onboard vreg is probably already close to overload - i always thought, my socks smell funny, but it might be the vreg instead :-) * start with a more complex synth programma config (looks like waldorf q, yamaha fs1r or kawai k5000, but the latter two are really complex) * bling-enhance the bank switcher (superbanks and subbanks, scroll through graphical bank lists on two screens) Many greets, Peter

But me likes punk-tier, cant i convince anyone? pllz? ;-) http://decaydancebitch.deviantart.com/art/Punk-Tier-Jade-384031878 Hehe, many greets and have a great evening, Peter

Sorry, we started building with boards we still had in stock and with a display orientation, that we liked :-) Imho, the small OLEDs wont give the same overview as LEDrings, also missing bling is baaaad!! :-D Many greets! Peter

Looking nice! We have lots of the 128x64 displays on order, so our Programmas will prolly use these, as they are not so cheap in larger numbers :smile: Personally, i like the 45 degree mounting style a lot, but it is a design question, tastes may differ, there is no right and no wrong :smile:. We currently have the bigger problem, that fairlightiii is absent, and it would be best to have the LEDring boards re-designed with a possibility to attach FantomXRs new OLED carrier boards, but no one has the source files! With a new board revision, the LEDrings could be adapted to be a bit smaller in diameter, then the 128x64px displays could optionally fit horizontally. As the labels are just "dumb" graphics files loaded, every user can decide on his preferred display mounting style by just swapping the graphics files on the SD card. Have a great evening! Peter

no worries, no cut-out is needed, as long as the shorter side (vertical) is 26mm :)

One cap/resistor is sufficient for the reset lines of four displays. I've attached a pic of the cutout - you can omit it, if you make the boards 28x26mm (26mm = the side where the connector is wrapped around). edit: i've remeasured with a digital caliper. make that 27x26mm - the display has a width of 26.75mm Many greets, Peter

Looking awesome! If you want to ensure MB-LRE "diamond" configuration compatibility (i.e. to mount them in the 45° angle between the LEDrings), the PCB size should not be larger than 28x28mm and should be preferably quadratic in nature - to achieve that, the original boards had a "nose" cut out to accomodate the 180° bent connector cable, as it takes up room as well. Many greets! Peter

Cool! :smile: TK., when you have them in hand, would you have a look at the timing? It might be, that because the STM32F4 is faster than the LPC17, the number of waitcycles is not sufficient anymore - and that causes the phenomenon, that it works for jbdiver (LPC17) and not for cube48 (STM32F4). Many greets! Peter

Nice! I checked: the reset line, and BS0-2, that looks good, it is too late for the rest now :) Maybe reduce J1 to a smaller footprint? 6 pins should be sufficient, imho. Many greets! Peter

Very cool! :-) We currently have 6 buttons and one encoder in the lower menu area. One reason for this choice was to minimize input serial register use (standard SCS mapping, directly attached to the core). The hope was to be able to attach a maximum number of LEDRing boards - each of them uses four input shift registers, and there was the fear of a too long serial chain, when using another DIN module for more inputs. Also, there was the hope, that we might be able to extend the existing LEDring boards with an addon-box with even more LEDring-boards later on - this was therefore prioritized over more input possibilites in the menu section, as our goal was to get a maximum size encoder array :-) (we don´t know the hardware limits of the serial chain yet and how many more LRE boards are ultimately possible). Another reason was the goal of a quite minimalistic/clean programma main surface (with everything necessary involved, but no luxury items/and no excess area used up by controls, that may not be needed by every application) and to design addon boxes for specific use cases later on. The available surface space is quite limited and has been optimized for the Formulor/Ponoko size panels (vertical and horizontal limit of 384mm) - with this, we were able to fit eight OLEDs in the lower compartment. And, we have one push-acceleratable encoder for subbank and superbank switching, a menu button and five freely assignable switches, that allow for 25 custom bookmarks to be very quickly reached with a fast and easily memorized two-key-combo :-) (see below). Synth-specific stuff, like selecting LFOs, waveforms, envelopes should imho only be handled on the lre-boards, not in the menu section, as we have many different synth targets and we cannot produce hardware that maps to every necessary function - so the idea is to stay generic here, utilize the label OLEDs for best description what each encoder does and hope for the best! :-) Regarding the lot of lower menu OLEDs: * One of the lower OLEDs is intended to be used as a key indication screen/menu, that shows which of the menu buttons is mapped to which function, so we are very dynamic here - to build a bookmarking system: with two levels/key presses, we can reach 25 shortcuts, that lead us to different target banks within the programma, or fire .ngr scripts, or other actions. Every bookmarked action/target bank is documented on the keyscreen. * Another one of the OLEDs is used as an indicator which target synth (MBNG patch) is currently used, and for status message flashes. * Then, we have four OLEDs for dynamic parameter description/graph/value output. What would be really nice would be an envelope display on those screens. Or synth specific addons, like a comb filter display for the K5000. Or... the algorithm selector for a FM synth. Anything, that needs a bit more complex visualization and description text... these screens get updated, when the respective encoder is turned. If no specialty (e.g. an envelope) is being displayed, there can be a long description of the currently changed parameter and its current and initial (snapshot) value. As we are potentially dealing with a lot of parameters for the complex synths, a bit of information text should be very nice, some synth engines are very complex and not easy to grasp. * The remaining two OLEDs should display the current superbank and the subbank. This concept is just a logical extension of the standard MBNG banks - it is just a hierarchical access scheme. The superbank can be changed by pushing the menu encoder while turning, the subbank can be changed by only turning the encoder. This allows for a clean segmentation of banks. The two displays act as a "breadcrumb display", that shows the currently active superbank (for example "voiced operators" for the FS1r) and subbank ("voice 1"). To reach a new superbank, push and turn, to switch to a new subbank, just turn the main encoder. That was the navigation idea, at least. I know, these are a lot of things on the agenda and there is so little time - let's see where we will be headed. It might be a slow process, as we have daytime jobs :-) In conclusion, my feeling is, that the main menu's navigation options (with the presented segmentation via main encoder, and the quick access via five*five bookmark general buttons) should be sufficient for any programma needs (even for large synths). All synth-controller functionality, on the other hand, should be handled within the encoder section (with help of the dynamic labels). If encoders are not sufficient, we have the option to extend with external boxes. With the use of an AINSER64, there are lots of analog ins available for additional joysticks/pots or even plain switches for specific (maybe even synth specific) additions. Sorry for the long text :smile: Many greets and have a great evening! Peter

nope, unfortunately me got nothin' (as usual) :smile:

That sparkfun display looks nice! :-) The suggestion was to install the reset cap/resistor on the board you are designing. This saves one line (6 instead of 7) and also the users can forget about installing a cap and resistor somewhere to properly initialize their displays :smile: Many greets, Peter

Yes, that is necessary for the correct "late" initialization of the OLEDs: after powerup, the cap is charged, only when it is full, the RST pin toggles its state from "reset" to "run". This filters initial garbage on the data lines and power fluctuations during the first milliseconds after power is available. You can use a shared resistor/cap for many displays for this (then 7 wires per display are required), or you can save one wire and mount it on the small boards with two cheap smd components. That would be indeed nice! And preselecting the 4-wire SPI mode is cool, too! :) Many greets, Peter

yes, there is no vreg on the board - the displays work fine with the 3.3v supply of the core edit: a design topic, so the tastes may vary, i personally like the 45° angled OLEDs a lot. it is something differrent. yarr! So not much more need for space, but a better connection scheme would be awesome, maybe one that allows for easy connecting to a future MBLRE board :-)

:-) If you look in section 1.6.2 "Block Diagram", vcc generated internally http://www.buydisplay.com/download/manual/ER-OLED0.96_Series_Datasheet.pdf ...the 6 caps and the 1 SMD resistor correlate with the current carrier, also the BS0-2 protocol selection lines. I think you have a good chance implementing it like this. R1 = 390k matches, just validated Many greets, Peter

Cool! I can take some high-def photos of the carrier board of the OLEDs. This should help, the wiring is not difficult, not a schem, but close! :smile: I have a disassembled one lying around anyways, the displays lifespan was not first-grade :-) Edit: the linked empty carrier != the current carrier, that is in use - where is the datasheet? Many greets! Peter

But can you really save so much cash? The full boards with OLED-combo is like 6$ with OLEDs already soldered - the OLEDs alone are like 3$ - what is the expected production cost of the boards? Do we need to solder SMD vreg components? My full board combinations also have 6 small smd caps, that might be necessary for filtering - that is quite an effort for a max of 3 $ saved. UNLESS, you can realize a better form factor, which benefits many projects, that is prolly why J had the Programma in mind, where we really are out of space! :-) Many greets, Peter

They are all driven in 4 wire SPI mode, 6800 / 8080 would imho need moar than necessary data wires. Currently, a SSD1306 needs 7 wires to wire and it is already some wiring! (Forgive me, too many solder fumes!) :hyper:

if you´ll send me two for permanent testing, i could try to hack the driver! :smile: . . . ...was just joking! I´d love to build another SEQ with those displays later on that year, but it will take while - hope you manage to find the problem, if not, and no one else has ideas, i´d order two of them, too, to test. Later on :-). edit: it is probably timing related, as with many OLEDs, they could also have changed it from one firmware revision to the next - if you want to experiment, look into the mios32 repository /trunk/modules/app_lcd/universal/app_lcd.c and experiment with all timing specific code, e.g. look for delay_ctr and adjust the loop limits. !!! There could be differences between LPC17 and STM32F4, as the latter board is faster, and this would explain why it works for jbdiver! Some internal loops expect fixed runtime behaviour, like 4uS @ 72mHz - play around in app_lcd.c, line 474 and following. Good luck! You could also test-swap the core for a LPC17 and see if that helps, if the theory is true, the displays are identical, only the timing code behaves differently on the different cores. Peter

Hi Chris, great idea! One of my displays was DOA, a problem with the connector cable. I tried to solder it, but it is a challenge. Not impossible, but you´d need a very fine smd soldering tip and steady hands. I failed! :smile: and ordered moar from mah favourite Swedish supplier! ;-) Many greets, Peter