Disclosure: I design and manufacture sequencers...
I can give you some lengthy details about my design decisions and why there are limitations like bar length.
This may be too long and too detailed, but it is a topic I have lived...
So, just looking at the idea that "memory is cheap".
From the hardware side:
A hardware sequencer design will need to choose a core processor to start with. In most cases, for a sequencer, this will be a microcontroller, not a desktop microprocessor.
There are many reasons to choose one vs the other, both from the hardware perspective and the software perspective.
Things have changed/blurred with very small form factor modules that use desktop class microprocessors, along with all of the supporting components, such as memory, GPU, thermal management, etc.
Many microcontrollers today are also getting more powerful with more features, and can rival desktop processors. You can read more about that here:
https://www.totalphase.com/blog/2019...e-differences/
or here:
https://predictabledesigns.com/micro...r-new-product/
Microcontrollers in general allow programming closer to the hardware, with great control over peripherals (serial MIDI, USB, UI, etc). This can give more control over critical aspects like timing, responsiveness, priority, etc.
If I choose a desktop class processor, the next question will be "Why not just write it in software and use existing hardware?" This could be an iPad, PC, whatever and you get an advanced OS for free. It reduces cost, risk and support.
Most musical device manufacturers can't compete with the features, cost and ubiquity of something like an iPad on the hardware side.
The other factor is overall cost. Microcontrollers are cheaper in most cases than a desktop processor. You can use a rule of thumb that the cost of a component can be multiplied by a minimum 2.5x to estimate the impact to the final price of the device. Here is a good overview of that rule of thumb, if you want to learn more:
https://www.youtube.com/watch?v=UwrkfHadeQQ
In most cases a device like a sequencer will use a microcontroller.
So, with more memory comes more heat, more power, more microcontroller I/O, more complex PCB layout... which creates more risk and more cost.
As an example, adding more memory could impact the following hardware:
- power supply
- power conversion
- heat dissapation, heat sinks, fans (!)
- PCB design, for traces, layers, impedance, timing, emissions, heat
- microcontroller, faster clock, more I/O for memory address and data lines
- additional supporting circuitry, muxes, caps, etc
- UI components, buttons, LEDs, display to make use of the memory
- the memory component itself, usually larger SDRAM
...and if you get any of these wrong during design, it is expensive to fix, or iterate on revisions of the hardware.
From the software side:
This may be an even bigger reason you don't see greater bar length in a step sequencer. To start with, it is important to think about the way data is stored in different types of sequencers. It was mentioned earlier, but the difference between a step sequencer and a list sequencer is crucial.
An overly simplistic way I like to think of this is the difference between Microsoft Word and Microsoft Excel.
If you think of Word as a list type sequencer, you just type as many words as you need and the memory usage is very compact. You don't really care about what happens "between the words". The sentence structure gives you the timing. In a list sequencer the timing is a timestamp on the event.
Now think of Excel as a step sequencer. In Excel you have a bunch of cells, that may or may not hold any data, but they still consume memory. The location of the cells give you the "timing".
Most of the older sequencers mentioned are list type sequencers which were limited by the total number of events, but they didn't give a lot of advanced non-linear step sequencing features.
In something like an MMT-8, two MIDI events consume only two memory "chunks", regardless of the timing. You could have one event at time zero, and another at time 3 minutes, it doesn't matter. The only difference is the timestamp values. In a step sequencer, more and more memory is consumed the farther away the two events are, there is a chunk of memory for each empty "step" between the two events.
So why would you want to make a step sequencer? As mentioned, a big reason is non-linear playback and performance features. Not just the rearrangement of large patterns, but playback directions, such as random playback, skipping of steps, etc.
At the step level, every new "capability" you add increases the memory consumed by each step, even if there is no active event data in the step. Things like per step parameter locks, step probability, step skip, ratcheting, microtiming, recalling a programmed pitch, etc. In a list based sequencer if you remove an event, it's gone. In a step sequencer, the pitch, velocity, length may still be there, they are just turned on or off. A simple detail like this has huge implications for memory usage, but may be desirable based on the focus of the device.
Getting into more of the gory details of the software (but still simplified), using a microcontroller, you may not have any operating system, or in some cases the OS is just a "scheduler". This means that the microcontroller is running the sequencer code directly. It also means there is no advanced memory management being performed (usually this is taken care of by the OS, or more advanced hardware). So the impact of this is that in general it isn't a good idea to use "dynamic allocation" of memory in the embedded microcontroller world. It leads to memory fragmentation that can't easily be defragmented because pointers to dynamically allocated objects could become invalid after defragmentation and the sequencer would crash. There are ways to mitigate this, such as only allocating, but never deallocating memory, or using a very large pool of items (events) and just taking or releasing these elements as needed.
Another side effect of using a lot of these "dynamic" approaches is that you start using memory pointers in a lot of places, which typically would be a 16 or 32-bit pointer, so this pointer must also be stored and increases the memory usage even more. You can read more about these ideas here:
https://barrgroup.com/embedded-syste...ory-allocation
The other (non-dynamic) approach is just to create a sufficiently large, but fixed sized array that is dedicated to a pattern, track, etc. This guarantees that you always have enough memory, but it can be quite wasteful because the memory for this array is consumed regardless of whether it is used to hold meaningful musical data.
This array based approach is a common method to handle memory in a step sequencer, and a main reason you have bar limitations.
In this case, memory may be better used to provide more tracks, more patterns instead of sitting unused in the (infrequent) case a greater number of bars is needed. The patterns are chained together by the musician if longer structures are needed, giving a sort of "dynamic" allocation of the available memory.
It is a tradeoff.
Another area I won't even get into is how the data can be permanently saved and restored into memory...
Of course the difference between list and step sequencing isn't that black and white, so there are many examples of blending some elements of both types into a single machine, both old and new. Usually there will be other tradeoffs to be made depending on what the main focus of the design is.
If you need to see examples of this in various current sequencers:
The Synthstrom Deluge seems to handle dynamic allocation of memory and provides arbitrary length patterns. I don't know what the current level of advanced step capabilities are on the Deluge.
The Cirklon gives you P3 patterns which are step type patterns and CK patterns which are list type patterns. So you have the option to choose the type of pattern.
In general, I would say trying to compete with a PC running a DAW is a losing battle for a hardware sequencer if you only look at sheer memory, display, speed, PPQN for the price, and just acting as a MIDI recorder and playback device. So the hardware sequencer needs to excel at what the PC can't do so easily, which is provide a tactile, performance oriented interface which embraces some of the limitations. It undoubtably leaves some musicians wanting more, bar length limitations is just one of the many things I get feedback on.
I didn't even cover the complexity of the other aspects of the hardware/software that have to be balanced along with something like number of bars! Think number of tracks, timing accuracy, quantization (or not)...