MIDIbox SEQ V4 Wishlist

[moroe]

The live editing step sequencer concept requires static data structures stored in RAM.

Let's say, each track would offer 16 layers with 128 steps, this would lead to a memory consumption of 2k for each track, and 32k for 16 tracks

But the planned processor offers only 20k RAM (update: 64k RAM, 512k flash cost US $4 more - we will take this one)

Another issue: storing 32k on SD Card would lead to unwanted latencies on pattern changes, regardless how much RAM is available

But a 4th layer makes sense (I'm missing it as well)

hello thorsten

would it be possible to get more layers if we only use 64 or 32 steps ?

is the memory organisation hardcoded or a dynamically ?

if its hardcoded maybe you could release 2 versions of seq v4 and users can decide which one they will burn on their pic

there would be 2 versions then: one with only 32 or 64 steps and more layers (bigger chords, more controlers, step shift..) and the one with 128 steps and fewer layers.

just an idea

moroe

[sphere42]

That's efing awesome!!

I vote for more steps. 128 would be nice, but I would like to have 256 steps at least That's 16 bars.

Or 512 step (32 BARS OH MY GOD)

:D

I know, I know, more steps, more work but also more fun and more randomized patterns ;)

[TK.]

Some words about the progress: meanwhile the infrastructure (MIOS32) is available and running stable.

I started to rewrite the MBSEQ application completely in C.

My plan is to implement a MBSEQ V3 equivalent first (so that I'm able to compare the performance, code size, etc.. with the old implementation), before continuing with new V4 functions.

But in background new concepts are already in use. E.g., the timestamped MIDI events, a generic MIDI port interface, different task/interrupt priorities to simplify multitasking, abstract hardware layer to allow accurate realtime emulation on a Mac, later maybe also for other operating systems (if implemented by anybody else)

E.g., it's already possible to play tracks in Master and Slave mode.

The Mac based emulation can sync to the real hardware, and vice versa - there is no better test to check the robustness :)

Meanwhile I've also a better feeling about the new possibilities of the STM32F103RE controller (which only costs. ca. US $15 btw.) and can give you some answers to your feature requests:

• Integrated Sampler: no - although I was already able to generate a stereo waveform through a I2S audio DAC at 48kHz, this task loads the CPU so much, that the sequencer wouldn't run stable anymore. Use an external sampler, or your PC (which allows more comfortable editing)
  
• Touch screen: feasible, but expensive hardware and high programming effort.
  
• Different sequences of different length at the same time: already possible since MBSEQ V1, MBSEQ V4 will support a configurable number of steps which is only limited by the pattern memory (more than 1024 steps per track is feasible!)
  
• Number of layers: configurable, only pattern memory will limit the number of parameter layers, more than 16 layers per track is feasible
  
• Number of tracks: at least 32, maybe more. There will be a separation between drum and synth tracks to save memory usage. The user interface will behave different if a drum track is selected - in other words: on a drum track, it will behave like MB-808 (e.g. it will provide A/B/C/D sections), on a synth track like MBSEQ V3
  
• loading more than 4 tracks into ram: since MBSEQ V3 all tracks are in RAM and directly editable, this won't change in MBSEQ V4. Only MIDI files will be directly played from SD Card, and are only editable by importing/exporting the file. However, main focus is a live sequencer (playing .mid files is only an add-on), and this won't change.
  
• DMX output: feasible with external IIC device
  
• SEQ scratching: available since MBSEQ V2 via "Scrub" button, but worked only in forward direction. MBSEQ V4 will support backward direction as well.
  
• Bigger LCDs/graphical LCDs: feasible, but not in my focus (e.g. I don't want to buy expensive hardware and spend hours in programming just to satisfy requests which are not interesting for myself). However, thanks to the C implementation and different API layers, anybody else could provide such an option later
  
• MIDI over LAN: MIOS32 will support an TCP/IP layer (in future). The MIDI layer allows to send MIDI event packages to the TCP/IP layer... accordingly MIDI over LAN will be feasible. Even WIFI will be possible, although you won't like the latency
  
• Layer to vary the time intervals between the steps: will be part of the new integrated groovestyle editor
  
• Midi processors for internal routing... with midi fx... LFOs and midi filters....: thanks to the new timestamp concept: feasible w/o much effort
  
• More random stuff... rotate....skip closed gates ... random move active gates selected and or random chance by percent: feasible, as number of trigger layers will be enhanced as well (only limited by pattern memory)
  
• Nameable drum maps: feasible
  
• Integrated Mackie Control emulation: feasible (a C based demonstrator which runs on MBSEQ already exists for PIC, there is enough flash memory free to install this application in STM32 as well, so that no additional code upload will be required)
  
• Midi sync. delay calibration.. Clock sync delay in ms... from say -30 ms to +30 ms: positive delays are feasible thanks to the new timestamping concept. For negative delays, just compensate the delay on your other sequencers.
  
• enhanced mixer functions: feasible (also in conjunction with MIDI Fx)
  
• Support for 16 motorfaders or "Stribes": feasible, although I think that Phattlines additional ideas should be implemented by somebody else (high programming effort)
  
• Tempo track: feasible
  
• Button/LED matrix with more LEDs/Buttons: feasible, e.g. 64x64 = 4096 LEDs/buttons shouldn't be a problem if you find place for such a monster
  
• Animation on the matrix display, like tenori-on?: open source allows you to integrate such functions
  
• MIDI Fx: Delay, feedback velocity, feedback note, feedback gate time, feedback clock: feasible
  
• MIDI Fx: CC LFO and ADSR: feasible
  
• Access to button/encoder functions via CC/SysEx, so that external MIDI controllers can enhance the CS: it's just an enhancement of the exising MIDI remote concept, therefore feasible
  
• REC Monitor: already available in MBSEQ V3
  
• why not implement a sort of korgs KARMA  or things from the LATRONIC NOTRON sequencer: feasible, but very high programming effort
  
• Possibility for more IIC MIDI: feasible, but not really useful as discussed earlier. MIOS32 supports up to 8 IIC_MIDI modules
  
• Recording start message when the sequencer starts and a recording stop message when the sequencer stops: MIDI clock start/stop will do this job - already available since MBSEQ V1
  
• Is it possible to make a one shot pattern with MBSEQ V4: feasible
  
• would also like to have a option to sample each note after another from a synth, like this software does: if a software already exists, I don't see the need for re-inventing the wheel (in which menu should such a feature be burried...? and who would really use it?)
  
• is the memory organisation hardcoded or a dynamically?: it's dynamic and configurable
  
• Or 512 step (32 BARS OH MY GOD): as mentioned earlier, number of steps is only limited by available SRAM. E.g., a drum track could consist of more than 100000 steps if you don't play any other track ;)
  

Btw.: the word "feasible" doesn't mean, that I commited to integrate requests into the firmware by myself...

Best Regards, Thorsten.

[moroe]

wow these are really great news !!!!!!!!

i really enjoy your big amount of feedback on the forum.

please could you give a statement about this:

you mentioned a sysex patch send option in the announcement of V4.

this would be awesome.

hope that you also implement a sysex patch record funktion for synths.

i saw that the Midibox UC is able to request the synthesizer's edit buffer, maybe you can use some of his code

imagine that you only have to press a "gather all settings from synths" button

and all connected hardware is sending their patches to the sequencer for saving as a whole project !!!!!!

maybe only as a recording function where you have to enable sysex sending at the synths manually one after another

but the sequence data and the synth patch data should be stored together as a whole project file.

also needed would be a seperate preset library for synths where you can send, request and store presets seperately for each synth

i really would like to have a total recall hardware studio without pc.

just some ideas

moroe

[TK.]

you mentioned a sysex patch send option in the announcement of V4.

this would be awesome.

hope that you also implement a sysex patch record funktion for synths.

I like this idea, as I see the need for my own synths as well - therefore you can be sure that a powerful solution will be available - sooner or later :)

I guess, that it is acceptible if SysEx request strings are stored in a .txt file on SD Card? Which means, that I don't need to provide editing capabilities - just create a .txt file which defines the parameters of your synth, store it on the SD card, and load the file into MBSEQ. Thereafter the predefined SysEx request strings can be sent from a special page, and received SysEx data can be recorded and stored on SD Card into a special library directory.

Which means: you would also be able to maintain the library with your PC (e.g. for backup reasons, or to copy a large bulk of already existing .syx files)

Best Regards, Thorsten.

[TK.]

Picture of a MBHP_CORE_STM32 module (layouted by Nils) behind the MBSEQ frontpanel (layouted by Wilba):

[ilmenator]

I guess, that it is acceptible if SysEx request strings are stored in a .txt file on SD Card? Which means, that I don't need to provide editing capabilities - just create a .txt file which defines the parameters of your synth, store it on the SD card, and load the file into MBSEQ.

Could the file structure on the SD card kind of represent the SysEx (sub-)menu structure then? Say, I call a folder "Korg M1" and have two text files "Bank load", "Bank save" in them; then, in the SysEx strings menu I select "Korg M1" and can then subsequently choose between "Bank load" and "Bank save" (the text files) in that folder (which are executed immediately after selecting/loading them). I guess this would mean endless flexibility...  :P

Best regards, ilmenator

[sphere42]

Wow, nice news TK! And that picture, hmmm...

...tasty  8)

And as for my idea about 512 steps... well I don't think that's good idea as someone could find it too much to operate with.

But I was thinking about how to operate with such amount of bars, and I think 256 steps could be fine, because it's eaxctly 16 bars so you could operate with them with 16 general buttons (at least I think that's the name). Imagine how fast you could work with patterns. Copying / Pasting, zooming in sections.....

[TK.]

Could the file structure on the SD card kind of represent the SysEx (sub-)menu structure then? Say, I call a folder "Korg M1" and have two text files "Bank load", "Bank save" in them; then, in the SysEx strings menu I select "Korg M1" and can then subsequently choose between "Bank load" and "Bank save" (the text files) in that folder (which are executed immediately after selecting/loading them). I guess this would mean endless flexibility...  :P

So, you mean that each directory should contain a script with additional instructions - no problem :)

This would also force the user to sort patches into the correct subdirectories.

This could be the content of a file, located under /SysEx/MIDIboxSID

# configurable parameters (?1..?8)
# changable with GP encoders
?1 = Device
?2 = Bank
?3 = Patch

# request strings (the name shouldn't be longer than 40 characters)
:MIDIbox SID Edit Buffer
request = F0 00 00 7E 4B ?1 01 08 00 00 F7
subdir = Patches

:MIDIbox SID Patch
request = F0 00 00 7E 4B ?1 01 00 ?2 ?3 F7
subdir = Patches

:MIDIbox SID Ensemble Buffer
request = F0 00 00 7E 4B ?1 01 78 00 00 F7
subdir = Ensembles

:MIDIbox SID Ensemble
request = F0 00 00 7E 4B ?1 01 70 00 ?3 F7
subdir = Ensembles
[/code]
etc...
Best Regards, Thorsten.

[TK.]

And as for my idea about 512 steps... well I don't think that's good idea as someone could find it too much to operate with.

But I was thinking about how to operate with such amount of bars, and I think 256 steps could be fine, because it's eaxctly 16 bars so you could operate with them with 16 general buttons (at least I think that's the name). Imagine how fast you could work with patterns. Copying / Pasting, zooming in sections.....

You are right, so let's set 256 steps as limit.

And for parameter/trigger layers 16 maximum

Selection: press A or B button to select between the first and second layer (as before)

press C button to select 1 of 16 layers with GP buttons (LCDs will show the available layers + names)

Best Regards, Thorsten.

[ilmenator]

So, you mean that each directory should contain a script with additional instructions - no problem :)

This would also force the user to sort patches into the correct subdirectories.

Yes, I was originally thinking of one .txt file per SysEx instruction, but grouping SysEx instructions that belong to the same device is even better. GREAT!

Best regards, ilmenator

[moroe]

I like this idea, as I see the need for my own synths as well - therefore you can be sure that a powerful solution will be available - sooner or later :)

I guess, that it is acceptible if SysEx request strings are stored in a .txt file on SD Card? Which means, that I don't need to provide editing capabilities - just create a .txt file which defines the parameters of your synth, store it on the SD card, and load the file into MBSEQ. Thereafter the predefined SysEx request strings can be sent from a special page, and received SysEx data can be recorded and stored on SD Card into a special library directory.

Which means: you would also be able to maintain the library with your PC (e.g. for backup reasons, or to copy a large bulk of already existing .syx files)

incredible !!!

this will be the most professional step sequencer the world has ever seen.

there is no need to edit the patches inside the seq v4, a pc is really better for this.

could it be possible to step trough the patches on the sd card with  plus - minus buttons or a encoder and seq v4 will send them immediately ?

my digital camera will need a new 16 gb sd card when seq v4 arrives :)

best regards

moroe

[sphere42]

You are right, so let's set 256 steps as limit.

And for parameter/trigger layers 16 maximum

Selection: press A or B button to select between the first and second layer (as before)

press C button to select 1 of 16 layers with GP buttons (LCDs will show the available layers + names)

Best Regards, Thorsten.

You Sir, are pure Genius.

I'm going to wait for fourth version instead of building current version.

Thanks a lot Sir!!

[Echopraxia]

In regards to midi file import and export. When you say load a midi file into the seq will it assign all the midi tracks in the midi file to their repsective tracks on the MBSEQ? I know we want to keep this a LIVE sequencer but I thought it would be nice to make a song on the sequencer and record all the live action to PC sequencer and make edits on PC then be able to transfer song back to MBSEQ with new edits. Any thoughts? My thinking is for swaping between studio use and live use.

Were all rooting for you TK!

Regards,

Echopraxia

[moroe]

just another idea

i dont know if it would make sense, because there is portamento on each synth and the glide option in seq v3:

why not some sort of pitchbend envelope for each step ?

greets

moroe

[TK.]

Today I reached an important milestone in my "feasability study" (see initial posting)

Most of the MBSEQ V3 features are now implemented on C, they are running on STM32 and they are accurately emulated under MacOS.

The code size is currently 80kb, compared to 64kb PIC code of MBSEQ V3 this means, that the code density of the ARM Cortex M3 processor is almost equal for a real world application.

432kb flash memory is unusued yet - a lot of room for future enhancements!

It's possible to use 16 tracks with 256 steps, 4 parameter layers, 8 trigger layers. Paritioning is customizable, which means, we could also use 16 parameter layers with 64 steps (-> 4 measures) for polyphony in a single track. But this doesn't really load the STM32 chip, nothing speaks against the usage of 32 or 48 tracks (e.g. 32 additional tracks for percussions, which consume much less RAM than fullly featured tracks)

The most important thing - and this was the point which really scared me, as it required a lot of pre-work: loading a complete pattern from SD Card takes only 7 mS in worst case. And even if multiple patterns are loaded for different track groups in song mode, it won't affect the sequencer timings, as MBSEQ is now working with a MIDI event scheduler in a separate high priority task which ensures super stable timings while patterns are loaded or stored.

The sequencer is clocked at 384ppqn in master and slave mode, which is 16 times the normal 24ppqn MIDI clock resolution. I haven't noticed any robustness issues yet, but I must also say, that I haven't made songs with MBSEQV4 yet - programming this beast is too much fun! ;)

A MIDI file player is already implemented as well. It will be possible to import/export patterns via .mid files, as there is more than enough flash memory free for such features.

Due to the dramatically increased pattern size, BankSticks won't be supported anymore.

Instead a SD Card is required, which is much faster and more comfortable to use anyhow (e.g. for exchanging files, or to create backups)

The bank format is flexible enough to cover different track partitionings and future enhancements.

A bank consists of 64 patterns, and takes 368674 bytes. The number of available banks isn't really limited, so you can take different banks for different purposes (e.g. different banks for different MIDI devices and/or music styles), and sort your setup this way. All banks/patterns/tracks can be named with 20 characters.

Thanks to the new "freedom" in memory size/CPU speed and C language, certain features which seemed to be impossible for MBSEQ V3 were a really no-brainer for MBSEQ V4. Like the "Echo Fx", which was completely programmed in two hours, and worked almost immediately w/o much debugging effort...

... which brings me to the conclusion, that it cannot take so long until MBSEQ V4 is ready for an alpha release - for those who own a Mac: you will be able to try it out immediately. ;)

Status MBHP_CORE_STM32 module: I will get a second batch of 25 prototypes in ca. 2 weeks, they are already assigned to forum users with programmer status. It will be released if there are no errors anymore. Upload via MIDI is already possible, so that there is no need for a JTAG programmer, considered that somebody (like Smash) pre-programmed the chip. But there are also inexpensive solutions to program the bootloader with a common RS232 interface. Once this has been done, code can be uploaded via USB (which works btw. even faster than JTAG). More about this topic sooner or later in another article.

Best Regards, Thorsten.

[jimh54]

"Most of the MBSEQ V3 features are now implemented on C, they are running on STM32 and they are accurately emulated under MacOS."

Is Analog and gate outs one of the suported features left in? Perhaps not in the MacOS emulator but in the final build?

I'm trying to decide whether to wait for this or to go ahead with the MBSEQ 3.4 instead. I like all of the features of the V4 but I need analog.

[TK.]

Is Analog and gate outs one of the suported features left in? Perhaps not in the MacOS emulator but in the final build?

I'm trying to decide whether to wait for this or to go ahead with the MBSEQ 3.4 instead. I like all of the features of the V4 but I need analog.

You could use a PIC based MIDIbox CV, connected to a MIDI port (e.g. GM5 based)

However, keep in mind that the user interface of the emulated MBSEQ is not designed for computers. You can move encoders with the mousewheel, and click on the buttons with your mouse or with the keyboard - but the usage of a real MBSEQ will always be more intuitive and faster.

The purpose of the MacOS based emulation is mainly to provide a virtual prototype, which allows people to get a better understanding about the possibilities of a certain application before building a MIDIbox, to plan a customized frontpanel, and for programmers to debug an application w/o the need for ARM debugging tools.

I consider to provide a special MIDI remote function, which will allow a PIC based MBSEQ to control an emulated MBSEQ V4 for those who don't want to replace their core module by a MBHP_CORE_STM32 yet. The remote connection could also allow to control AOUTs and triggers. LCD output should be feasible as well. Even running it on a Windows or Linux PC should be possible this way w/o much effort at my side. But for myself it's a minor feature, therefore: low priority

Best Regards, Thorsten.

[jimh54]

I guess I did not make my question clear enough.

I do not care whether the emulator can be made to have analog outs.

I want to know if the final hardware build of MBSEQ V4 can have analog outs like the MBSEQ V3.4 can. (with an Aout board connected).

I assume that analog can be added, to V4 but need to know for sure before I commit to building the MBSEQ V4 as opposed to building the MBSEQ 3.4 instead.

However, Thanks for the information on how to add analog outs to the emulator if one needs to do that.

[TK.]

Oh, the answer to this question was too obvious: of course, all AOUT modules will be supported. It will even be possible to chain the modules in order to enhance the number of channels.

Best Regards, Thorsten.

[jimh54]

Awesome!!! I'll be anxiously waiting for the final release. thanks.

[julienvoirin]

"Most of the MBSEQ V3 features are now implemented on C, they are running on STM32 and they are accurately emulated under MacOS."

OMG ! you rock TK :)

[jimh54]

I have a couple of new questions. The new core board will obviously not have the infamous Eusart bug that prevented Midi from functioning correctly.

1) Does this mean that only iic midi out boards would be necessary since the new core should provide for 1 Midi in/out?

2) Could one perhaps use a gm5 board to provide the same function in place of the iic midi outs?

thanks

[seppoman]

1) Does this mean that only iic midi out boards would be necessary since the new core should provide for 1 Midi in/out?

Core32 will provide two Midi ins and outs. I guess if that should not be sufficient you could expand that via 2c modules.

2) Could one perhaps use a gm5 board to provide the same function in place of the iic midi outs?

no. The gm5 is a regular PC midi interface just like e.g. a M-Audio MidiSport, only DIY, cheaper and even better...

S

[napierzaza]

I was thinking of something like having two shift keys. They'd shift the entire matrix right or down and lock, so you can very quickly switch over to the next for tracks of the matrix or the next group of columns. They'd work like a caps lock so you can easily edit that section (you could have it function as a toggle, or even maybe just install a nice looking toggle switch for it to lock). It'd eve be cool to have 4 LEDs, and the active section would be the one that would light up for notification of where you are.

To clarify: This only really makes sense if you plan on building a 4x16 array for track control. So you could basically move around your instruments and your 128 steps easier. Now that I see how many tracks and steps though, maybe we need two knobs (yes like and etch-a-sketch) so navigate the matrix. Possibly using number display LEDs might be better than a matrix?

You should be able to have only one digit per direction. With 128 steps you get 8 shifts, and with 32 bars you have 8 different blocks vertically (assuming a 4x16 matrix).