Jump to content

latigid on

Frequent Writer
  • Posts

    2,516
  • Joined

  • Last visited

  • Days Won

    147

Posts posted by latigid on

  1.  

    3 minutes ago, tago said:

    You mean your circle 6 button layout? What's the thinking behind that arrangement?

    31 minutes ago, latigid on said:

    I chose the 6 button "hex" layout just to try something different. My thought was that there's enough space to provide two menu rows of 3 items each. Have to see though, my guess is @Hawkeye will do most of the hard work with the Programma builds ;-).

     

     

    3 minutes ago, tago said:

    Looking at the photo it seems like you can compare the lower lines, they have the same character count (20). Around 3-4 times smaller then LCD character height. But the OLED has more vertical pixels. Maybe a condensed font is the solution to fill the whole display? Or simulate a 4x10 LCD? What looks the SCS on a 2x40 LCD, is there lots of blank space?

    I think it would be possible to do a 4*20 display on a single OLED. Understand that the traditional SCS layout (visible in the MB CV control surface above) typically puts 4 buttons below the LCD to select menu items.

     

    3 minutes ago, tago said:

    I want the SCS mostly for patch selection purposes in a universal synth controller. It would make sense to have a larger font on OLEDs, at least for patches names.

    You're describing the Programma. 1-4 ELO boards with sets of 16 illuminated encoders and 4 "labelling" OLEDs, auxiliary SCS-OLED boards for patch name, envelope shapes, SCS button labelling etc. 

  2. No worries, PCBs should be here today if DHL get their act together. I have white 0.96" OLEDs on the way, could possibly try with a yellow-blue I have left.

    The thing is, you don't have an ordinary button layout, so maybe traditional SCS LCD functions don't make sense anyway. But as far as the display goes, a 2*20 CLCD is 100 pixels across with a gap of ~1 pixel in between characters. So the horizontal resolution is comparable.

    I chose the 6 button "hex" layout just to try something different. My thought was that there's enough space to provide two menu rows of 3 items each. Have to see though, my guess is @Hawkeye will do most of the hard work with the Programma builds ;-).

    This gives an idea of how the text fits, approximately 20 characters:
    56e1e953957da_CSsmaller.thumb.jpg.042e87

    • Like 1
  3. Here's an updated picture:

     5795ef38a4904_SCS-OLEDv1.0.thumb.PNG.d26

     

    You can see 7 pin SIL rows for the displays and the six switches/encoder (two positions possible). Encoders with built-in switches are supported but you have to wire your own pins.

    Possible configs are:

    1. OLED OLED OLED OLED
    2. OLED [6 buttons] OLED
    3. OLED OLED encoder
    4. OLED [6 buttons] encoder
    5. only switches
    6. only encoder
    7. combo of switches + encoder
    8. fewer OLEDs

    Pinning for the OLEDs is based off J15A from the Core32F4, same for the display driver.
    Pinning for the SCS is the standard J10(A). 

     

    It would be possible to split the SCS functions across two boards, e.g. with OLED [buttons] OLED on one and OLED OLED encoder on the other.

    • Like 1
  4. 15 minutes ago, tago said:
    3 hours ago, latigid on said:

    You can't mix different display drivers on the same signal chain without significant re-coding. MBCV uses two separate ports and is noted as an exception. If you wished to have this coded into MBNG you'd likely have to do it yourself. 

    Do you know if it's possible to have say 4x 128x64 OLEDs and 1x 256x64 OLED all with the same controller chips on it in a MBNG system without customizing the code?

     

    I don't know for certain, but at a naive guess I think you would need to program the displays with the maximum pixels in mind. So in your suggested setup you have five 256*64p displays, where the first four are only used at 50%. 

  5. 2 hours ago, tago said:

    I have seen this page, but there are only drafts/wireframes. I wanted to get a real world feel of that thing. :)

    You and me both, PCB protos expected next week. 

     

    1 hour ago, tago said:

    Ok, regarding "MS-20 filter clones x 2 - MIDIbox CV V2" i see 4 OLEDs and one LCD. So its possible to mix displays after all? Is this only available for Midibox CV V2 or custom code?

    You can't mix different display drivers on the same signal chain without significant re-coding. MBCV uses two separate ports and is noted as an exception. If you wished to have this coded into MBNG you'd likely have to do it yourself. 

  6. The 0.96" displays are really nice (hi-res thus sharp pixels) and really cheap. Most also have a carrier board meaning you could mount them easily. The one you found needs an FFC or 0.5mm pitch soldering, so go for the mounted option if you choose this route. 

    I don't think that mixing display controllers is possible without special coding (works for example on MBCV).

    As far as chaining multiple displays, I know @Hawkeye implemented this for the Programma v0.1

    large.gallery_7895_68_21795.jpg.228d4cd0

     

    My SCS-OLED boards will have a similar arrangement of rows of 4 OLEDs, which can be omitted in place of switches/an encoder.

     

  7. We're all coming from different backgrounds, with different time commitments and so on. The number one priority is that the board should work, and that's the responsibility of the designer. Many other choices come down to personal preference or experience, which is totally cool seeing as we aren't under contract to provide a specific service. E.g. I will always put decoupling caps near the power pins, and if you don't believe in them (:-P) it's your choice not to populate those components.

    The direction towards a casing standard is quite smart, because that's often the limiting factor in builds and can contribute majorly to the cost. @Rowan actually suggested that as a direction a little while ago, and it's very doable simply by limiting the PCB height to ~100mm. I don't agree that panel sizes should be equal to a power of two, though there is a loose idea to keep the HP values as even numbers.

    It's very rational to use SMT, not just because of size and certain availability, but it allows for easier trace routing, double sided placement, closer clearance (look at the registers placed under the dot matrices above), less drill hits etc. And you'll actually find that it's easier than through hole assembly as you don't have to clip leads. Can be much cheaper for components too. Avoid SMT on parts that experience mechanical stress like pots, switches, sockets etc. Personally I stick to through hole design when I can.

    Sorry for the off-topic discussion, feel free to split if needed.

  8. The EAGLE library part has pin 1 on the right as referenced to the schematic:

    578b620cc03f1_SchemMolex.thumb.PNG.a3db8

     

    I can't say how this would relate to KiCAD, but it would be great to standardise the power connector on the right relative to the polarity tab on the bottom edge.

  9. Quote

    You need a SEQ somewhere anyway, so power will be taken from there. Adding a power supply connector just creates false hopes, I think.

     

    If the current consumption is "high" then it makes sense to wire the power lines in parallel  EDIT: I should say "star wired." This sends the return current back to the source rather than influencing other modules in the chain. I only asked because I was wondering about the 2-pin connector at the top on the rear side. Flexibility, even if it's "over designed," can extend the device beyond its original purpose.

  10. Quote

    Decoupling caps are highly overrated. If really paranoid you could still fly a through-hole capacitor across the IC...

    I don't agree; I've read about cases where decoupling caps were the difference between a chain of serial shift registers working or not. A fly-wired cap would be just as effective as your current layout -- the closer to the power pins the better.

  11. Nothing wrong with SMD, most of my upcoming modules will have some SOIC/1206. It's better to learn sooner or later.

    Edit: nothing stopping @Psykhaze adding 2HP to his front panel.

    TPD looks cool, but shouldn't the decoupling caps be nearer to pin 16?

    Without trying to spread FUD, I wonder about lots of blinkenlights in a Euro case when potentially combined with analogue modules. Do you have any data on power supply recovery when everything's humming? It could be okay with the PSU driven from the SEQ or at least isolated from the Euro rails. 

    For my latest work, I include a 3-pin 100mil/2.54mm Molex header with the centre pin 0V/ground and +5V on the right when the polarity tab is at the bottom of the connector. The left pin is NC. Could we consider a standard perhaps?

    • Like 1
  12. No question, go for STM32F4. For a start, LPC17 carrier boards are not available AFAIK and they changed the pin config of the MCU breakout which further reduces the compatibility. F4 is faster, has more RAM etc.

    BTW, if you only have a PIC Core at the moment, you have a SEQ V3 :). Perhaps you meant STM32F1, the first gen. Core32?

  13. Keep in mind that Programma v0.2 will use illuminated encoders instead of LED rings. Less holes and more flexibility (colour coding for different sections, modulator polarity etc.)

    As far as a universal controller goes, you get dynamic labelling of encoder functions and "pages" for different synths, different patches etc. -- the ultimate solution!

    It's also a 4*4 grid, so you're free to mix and match with different types of boards, like in the Modulbox concepts Jerome is putting forward.

    This is intended as a MBCV control surface, but it too could be adapted:
    56e1e953957da_CSsmaller.thumb.jpg.042e87

     

    These are Standard Control Surface (SCS) boards which can have 1,2 or 4 OLEDs attached in various configurations (note the 6 buttons are now in the centre):encoder.thumb.png.4a8455f177f9085dca2f885716912be8eeb_buttonshex.thumb.png.44e864OLED.thumb.png.6b56fd63036c057dd8380074

    • Like 2
  14. @Psykhaze, well, the question is: why doesn't everybody just veroboard their switch/LED/pot boards? The ironic thing is this was the original intent of MIDIbox -- custom controllers, and it was out way before off-the-shelf MCUs like Arduino etc. Modulbox and pro-PCBs in general sacrifice this more personal approach for robust and easy to handle solutions. I'm not saying it's a bad thing, but the inevitable outcome is that newbies with no concept of what MIDIbox or a shift register is will come and expect instant results. Be careful what you wish for :itsok:

    SDIY (if we can extend this to MIDIbox) is a community with a wide range of abilities. I would certainly not expect a newb to understand everything from the start just by looking at uCapps and the wiki. Perhaps with your efforts there some info can be clearer. It's just nice to start with a PCB that's almost guaranteed to work so you don't get disappointed. It's very true about taking the time and effort to learn about the basics in a managed way.

    Best,
     

  15. Of course you can use veroboard, but it's flimsy compared to FR4 PCBs and the copper can delaminate. It's also quite time consuming (not to mention error-prone) to wire up the traces, and when that's done normally signal integrity/RFI is poor due to unintentional antennas, lack of ground plane coupling etc. It's also impossible to use non-100mil/2.54mm spaced components without drilling extra holes, which are then poorly fixed. Basically, veroboard is, like, so 2005.

    With dedicated PCBs, one person (or a group) spends lots of time preparing the layout and risking many bugs in the first version. But after, copies are made and everyone can enjoy. @Psykhaze, it's very ironic of you to suggest veroboard when you propose simple PCB layouts (professionally made I suppose) with only a few switches/LEDs/pots etc. for Modulbox.

    As far as Core32 PCB availability goes, I'm considering an alternative layout with a few extra tricks. Perhaps also a "slim" MIDI IO with 2.5mm jack connectors :doubt:.

×
×
  • Create New...