More than 8 pages, please?

I’m running short on pages on the E1 Mini, now that I’m developing a preset for the Korg DS-8 and Matrix-1000. Would 12 or 16 be possible? Thanks!

And given that we cannot create controls, we can only repurpose existing controls, extra pages give us more controls to pull from.

Not a blocker for me though … and I’ve had good luck just moving a few controls from page to page when navigating and customizing the control for the page’s need.

@FrankieMachine It’s not as convenient, but it’s likely you can use controls that tie to virtual devices that you then change to emulate a page change. That is, can a single page be reconfigured to serve multiple purposes.

My guess is memory is not an issue on the Mini, but if it is, perhaps this is a device level setting for number of pages. That would complicate the editor and sharing of presets…

So far I could just about fit everything into 8 pages, but now that I’m making a preset for the DS-8 I could use 2 more pages.

I’m not familiair with virtual devices, I only use the web UI. I like to keep it simple and focus my time on sound design (and who know, someday, maybe even make some music again).

Have this same problem already. I wanted to made really big preset, and structure of roland jv2080, give me possible to separate it to the 3 modes, one for rythm, withone have 5 pages, one for performance, where i have everything fitted to all 8 pages to the limit, and one for patch, where i use dynamic controls, and can’t fit it into 8 pages. I need like 4 pages more i think for rest of the parameters.
I’m thinking about making one more preset for Patch mode, but i’m not sure, if they will be pinned, the functions in lua code will hear eachother. Like, if i have in preset A some controls turned on, to edit one tone, then preset B will know, what tone are edited to send properly informations? Can it will be defined in Lua code? I really don’t know, how to bite it.
I was trying with hidden controls, changing names of controls, and it make it only worse, i need more pages to make it clear and functional.

1 Like

Just my opinion, but if a machine needs tons of pages, maybe the Electra One is not the best option for a controller.

Computer editor plus Electra One for hands on control of key params might be the better approach.

Again, I love the Electra One for many things (I have 3), but there are limits

2 Likes

I dissagree: a few more pages could release the E1 Mini’s full potential. But I hear an update is coming up, so I keep my fingers crossed.

1 Like

I hate to use computer to make music and don’t even close to utilize half of potential of this hardware. I think, more limits are in firmwire right now. Some functions are really good, some making problems (or just have too small knowledge), but placement of controls are one of the most annoying thing in electra mini. I was thinking about to use blank pages from bigger version of preset, but it was problematic too, and never get answer it is posible. Theoretically wanted to make more pages with button withone when pressed, hide all the page from electra one mini, and place it on electra one 6x6 page, and taking other controls from 6x6 page, and setting it on actual electra one mini page. It was never working, and i give up with trying that.

I respectfully disagree.

I’m actually dreaming of more pages for my MK2, because I’ve reached the limitations of the 12 pages several times for different reasons being:

  • That the device I’d like to control has simply too much parameters, but I’d really like to have the full set of parameters immediately reachable. I think that is really one of the goals of the E1.
  • That I often use some slots for fast lua navigation between pages (so much faster and more convenient that using the pages menu and the buttons). Actually the big rubber buttons are what I like the least on the electra one and displaying the thin pages menu on the top of the screen does’t work for me. But using slots for navigation purposes consumes a lot of them.
  • That some slots can be consumed by hidden controls,to register values from incoming patch sysex to be then converted to the corresponding controls, which do not represent the value the same way as in the patch sysex (for example 0;1 to 0;127). There’s certainly room for improvement via lua for this, but it will be harder to implement for people like me.

It also often limits the possibilities to set up the controls in a consistent, clearly laid out and logical way, because everything is crowded.

Limitations of the pages on my E1 mini doesn’t bother me much because I’ve also got the MK2 and I use my Mini for simpler tasks, but I can well imagine that it can be frustrating for someone that “only” has a mini.

I must also say that, despite those limitations, the MK2 and the Mini are absolutely wonderful devices. :slight_smile:

2 Likes

Reading the thread, the interesting detail is that several of you aren’t really short of pages for parameters - slots are being eaten by navigation controls and by hidden controls used to catch incoming sysex. If that’s the common pattern, then two smaller changes would relieve most of the pressure without a page-count bump: hidden/utility controls not counting against the visible slot budget, and a lighter way to jump pages than dedicating real controls to it. On the practical side, oldgearguy’s point about a computer editor for the full parameter set plus the E1 for hands-on control is the split I’d land on for something like a DS-8 or Matrix-1000, since immediate access to every parameter stops being a win once you’re hunting across 12 pages anyway. Grouping by function (osc / filter / env / mod / patch admin) and accepting that the rarely-touched stuff lives in the editor keeps the layout readable, which was the other complaint here. If more pages do arrive, a page-name strip that’s actually legible matters as much as the count - eight unlabelled pages is already hard to navigate live. Curious whether the sysex-catching use case could be handled in Lua without consuming controls at all; that seems like the highest-value fix in this list.

1 Like

Adding to that, I’ve managed to fit all DS-8 functions within 8 pages: Electra One App (excluding patch naming/parsing). I also managed to fit the most used M-1000 parameters within 8 pages ( Electra One App ), with exception of the mod-matrix. I’m considering making a seperate M-1000 preset for this.

Thus so far, I’m good, but more envelopes would be my main improvement request, which could help building larger presets that definitely wouldn’t fit within 8 pages - like the JX-10 with Vecoven I’m considering. And if the XY-pad could be improved (check my request), Cutoff and Resonance could be combined too within a single, unfolding parameter, freeing up more space.

Just thinking out loud, LFO’s might also be suited for a single, unfolding parameter: most LFO’s have functions like waveshape, speed, delay in common.

All in all: more unfolding parameters would be more valuable to me (and probably other E1 users as well) than more pages.

@martin , I hope you don’t mind me including you in this discussion.

Thanks.

1 Like

my current work already includes:

  1. pot switches on mini will be available to have a Pad style control assigned, basically as @hape requested here: Electra One Mini | Some wishes for a future update . ie. increasing number of pad controls

  2. the System button in the Menu will be replaced (and buttons reordered) with a new “Page Set” toggle allowing to switch between two sets of 8 pages on the Mini. The System screen will get more complicated way of accessing (most likely long press of the Menu button). ie. twice as much pages. It feels like a better use of HW buttons, the System screen is hardly ever needed in day-to-day use. This is still work-in-progress.

6 Likes

FWIW, I’ve never had to use separate controls to handle sysex. All of my editors receive the patch dump, parse it all out to the parameter map and then virtual controls plus Lua do the additional work.

Not sure if the current approach is due to AI suggestions, or maybe because folks are not experienced in Lua?

Suggestion is always to take a look at the work that’s come before you and to learn and improve on that.

EDIT -

Look, creating a useful editor for complex gear is hard. I know that. However, turning the E1 into a spreadsheet with knobs by creating 12 pages with 36 controls on each is not the best approach.

However, sometimes that method is needed to get everything there.

Normally, you would use colors, logical groupings on a page, groups(boxes) within a page, different control styles, labels, and so on to help a user navigate quickly. The days of having muscle memory and editing a MiniMoog with your eyes closed are not obtainable (for the most part).

There is a tendency (for synths) to put all oscillators on a page, all filter stuff on another, and so on. In general, I did that with the Micron and microWave and XT. Looking back, that may not always be best. If I did another, I might have the main page display the most commonly edited params for a synth with buttons in each section to jump to a ‘deeper dive’ page with all the parameters for that section.

Again - this mini-rant is not meant to discourage, but to maybe have folks sit down with pen and paper (or iPad or whatever) and sketch out a flow first and try different grouping and pages. I can’t even begin to count the number of different iterations I did in an Excel spreadsheet for the LP-1, PCM 70, 80 and others. Even then, getting the flow right for me maybe didn’t line up 100% with others ideas, so tweaks were still being made after the first release.

6 Likes

FrankieMachine, that is a useful data point: if a full DS-8 fits in eight pages and the M-1000 only overflows on the mod matrix, then the real constraint is density per page rather than page count, which supports your unfolding-parameter argument over a bigger page budget. The mod matrix is also the clearest case for it, since a matrix is inherently a grid of small values that nobody wants spread across a whole page. On layout, one approach that has worked for me with multi-timbral or matrix-heavy gear is a shared overlay page: keep one page whose meaning changes depending on which section you last touched, so the matrix or the LFO detail unfolds into the same physical controls rather than each getting permanent real estate. It costs you a mental mode but buys back a lot of slots. The per-synth banks route is cleaner if you switch instruments often, but it means duplicating the pages you always want visible. Martin, the Page Set toggle on the Mini sounds like the pragmatic answer for people who genuinely do need more than eight, especially since the System screen is rarely touched live. Worth asking whether the page-name strip stays legible once there are two sets, because switching blind between sixteen pages is where the navigation cost really lands.

3 Likes

How about 3 different presets?

All for the JV2080 but split up and easily accessed with the touch of a button or two.

Would love to see your JV2080 preset!

1 Like

Woah, i have 4 preset’s already to make it work.
It’s no problem for rythm and performance mode, where everything is separated.
But patch mode is already separated to common and effects(in future) and tone matrix edit, if You seperate tones, then other preset, don’t know which one tones are edited or viewed. So tones are now in one preset, where i fit everything to max.
It will make problem in nearly future, because i need to create additional option.

If You use performance mode, You can edit Rythm on 10 part live, with sysex, You just edit rythm mode with this same adresses, so it’s simply. But every other part is defined by patch.
If You change mode from patch edit, to performance mode, You can also edit patches in individual parts via sysex, but adress is other than patch mode, it’s defined by part You want to edit.

So i need to create controls to define with one mode is selected, Patch, or Performance (From 1 to 9 parts, or 11 to 16).
That will change ALL of adresses for common patch and tone patch presets. It will give 15 aditional adresses for every parameter according to part You select. But if You select it only on common patch preset, or only in tone preset, there will be no communication between these preset’s.

Only way right now to solve that, is copy that one options to both presets, and make external CC mapping for it with this same command. If You send this same CC command, to both pinned preset’s there should change it same. That’s theory right now. I have no idea it will work, but i wouldn’t have to check this, if i will have more space on pages, to fit common and tones section in one preset…so, for me, making adittional space would be great.

I will end it some day. Maybe, if my miserable life lasts long enough… for last ~six months i ended something around 70% of all options, what should be there, for totally live action setup… it’s draining my life out of me, but there’s not much to drain off, so whatever XD I’m totally fascinated with that sounds, and it holds me in one piece. I ended up like freak.

1 Like

That split between performance mode and patch mode sounds like the right boundary: keep the live rhythm controls in one performance page, then leave tone-specific SysEx on separate pages so each part has a stable address. For a practice session I also like running a simple, steady audio bed separately from the controller, so the E1 stays focused on the hands-on changes. I’ve been using this frequency app for that. It’s free, and I just treat it as a listening timer/bed rather than another layer of preset logic.