latigid on

MIDIbox SEQ new frontpanel idea

301 posts in this topic

Hmm, or maybe dispense with the switch plate entirely, PCB+diode mount the swiches (like a poker 2). Instead, have a single simple plate hung from the left and right of the front panel, and maybe the middle by the encoders, reminiscent of IBM keyboards. The PCBs then mount to that. It'd be heavy as hell, but much stiffer, and easier to have manufactured?

I've just realised this design dispenses with the big datawheel! A pity - I'd designed a parametric clone of the ALBS DK16-190V3 in OpenSCAD. I was toying with the idea of printing one at iMaterialise at the appropriate size to test the design.

Screen Shot 2016-12-14 at 10.53.31.png

Share this post


Link to post
Share on other sites

I don't entirely get it, Poker 2 still has a switch plate. Also Cherry MX switches have the central mounting post and, if not plate mounted, two plastic stabilising nubs for the PCB. Matias have merely two through hole pins, so need some stabilisation. Likely it'll still be a bit wobbly.

The encoders and aux switches need to be elevated -- the keyswitch + cap is more than 20mm tall, but the encoders have a usable dimension of about half that.

The datawheel could be accommodated by removing two switches, using a smaller cap, cutting down two of the switches or spacing the PCBs further apart. The best implementation IMO is to have a data encoder with a FAST function switch.

 

Quote

They say a camel was the result of designing a horse by a committee ;).

 

Share this post


Link to post
Share on other sites

Sadly, I'm pretty bad at drawings too, so I'll try and describe it better. Sorry about the Poker2 reference - I read that it did not use a separate stabilising plate.

1) At the back, you have a solid, flat, metal back plate.

2) The next layer up is the keyswitch PCB, which is bolted to the solid plate on standoffs, leaving space for the PCB stabilisers and plungers of the keyswitches. The keyswitches would be staked with diodes to the PCB, and so wouldn't need a stabilising plate.

3) The next layer would be the boards for the encoders/aux switches. Instead of being on blind standoffs, these would have holes in the PCB, and sit on spacers. 

4) The next layer would be the front panel, which is bolted through spacers, through the encoder boards, through the encoder board spacer mentioned above, and finally through the back plate. At the side without an encoder board, it could be bolted straight to the backplate through a single spacer. This pulls the whole sandwich together. The back plate provides stiffness and reinforces the front panel, and the back plate provides a surface for having lots of mounting points for the keys, without consuming all the internal space in the case.

So 1+2 have lots of mounting points, to provide through support, and then 1+3+4 provide rigidity and overall mounting. Because 1 only involves cutting and drilling, it would hopefully be cheaper to manufacture than the cutting, milling and folding that a keyswitch stabiliser plate design would require.

Share this post


Link to post
Share on other sites
24 minutes ago, latigid on said:

The best implementation IMO is to have a data encoder with a FAST function switch.

My take on best implementation would be an ALPS SRGP jog-shuttle.

 

ALPS jog shuttle.png

Share this post


Link to post
Share on other sites
8 minutes ago, lis0r said:

Sadly, I'm pretty bad at drawings too, so I'll try and describe it better. Sorry about the Poker2 reference - I read that it did not use a separate stabilising plate.

1) At the back, you have a solid, flat, metal back plate.

Sure

8 minutes ago, lis0r said:

2) The next layer up is the keyswitch PCB, which is bolted to the solid plate on standoffs, leaving space for the PCB stabilisers and plungers of the keyswitches. The keyswitches would be staked with diodes to the PCB, and so wouldn't need a stabilising plate.

Lost you there. For reference, these are the switches to be used -- no diode mounts, no external plungers.


quietlinearswitch_header_1.jpg

8 minutes ago, lis0r said:

3) The next layer would be the boards for the encoders/aux switches. Instead of being on blind standoffs, these would have holes in the PCB, and sit on spacers. 

Could work, at a risk of having long skinny PCBs (prone to flex). Current design has some standoffs matching with the base PCB, they just can't go up to the front panel.

 

8 minutes ago, lis0r said:

4) The next layer would be the front panel, which is bolted through spacers, through the encoder boards, through the encoder board spacer mentioned above, and finally through the back plate.

This is more or less what I thought, except no mounting to the front panel. If this is the case, we could even think about a much thinner steel panel, making the LCDs/OLEDs prettier ;).

 

8 minutes ago, lis0r said:

At the side without an encoder board, it could be bolted straight to the backplate through a single spacer. This pulls the whole sandwich together. The back plate provides stiffness and reinforces the front panel, and the back plate provides a surface for having lots of mounting points for the keys, without consuming all the internal space in the case.

As it is. there's almost no room on the "southern" edge of the front panel. The switch caps go very close, so the only place for standoffs is slightly further in. With luck, there'll be no problem with many standoffs anchoring the base PCBs, as the only thing left to consider are I2C (PIC only) modules. 

 

Quote

having lots of mounting points for the keys, without consuming all the internal space in the case.

unless I'm not following you properly, this is a contradiction? Either you have lots of "internal space" (underneath the Base PCBs), or you have lots of mounting holes filling that space.

 

8 minutes ago, lis0r said:

So 1+2 have lots of mounting points, to provide through support, and then 1+3+4 provide rigidity and overall mounting. Because 1 only involves cutting and drilling, it would hopefully be cheaper to manufacture than the cutting, milling and folding that a keyswitch stabiliser plate design would require.

Lost you again. The "plate" is nothing more than a fibreglass PCB with cutouts to hold the switches, and through hole pads for encoders, aux switches, a few LEDs and sandwich header pins. 

 

Are we on the same page yet?

 

 

4 minutes ago, ilmenator said:

My take on best implementation would be an ALPS SRGP jog-shuttle.

 

ALPS jog shuttle.png

 

Heh, of course :). I actually have one salvaged one from an old controller. They're friggin massive though, and I've never understood the handling properly. Does the jog part have multiple switch contacts that close in sequence?

 

Share this post


Link to post
Share on other sites

I think the jog part is actually a pot, so an analog input pin (or two, one for each direction?) is required. I can look that up.

Share this post


Link to post
Share on other sites

Sorry, my terminology is confused. Jog is the encoder, shuttle is the side part. Right, I remember it may have been a pot element to measure the acceleration.

Share this post


Link to post
Share on other sites

Oof, this thread is getting difficult to keep track of. Perhaps we need the current proposal in the wiki somewhere? I thought Cherry MXes were still the favoured component.

It's looking a lot like this won't be compatible with my case, so I suspect it's not going to be for me anyway. Guess I better keep an eye peeled on the shop for if the current CS boards come back into stock.

Share this post


Link to post
Share on other sites

I like and use this one, up/down/left/right/button/jog but no shuttle.
1908271-40.jpg

Share this post


Link to post
Share on other sites

I saw those at Mouser, about $5 each and a smaller size. The height is difficult to work with, unless there's a carrier PCB. Nice!

Meanwhile the official ALPS combo jog/shuttles look to be unobtainium, unless you have a reliable source to salvage? The huge size and difficultly finding compatible panel hardware makes it unlikely, although it would be super cool to add.

So I had a go at modelling the current idea. The alignment isn't perfect but you get the gist I hope.

large.585272f734d54_frontoblique.PNG.356

 

large.585272f7963d6_yedgerev.PNG.069dc64

 

large.585272f821dd1_yedge.PNG.62431883f4

Share this post


Link to post
Share on other sites

A few extra thoughts perhaps.

I didn't cut out the panel where the switches go, but it would need to be fully removed around them. The combined PCB y dimension is perilously close to 3U (the panel given is spec'd to  ca. 483 * 132 mm). I think it should still fit, but maybe in a steel case with thinner metal. 

4 encoders on the vertical seems too cramped. 

Share this post


Link to post
Share on other sites

Comparison with DCS (best guess at the shape).

Panel was removed.

58528d19c0577_obliqueDCS.thumb.PNG.1eb4d

 

58528d1b76c72_yDCS.thumb.PNG.06865b0b81e

Share this post


Link to post
Share on other sites

Maybe we do need a jog/shuttle after all?

 

large.front_1.PNG.2aac4542058a9d3190186dlarge.front_closer.PNG.9fe63e2ccddb6823clarge.right_1.PNG.bbd151221062080b820e1e

 

In the middle or to one side? (Could be made lefty too.) On one hand I like the symmetry, on the other the x edges of the display windows are ~60mm apart vs 30mm (closest they can be). 

The clear benefit is the jog carrier PCB would be about the same size as a Core and mount above it = fewer headaches trying to dance around standoffs on the switchboards. 

How then to assign tracks (/groups) and layers? A few more encoders? Or buttons to assign track/layer scrolling on the jogwheel? Or, make use of the 16 buttons along the bottom row. I think it makes best sense to have switches separate from the BLM though so you can go through tracks on the fly without changing modes.

 

How to handle the shuttle? If it's no good to use the Core ADC, a separate chip would be easy to do. The resolution doesn't even need to be very high.

 

 

 

Edited by latigid on

Share this post


Link to post
Share on other sites

Good job on the modelling. Jog wheel off to one side would be my pick. The gap in the middle could possible be reduced more? The pics do make it look very busy hardware wise, which adds to cost, which brings silicon pads back into my head to simplify the whole shebang. (sorry)

Share this post


Link to post
Share on other sites
Just now, mongrol said:

The gap in the middle could possible be reduced more?

No. The displays are hard up and that's the minimum spacing (check on Wilba's).

 

Just now, mongrol said:

The pics do make it look very busy hardware wise, which adds to cost, which brings silicon pads back into my head to simplify the whole shebang. (sorry)

No, at least not from me. Rubber pads are not aligned properly and are too small to put an RGB LED underneath, let alone the whole top layer is exposed copper pads. Maybe with a 4-layer board, but then you're back to costs going up. 200 Matias switches are 40 GBP or so, 16 adafruit pads are 5 USD. So about the same price. It's non-trivial to get pads and encoders on one board due to vertical spacing (milling needed). No real space for legends on the front panel, unless you have (special silicone glue) stickers as TK suggested.

Anyway, thanks for your input.

 

Share this post


Link to post
Share on other sites

I'm still confused about what's jog and what's shuttle :)

I found a more detailed datasheet

 

585334ca8e26e_Jogshuttlecode.thumb.PNG.8

 

So the "shuttle" is an absolute position encoder (10 degree resolution?), while the "jog" is apparently a 10 ppr relative encoder. I think the latter function is limited in its rotation with a spring return, not sure though.

Share this post


Link to post
Share on other sites

Following your terminology above, the shuttle should be spring loaded (and return to its zero position, hence the outer ring). The inner element (jog) is a regular relative encoder, for sure.

At least from one MIDI implementation example (Peavey Studiomix), the assumption of an absolute encoder does make sense: the Studiomix sends out only four or so different MIDI messages per side, depending on angle position.

Share this post


Link to post
Share on other sites
8 hours ago, ilmenator said:

Following your terminology above, the shuttle should be spring loaded (and return to its zero position, hence the outer ring). The inner element (jog) is a regular relative encoder, for sure.

At least from one MIDI implementation example (Peavey Studiomix), the assumption of an absolute encoder does make sense: the Studiomix sends out only four or so different MIDI messages per side, depending on angle position.

Absolute = unique code for each position, relative/incremental = direction info only (and commonly used in MIDIbox).

I found a fleamarket post of yours that you had a bunch of jog shuttles, are any left? Both the knob and mechanical parts are on the inventory at ALBS.de

16122016.thumb.PNG.93d04a5960dbf2d2c9d9c

Internal case height = 45mm, not too accurate on the Core positioning (needs a carrier).

 

 

Share this post


Link to post
Share on other sites
52 minutes ago, latigid on said:

I found a fleamarket post of yours that you had a bunch of jog shuttles, are any left?

Yes, I should have about 15 or so left, maybe even more, complete with the plastic parts. I can check when I get back home later tonight. I think they have the pins bent upwards, because they were mounted in a cutout inside the PCB that is shaped like the controller itself, and soldered in from underneath. However, I think it would be possible to bend the legs back into place or even just solder some wire (or cut-off resistor legs :grin:) to the pins if needed (and if you want the controller to sit higher on top of the PCB).

Share this post


Link to post
Share on other sites
On 12/16/2016 at 7:21 PM, latigid on said:

No. The displays are hard up and that's the minimum spacing (check on Wilba's).

 

No, at least not from me. Rubber pads are not aligned properly and are too small to put an RGB LED underneath, let alone the whole top layer is exposed copper pads. Maybe with a 4-layer board, but then you're back to costs going up. 200 Matias switches are 40 GBP or so, 16 adafruit pads are 5 USD. So about the same price. It's non-trivial to get pads and encoders on one board due to vertical spacing (milling needed). No real space for legends on the front panel, unless you have (special silicone glue) stickers as TK suggested.

Anyway, thanks for your input.

 

The switches make it for me. This is looking so good. Thanks for all this work.

Share this post


Link to post
Share on other sites

I think that additional buttons will be required, maybe above the Jog Shuttle.

They would allow to switch the keyboard into different modes, such as

  • 1 button to select the "normal layout", the 4th row (which is not available on Wilbas frontpanel) is used to select tracks
  • 1 button so that the 4th row is used for mutes
  • 1 button so that the 4th row is used to select parameter layers
  • 1 button so that the 4th row is used to select trigger layers
  • 4 buttons to switch to BLM mode and to select the 4x16 segment
  • maybe some spares if space is available

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

There are four spare buttons on the TPD which could be used if space is unavailable here.

Share this post


Link to post
Share on other sites
10 minutes ago, TK. said:

I think that additional buttons will be required, maybe above the Jog Shuttle.

They would allow to switch the keyboard into different modes, such as

  • 1 button to select the "normal layout", the 4th row (which is not available on Wilbas frontpanel) is used to select tracks
  • 1 button so that the 4th row is used for mutes
  • 1 button so that the 4th row is used to select parameter layers
  • 1 button so that the 4th row is used to select trigger layers
  • 4 buttons to switch to BLM mode and to select the 4x16 segment
  • maybe some spares if space is available

Best Regards, Thorsten.

 

Good feedback -- thanks!

There is still space to the left of each 8*4 section -- my thought was to include pads for three (or maybe four) encoders/buttons, and make the PCBs roughly the same dimensions as LCDs/OLEDs. I would recommend only the left-most encoders be installed, in order not to have height conflicts in the middle. Then, as the original idea started, tracks, parameter layers and trigger layers would be accessed via encoders. Wouldn't the handling be better than a multi-mode 4th row? Plus, it frees the 4th row buttons for currently unused or future functions. The "track encoder" would shift the "track group" in BLM mode -- I believe that's how it works for the current 16*4 BLM.

Buttons, or even a "data encoder" if the jog/shuttle isn't included, could then be put in the middle, or on the outside. In fact, the "jog/shuttle carrier" could be placed where it suits -- in the middle, on the side, or left out. But it was certainly my idea to include more buttons on this PCB. :) I will try to make the HW as flexible as possible, but it's very important to hear implementation ideas.

One thing I like about the current setup is it constrains track selection to one part of the interface. Using the GP buttons or 4th row is a nice implementation and very logical with 16 parameters, but makes one search across the whole interface for the correct track. That's not a criticism, but only an observation. It might be quite different when the HW is set up in another way.

 

 

Share this post


Link to post
Share on other sites

Ah, here's a current shot of case designs, with a 15 degree slope (I believe the Heidenreich case is 12):

 

image.thumb.png.9d8e107e5b9853acfc5851b3

 

The strange square/cylinder things are me playing with ideas of how to secure a sloping surface to the bottom of the case.

899153260_o.jpg

 

Another:

B2S3_grande.png

 

 

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.