Jump to content

MIDIbox SEQ new frontpanel idea


latigid on
 Share

Recommended Posts

2 minutes ago, latigid on said:

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?

No, encoder are worse than buttons.

Buttons can be operated almost "blindly", encoders require visual focus to the display and could sometimes select an unintended track if not operated careful enough.

I noticed this on the MB808 frontpanel - no fun!

Quote

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. 

I would prefer to select tracks, mutes, parameter and trigger layers with the 4th row

By providing another button to select the bookmark (BM) function the user could store and restore any kind of other function (see documentation, bookmarks are very powerful, since they not only allow to switch to pages, but also to select tracks, mutes, etc...)

Quote

The "track encoder" would shift the "track group" in BLM mode -- I believe that's how it works for the current 16*4 BLM.

Too waggly usage, not useful in live situations!

Quote

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.

For me such a big jogwheel in the middle doesn't look nice.

Better to place it at the right lower corner, and some buttons below.
Probably you've to provide an alternative frontpanel for lefthanded users

Quote

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.

Buttons should be labeled... by giving generic labels 1/A, 2/B, 3/C, ... users will quickly learn the position and sooner or later operate without focusing the labels anymore...

Best Regards, Thorsten.

Link to comment
Share on other sites

2 hours ago, TK. said:

No, encoder are worse than buttons.

Buttons can be operated almost "blindly", encoders require visual focus to the display and could sometimes select an unintended track if not operated careful enough.

I noticed this on the MB808 frontpanel - no fun!

I would prefer to select tracks, mutes, parameter and trigger layers with the 4th row

 

Well, we could consider an encoder that scans through and illuminates the 4th row ;-)
808 colours for tracks?

Roland_step_3.jpg

 

 

Quote

By providing another button to select the bookmark (BM) function the user could store and restore any kind of other function (see documentation, bookmarks are very powerful, since they not only allow to switch to pages, but also to select tracks, mutes, etc...)

Good point.

 

Quote

Too waggly usage, not useful in live situations!

Quote

4 buttons to switch to BLM mode and to select the 4x16 segment

these buttons are essentially the four track groups, no? If tracks were handled on an encoder, then in BLM mode an encoder could scroll through the groups, even using lower resolution if too waggly.

 

Quote

For me such a big jogwheel in the middle doesn't look nice.

Agreed, I'm most sold leaving it on the right. Others may prefer an ordinary three pin encoder. The jog/shuttle takes 6 DINs ( @ilmenator are they detented?) but the scrolling + acceleration could be very nice!

 

Quote

Better to place it at the right lower corner, and some buttons below.

I was thinking more buttons above, but I can model some different layouts and ask for opinions. You may want to rest your palm underneath the wheel, or at least not hit anything while jogging.

 

Quote

Probably you've to provide an alternative frontpanel for lefthanded users

Of course :). The actual rear panel would be very simple: 16 DINs, USB Type A (OTG/host) or Type B via a panel mounted adaptor, SD or micro SD and probably a DB-25 for AOUT/DOUT or line driver. I think that's all that's needed? So -- the modular button and "jog/shuttle" boards can be rearranged as needed. 

 

Quote

Buttons should be labeled... by giving generic labels 1/A, 2/B, 3/C, ... users will quickly learn the position and sooner or later operate without focusing the labels anymore...

The keys are "relegendable," so you're free to have any paper or professionally printed labels as desired. The difference will be these "extra" buttons that should be defined and the handling considered. With 3D models it's easy to come up with the concepts before anything's ordered.

 

Can we think about modes a bit more? At the moment, GP buttons are used to trigger steps on the selected layer of a track. Will this be retained, or are triggers only actioned in BLM mode? If the latter, then this allows the menus to be accessed without pressing MENU first. 

This idea has some crossover with BLM 16*16+X: view 4 trigger layers of a single track at once, with the last button press choosing the displayed layer. So a trigger performance matrix.

So, there's three ideas for modes: menu, BLM and TPM. 

Edited by latigid on
Link to comment
Share on other sites

2 hours ago, TK. said:
  • 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.

Trigger layer has a GP button, mute has a dedicated button. Do they need "extra" ones?

Link to comment
Share on other sites

12 hours ago, latigid on said:

Well, we could consider an encoder that scans through and illuminates the 4th row ;-) 

The same way how the MB808 UI is working.
Please believe me, the encoder usage for track selection wasn't a good idea, I wouldn't do this again...

Quote

these buttons are essentially the four track groups, no?

No, the BLM buttons have to switch between BLM sections, and the purpose of a section depends on the BLM mode.
If BLM displays the gates of a track, the BLM buttons would switch between track groups.
If BLM displays a drum grid, the BLM buttons would switch between trigger layer (resp. drum instrument) sections
etc...

Quote

If tracks were handled on an encoder, then in BLM mode an encoder could scroll through the groups, even using lower resolution if too waggly.

You could use the jogwheel for this purpose.
The function of the datawheel is already configurable, press&hold EDIT, push GP7 to switch between the functions.
Additional functions could be assigned to the jogwheel in future.

Quote

Can we think about modes a bit more? At the moment, GP buttons are used to trigger steps on the selected layer of a track. Will this be retained, or are triggers only actioned in BLM mode? If the latter, then this allows the menus to be accessed without pressing MENU first. 

You are right, that this topic needs more planning.

Some functions that I "brainstormed" yesterday might be redundant, such as the mute button that you pointed out.

Trigger steps are selectable in BLM drum grid mode - again a conflict with your "TPM", an additional handling could lead to too much confusion.

I would prefer the following approach:

- show different layout options (how many buttons could be added to the jogwheel section)
- then we've to start to write a specification for button assignments and usage, this could be done in the Wiki

The only way to get a "big picture" and to work out the details to find the best layout.

Best Regards, Thorsten.

Link to comment
Share on other sites

About the track selection, if you were to compare to the Korg Electribes, on the older generations, each "part", the equivalent to the seq's tracks, had its own button, the newest generation replaced those with left/right buttons, definitely a step back for the UI.

What would actually be the use of the jog wheel and shuttle? After all, this is still primarily a loop-based step sequencer, is anybody actually making such long patterns? Even a 256 step pattern is only 16 "screens", so the detented data wheel is, methinks, well fast enough (and indicating each step with a clip) to navigate it. And there is also the track overview function. Data Wheel off to one side (left handed option would be welcome here!) plus extra buttons above / below it for Transport (incl. Record!), Mute, and more "performance features" like Repeat, Length / Clock Divider / Delay Trigger (maybe looping the selected steps / changing divisions just while some button is being held down?). The 4-row matrix and improved tactility would really open up possibilities for more performance-oriented playing of the sequencer, eg you could have mode where four different preset delay patterns are triggerable for each track on one layout page - with visual feedback on the RGB buttons. At the moment, the one area of the control paradigm that I find a bit limiting is that you cannot perform different actions to multiple tracks at the same time.

Link to comment
Share on other sites

After a lot of thought and private discussion with TK., it will be difficult to realise a new SEQ front panel in the given form. The initial concept started very simple and has morphed into something much bigger. 

The main problem is the new hardware options will significantly change the handling and software. All new ideas sound great, but someone has to code them, and support bug fixes/new feature requests. I am unable to do so, and TK. has indicated he won't have time. So we have a choice: either fork the current software with new options (i.e. SEQ v5), or work within the constraints with some hardware improvements. 

Assuming nobody wants to step up to take on the coding, a "take one step back" approach could have a 16*3 Matias matrix, with "duo" LEDs for the GP buttons, single colour otherwise, and jog wheel + group/track/layer buttons (+ other suggestions?).

16*3 keeps with the current, adding 4 buttons which are relegendable anyway. So you can give the F1/2/3 buttons dedicated labels too. The keyswitches are nicer, and the panel is simpler. I would need to check, but it's likely the front PCB would be amenable to panel mounting = much simpler case/mechanical design.

I'm sorry to those expecting a 16*4 RGBLM for Christmas...

 

 

Edited by latigid on
  • Like 1
Link to comment
Share on other sites

Just now, Smithy said:

I guess a redeveloped SEQ with an emphasis on Live Looping is out of the question then! ;)

I think we need to recruit / hire more developers who don't mind working for free!

 

Hmm, well that's what @Hawkeye's LoopA is supposed to do, but then there's already the MidiREX 

https://midisizer.com/midirex/


 

 

Link to comment
Share on other sites

17 minutes ago, latigid on said:

 

Hmm, well that's what @Hawkeye's LoopA is supposed to do, but then there's already the MidiREX 

https://midisizer.com/midirex/


 

 

Yeah, i cant seem to find any demo videos of the MIDIRex to see exactly how it works though.

I'm going to have start my own thread on a dream looper / sequencer. I'm thinking of something like the Kaoss Pad 3 style interface, but for MIDI instead of audio.

Essentially an encoder used to set the pattern length (which can be done live during playback)  and a numeric LED display, (or LCD Display) indicating the length of the pattern.

There could also be an option to manually stop / end the pattern by pressing a button, like the Boss RC-505 and have it automatically trim the length based on the MIDI data.

I seriously need to get this out of my head, even if no one develops it!

I find the fact you have to pre-initialise tracks on the MB-SEQ a bit of a short coming, then again I don't have one to critique! Im sure it makes up for it in the amount of features packed in.

Edited by Smithy
Link to comment
Share on other sites

 

@SmithyI have a MidiREX. Happy to answer any questions on it. Or state your looper desires and I'll tell you how well it fits (or doesn't). It's a pretty basic box overall though and maybe only slightly more capable than Hawkeye's LoopA.

On your comment on the Midibox. I don't use it as a generic looper all the time. I use it for song composition as well so there's some design tension there between two quite different workflows.

Edited by mongrol
Link to comment
Share on other sites

@latigid on fantastic design work, once again, mate! But you are right, it makes sense to see what is possible with the limited time resources all around, at the moment, aka let's grab the low hanging fruits! :-). Or you could learn to code for yourself, it really is not soo difficult and the MBSEQv4 code base is really well documented and understandable! I've had to do some tech analysis of commercial companies codebases during the last month, travelling around europe and you would not believe what I've seen there, and these guys were applying for a lot of cash to go on with that sh..., whereas here we have gold nuggets... :-)

@Smithy despite me not having time for much right now, a lot of ideas are on the list for the MBLoopA and i still hope to convince Andy to create a PCB for it. Right now, i have to finish another build first, but let's talk afterwards!

@Antichambre hehe, true! Cloning TK. would be the solution! :-)

Have a great time!

Peter

 

Link to comment
Share on other sites

 

47 minutes ago, mongrol said:

On the coding aspect, what's the license for the SEQv4 code? and does TK accept patches? I never seem to see people submitting any.

Anyone can download the code base, tweak and recompile. I know TK uses  code input from forum members in certain occasions, not only feature requests.  I guess the code goes under the same license as the hardware ?

Link to comment
Share on other sites

Hi guys,

 

hope I'm not late into party.

Really nice upgrade project and I would be more then happy to help to design a case for this beast.

Tbh I always wanted to make a case for MidiBox project.

Will dig more into details in upcoming week and shoot some questions and suggestions. 

  • Like 2
Link to comment
Share on other sites

18 hours ago, EsotericLabs said:

 

Anyone can download the code base, tweak and recompile. I know TK uses  code input from forum members in certain occasions, not only feature requests.  I guess the code goes under the same license as the hardware ?

Found the license under the MIOS32 "Software Architecture" section on ucapps.

 

License: Personal non-commercial use only

Personal non-commercial use only

 

Link to comment
Share on other sites

11 hours ago, AdrianH said:

Hi guys,

 

hope I'm not late into party.

Really nice upgrade project and I would be more then happy to help to design a case for this beast.

Tbh I always wanted to make a case for MidiBox project.

Will dig more into details in upcoming week and shoot some questions and suggestions. 

This is a great idea. 

Ive got some of the cases Adrian has designed/made for Mutable Instrumens products and can vouch for the quality and value. Adrian already has a strong track record so should be taken seriously. 

Link to comment
Share on other sites

Hi,

just to make it clear: not so much will change, I will continue the support and development like in the last 2..3 years, means: with ca. 20 days per year.
But I will focus this instead of introducing new MIDIbox projects or forking existing HW/SW projects by myself.

The license might also be more relaxed in future, but this will be announced in a separate thread in some days (please no discussion in this thread, it's too early)

I continued the discussion about a new MBSEQ frontpanel with Andy today, be prepared for a great new solution - no, there won't be an integrated BLM4x16, but the frontpanel will look fresh and useful :) 

Best Regards, Thorsten.

Link to comment
Share on other sites

3 hours ago, TK. said:

Hi,

just to make it clear: not so much will change, I will continue the support and development like in the last 2..3 years, means: with ca. 20 days per year.
But I will focus this instead of introducing new MIDIbox projects or forking existing HW/SW projects by myself.

The license might also be more relaxed in future, but this will be announced in a separate thread in some days (please no discussion in this thread, it's too early)

I continued the discussion about a new MBSEQ frontpanel with Andy today, be prepared for a great new solution - no, there won't be an integrated BLM4x16, but the frontpanel will look fresh and useful :) 

Best Regards, Thorsten.

This is such great news! Thank you.

Link to comment
Share on other sites

  • 2 weeks later...

Current state:

07-01-1.thumb.PNG.327182997df1237effa6c2

 

07-01-2.thumb.PNG.3b954b500a1e77cbdf1ef5

 

Excuse the lame font and generic/misaligned labels!

This one has fewer switches, but more switches. The idea is to use the first row of keyswitches as "soft" buttons, or General Purpose like in Wilba's. The second row of large switches are for 16 "selection" buttons. This row will change function depending on the state of the 8 buttons around the datawheel. Here you will select the track, parameter layer, trigger layer, mutes etc. As you have 16 buttons, multiple selections (esp. tracks!) can be selected at the same time.  I think it can be done that if the selection button is held down, the datawheel can scroll through 1-16 of that function. On the right, the buttons below the wheel are for transport, record, live, loop etc. The smaller buttons running along the bottom edge are editing commands like copy, paste etc. and edit, menu, pattern, song, utility and so on.

There's a front-mounted microSD card slot and by request a beat LED.

TK. will be disappointed that the bottom row are labelled on the underside, but the (rough) panel cutout dictates this, plus the association is clearer that the round rather than the squarish buttons perform these functions. 

 

This is a rough sketch of the power/USB entry:

07-01-3.thumb.PNG.a7a4f9690ac619f441e175

Power switch, USB B for computer and power, USB A for OTG host (here rather connect the B port to a powered hub), and a switch to select for OTG. This way you could still perform updates over USB even if the primary use was as a host. Some sort of USB cable will then connect to the Core located somewhere in the middle. I thought to add a 3.5mm jack (or maybe 1/4") for a footswitch (via a buffer) and wire this to the datawheel board, let's see.

Adrian brought up a point of switching the data and power lines, and thinking about it I don't think it's wise to have a power switch, because USB normally relies on connecting the power before the data. So is it a problem to use your master USB hub or wall switch instead? Otherwise something like this can be considered, although it seems a lot of effort:

http://mcs.uwsuper.edu/sb/Electronics/USBswitch/

 

The DB-25 + PCB is the MBHP Line Driver.

 

Apart from testing switches and keycaps, and routing up the main PCBs, the next question is MIDI IO. There is space for 16 DINs, but apparently it's inadvisable to use 8 MIDI ports on the same I2C buss. Instead, what's the chance of using the STM32F4 Core's second I2C? Or do we say 4 I, 4 O and 4 I2C outs are enough? There'll be provision to connect the BLM 16*16, maybe other goodies.

I'm intrigued by KissBox OEM, but the PCB takes up too much panel to be accommodated here. If it was as wide as the RJ45 socket it'd be a contender!

 

 

 

Edited by latigid on
Link to comment
Share on other sites

Now you've got me confused: apart from rearranging the buttons (and exchanging the button types), what is it that makes this a SEQ v4+, in the sense of the "plus" featuring something that cannot be had with the regular v4 version? The operation scheme seems pretty much identical to what we already know, doesn't it?

Link to comment
Share on other sites

Just now, ilmenator said:

Now you've got me confused: apart from rearranging the buttons (and exchanging the button types), what is it that makes this a SEQ v4+, in the sense of the "plus" featuring something that cannot be had with the regular v4 version? The operation scheme seems pretty much identical to what we already know, doesn't it?

It will run on an STM32F4, TK.'s label not mine. 

The operation will barely be different from the Wilba model, apart from having better quality and more refined button functions (as the usage has evolved since 2008), and also the new concept of a selection row. This is the trade off for not making something drastically different, that needs development time TK. can't provide.

 

 

 

Here's a lefty model:

08-07-lefty.thumb.PNG.a44f82eb7d79ddc081

 

Link to comment
Share on other sites

I think that the new "selection button row" consisting of 16 buttons and duo-colour LEDs will be a big + :)

The 8 buttons around the datawheel allow to assign a function to this row.
The functions are:

  • Step View
  • Tracks
  • Parameter Layer
  • Trigger Layer
  • (Drum) Instrument
  • Track Mute (and evtl. Track Solo)
  • Bookmark
  • Song Phrase

Especially for the first 5 functions will improve manual editing flow, having all 16 views/tracks/layers/instruments selectable in a dedicated button row should speed up switching.

Here another picture which shows the function assignments to the new buttons:

mbseqv4newfp4.thumb.png.21cff0f840feb969

Feedback welcome!

Best Regards, Thorsten.

 

 

Link to comment
Share on other sites

3 hours ago, TK. said:

Feedback welcome!
 

Congrats! I like it a lot, it looks clean and very structured, a nice successor to the V4 layout! 

Also, it is good, that people can continue using the old frontpanels, as lots of time and money has been invested on these. Legacy users might profit from new functions, even if not the newest user interface is in use.

Many greetings and a great new year 2017! :-)

Peter

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...