MIDIbox SEQ V4 Release + Feedback

[Hawkeye]

Here is a short demo video of the relative track position display:

The upper 8x4 LEDs of the matrix show the tracks 1-8, the dots "fall upward", every LED equals 25% of track length played.

The lower 8x4 LEDs of the matrix show the tracks 9-16, the dots "fall downward".

Muted tracks are not shown, so you can see at one glance, which tracks are currently unmuted and playing, even when you are not in the "mute" SEQ screen.

This video also shows the new 4-digit BPM indicator and the currently-played-step (of the currently active track) LED indicator.

All those features (BPM & step digits and the TPD matrix) fit on a DOUTx4 board (4 shift registers)... just make sure, that you use low-current LEDs, otherwise they might be too dim.

If you are interested, you should be able to add this to a "standard" Wilba SEQ, if you can add a DOUTx4 module to the serial register chain. I´ve cables over 50cm long running from the shift registers to the LED digits and LED matrix, so you could add this as an optional breakout box somewhere in your rig.

I hope to put on a better demo in a separate thread, when there is time for making some music...

Edit: now, there is a better demo and room for TPD discussion available here:

Thanks, TK.!

Greets,

Peter

Edited October 26, 2011 by Hawkeye

[jojjelito]

I think I need to add those displays to modular panel 2 right next to the modularized OLED Shruthi DCO/VCF. Darnit - there should be a design freeze one of them days

Well done Peter and Thorsten! I can haz schematix for dat?

Blinkenlichts finde ich sehr Gut!

Greets,

Johan

[Hawkeye]

Thanks, J!

Schem: wire the 8 pins of one DOUT shift register (with 220R resistors) to LED matrix cathodes, wire the 8 pins of another DOUT shift register (with bridges, no resistors) to the LED matrix anodes.

PS: tested the new dedicated bpm encoder function yesterday night as well and it works like a charm.. hands-on speed control, even when you´re e.g. in the mute menu :-)

Edited October 24, 2011 by Hawkeye

[jojjelito]

Yay!

Who would have thought it would be so easy to connect a BPM display plus the Nyanalyzer (it shows if you're making dubstep or being otherwise obnoxious) to the MB-SEQ?

Hawkeye: We can haz a photo tutorial - Big Pimpin the MB-SEQ?

/J

[Gridracer]

Sorry to report, but it seems that with V52 the MIDI in ports of the STM32 Core are not longer working:

-MIDI Messages will not be recognized recorded or forwarded by the SEQ

-No respond to the query Function of MIOS Studio when connected over MIDI

Turning back to V51 -> everything works perfect again.

by the way, i get the following error Message in MIOS Studio after upload:

[1505.753] Init DHCP

[1508.934] [sEQ_FILE_HW] ERROR: no space separator in following line:

[1509.064] Init DHCP

But I guess it has nothing to do with the Problem as I get the message als with V51 which causes no problems with the MIDI ins

Best Regards

Gridracer

[TK.]

Thanks for reporting this!

MIDI IN wasn't working due to a stupid copy&paste error in the MIOS32 driver (seems that I need an automated regression ;-))

MIDIboxSEQ V4.053

~~~~~~~~~~~~~~~~~


   o bugfix: MIDI IN ports are working again on MBHP_CORE_STM32 build

[/code]



The error message is probably caused by a syntax error in your MBSEQ_HW.V4 file.

Could you please send me the file for further analysis?


Best Regards, Thorsten.

[xarolium]

Hi Midiboxers,

Thank you TK to fix MIDI In Bug

I would like to know if its possible to improve IMPORT MIDIFILE fonction.

Like you describe on the V4.0Beta19 when you import midifile every note came with the same lenght. Do you think it's possible to change it that when i import my MIDIFILE i keep the lenght note i edited on my Software sequencer.

I don't know if it's clear what i'm trying to explain

Sorry for my Frogy english

Xarolium

Edited October 31, 2011 by xarolium

[Hawkeye]

Ok, I really hesitate to ask, because sooo much was added already... but there would be one little thing to improve it in my eyes :rolleyes:

Would it be possible to add a configuration switch, that allows to change the behaviour of the datahweel from the default "note editing behaviour" to "scroll behaviour" in edit mode for long-pattern-lovers :-) ?

Normally, the current step note is changed, when the datawheel is used, but for that, the step encoders are also very good.

It would be great to scroll through the track/change the currently edited step number with the datawheel (kind of like scrub, but when it is not playing and without pushing any other button).

So that one can quickly access/see different parts of a track... It would be an immense time-saver for me (the cursor keys are already totally run down :)).

I know, that one can use step view and then one of the GP buttons to jump to that section, but the datawheel for scrolling would be very intuitive for me...

Thanks, greets and have a great time!

Peter

Edited October 31, 2011 by Hawkeye

[TK.]

I would like to know if its possible to improve IMPORT MIDIFILE fonction.

Like you describe on the V4.0Beta19 when you import midifile every note came with the same lenght. Do you think it's possible to change it that when i import my MIDIFILE i keep the lenght note i edited on my Software sequencer.

Unfortunately this won't be possible, because each track has only a single length layer.

The whole MIDI event handling is based on this (e.g. to handle special cases correctly, such as notes which are longer than a step, or sustain flag enabled), so that I don't see a solution to solve this without writing a completely different sequencer engine (with limited edit capabilities).

Note that this is the reason why common MIDI sequencers (like Yamaha RM* or Korg Electribes) are so inflexible in step processing, because they store sequences in a stream based format where every note has an individual length, but where it's almost impossible to change the track direction, or to repeat a step, etc... without consuming a lot of CPU power.

In fact some time ago I hacked a stream based track mode into the firmware, but never released it since some existing features wouldn't work anymore, and since the required changes in the editor would take too much effort. Meanwhile the code has been removed...

Note: you could use the integrated MIDI file player if you only want to playback such a sequence which has been edited on your software sequencer.

Would it be possible to add a configuration switch, that allows to change the behaviour of the datahweel from the default "note editing behaviour" to "scroll behaviour" in edit mode for long-pattern-lovers :-) ?

I already considered this possibility, and I think that I should even enable it by default (behaviour could be changed by pressing SELECT button and switching an option)

Another option could be to use the datawheel for switching between parameter and trigger layers (especially useful in drum mode).

Since I'm not the only one anymore who misses this quick navigation capability, it will be added soon! :)

Best Regards, Thorsten.

[Hawkeye]

:smile: Thanks! Tell me, when you are in need of a new crate of beer, i´ll bring it over :flowers:

[nuke]

hey...

i realized that echo fx on a track doesn´t react to grooves anymore...wasn´t that working before?

greets, nik

...mm... back on v47 (just for testing) now i´m pretty unsure, if it ever was working with grooves!? :blink:

maybe i never noticed it, since never used it so excessive like i did yesterday... hehe

Edited November 2, 2011 by nuke

[gomiboy99]

Hawkeye, on 31 October 2011 - 18:01, said:

Would it be possible to add a configuration switch, that allows to change the behaviour of the datahweel from the default "note editing behaviour" to "scroll behaviour" in edit mode for long-pattern-lovers :-) ?

I already considered this possibility, and I think that I should even enable it by default (behaviour could be changed by pressing SELECT button and switching an option)

Another option could be to use the datawheel for switching between parameter and trigger layers (especially useful in drum mode).

Since I'm not the only one anymore who misses this quick navigation capability, it will be added soon!

Is this another way to go left and right? Or will it replace the Scroll function? I think it would be good to have a left right function on the datawheel. It frees up a couple of buttons on the front panel.

Tk, thanks for the excellent work.

Regards

Tim

[TK.]

i realized that echo fx on a track doesn´t react to grooves anymore...wasn´t that working before?

It works at my side, and I'm sure that it was also working before, as I use this combination in many of my own tracks :)

Or do you mean, that echoed events should take care about the groove? Thats impossible.

Is this another way to go left and right? Or will it replace the Scroll function? I think it would be good to have a left right function on the datawheel. It frees up a couple of buttons on the front panel.

We could use it for both: scrolling the cursor and switching to the next page if the cursor reached the boundary.

This would be the most perfect usage, as in most cases the page wouldn't be switched immediately if you move the datawheel (e.g. by accident)

Best Regards, Thorsten.

[gomiboy99]

That is the exactly what I meant to say.

[TK.]

I've committed the changes into the repository for beta testers! :)

Personally I will prefer to use DATAWHEEL_MODE_SCROLL_CURSOR, therefore it's default.

Following modes are available:

    const char datawheel_mode_str[DATAWHEEL_MODE_NUM][11] = {

      " Cursor   ",

      " StepView ",

      " Value    ",

      " ParLayer ",

      " TrgLayer ",

    };

[/code]


The mode can be selected by pressing SELECT + GP7 (decrement) or GP8 (increment)


Note that the Up/Down buttons of Wilba's CS have the same function which is assigned to the datawheel.


Best Regards, Thorsten.

[Hawkeye]

one word: fantastic :D

tested all modes (all are working fine) - for me it´ll clearly stay in "Cursor mode"

Thx!!!

Edited November 2, 2011 by Hawkeye

[nuke]

Or do you mean, that echoed events should take care about the groove? Thats impossible.

yep...thats what i meant...

i just noticed a "rolling" with overlapping notes and echos, when using heavy shuffles with 16th echoes...

ok...won´t work :ermm: ...is it because of different/mixed timesignatures that it can´t be snapped into groove grids?

...btw. i think i found another bug:

i get a crash with "!! HARD FAULT !! at PC=0x0802fc3e , when trying to save track-presets.

i can load my previous presets just fine,i also can save and load pattern and sessions without problems...

only saving presets gives me that crash, have to switch off and on then... :fear:

greets, nik

[TK.]

yep...thats what i meant...

i just noticed a "rolling" with overlapping notes and echos, when using heavy shuffles with 16th echoes...

ok...won´t work :ermm: ...is it because of different/mixed timesignatures that it can´t be snapped into groove grids?

yes - the echo will start once the delayed note is triggered like an audio echo. :)

...btw. i think i found another bug:

i get a crash with "!! HARD FAULT !! at PC=0x0802fc3e , when trying to save track-presets.

Classical buffer overrun, the fix is now available in the repository.

I also integrated a new footswitch extension implemented by Midilab which allows to enable live record mode from any page, delete a track by tapping on the switch, and more (in future)

Best Regards, Thorsten.

[Gridracer]

HI,

I am already curious about the next features :smile:

and i also have one in mind, may be you like it, and perhaps it is feasible:

I guess it would be nice if a parameter change with a GP encoder in edit mode would

NOT be applied immediately AS LONG as you hold the edit (or slect?) button depressed.

By this way you would not hear the scrolling through the note values during live editing if desired.

Best Regards

Gridracer

[TK.]

and i also have one in mind, may be you like it, and perhaps it is feasible:

I guess it would be nice if a parameter change with a GP encoder in edit mode would

NOT be applied immediately AS LONG as you hold the edit (or slect?) button depressed.

As long as only a single value should be handled this way, I could add this to the firmware without much effort.

But once you want to change multiple values (also triggers) and take over them by releasing the EDIT button, the effort would be too high.

Your choice? ;)

Best Regards, Thorsten.

[Gridracer]

As long as only a single value should be handled this way, I could add this to the firmware without much effort.

But once you want to change multiple values (also triggers) and take over them by releasing the EDIT button, the effort would be too high.

Your choice? ;)

Best Regards, Thorsten.

Hi, I was just thinking of one single value for only one step

and if it would only work for note and chord number it would be sufficient for me, that would avoild "disharmonics" during editing

I think an editbuffer for serveral values would be some overkill

Happy to hear that it would be not much effort and Thanks a lot if you could add it :-)

Best Regards

Gridracer

[TK.]

and if it would only work for note and chord number it would be sufficient for me, that would avoild "disharmonics" during editing

I think an editbuffer for serveral values would be some overkill

I'm glad to hear this, because while implementing the mode I noticed a big problem: the display routines take values based on complete events provided by the sequencer engine instead of directly accessing the parameter layers.

This has the big advantage, that there is a lower risk of incorrectly displayed values if I'm doing a programming error in all those if/else/if/else branches (spaghetti code...)

So, I will limit the feature to notes/chords and change the code accordingly to avoid any "it mostly works, but under this special condition it doesn't..." bug report.

I can only say: I know that it will never work perfectly!

Best Regards, Thorsten.

[TK.]

Alright, V4.054 is available now:

MIDIboxSEQ V4.054

~~~~~~~~~~~~~~~~~


   o in edit page the datawheel can now be used for different purposes:

     it can scroll the cursor, the step view, can change the value (as before)

     and it can be used to select the parameter/trigger layer.

     The function can be selected by pressing SELECT + GP7/8


   o Rômulo aka. Midilab started to implement a footswitch function which

     is especially useful for live recording and track modifications while

     playing on a keyboard.

     Press&Hold the footswitch to enable record mode, release it to disable

     record mode.

     Tap the footswitch shortly to delete the track.

     The footswitch can be assigned to a free DIN pin in MBSEQ_HW.V4


   o note and chords can now be edited without immediate change by pressing&holding

     the EDIT button. The new value will be taken over once another step is

     edited, or the EDIT button is released.


   o fixed potential buffer overrun when preset is stored

[/code]


Best Regards, Thorsten.

[midilab]

Hi Tk,

I got a request that i think isnt that hard to implement.

Something that can be preatty usefull for live situations is some kinda of delay time param for the midi data on each specific port.

Something like the "delay" we got inside ableton live to get things in time if we need to compensate some kinda of lag, or just to get a different groove shifting the time of midi data on ports.

Example:

Utils -> Opt -> Midi delay

Port Port

USB1 OUT1

-3.4 ms 2.4 ms

if it is possible to save that config inside session data will be perfect, because sometimes you need that kinda a configuration for diferent sessions and setups.

Thanks in advance!

Edited November 29, 2011 by midilab

[TK.]

Hi,

I got a request that i think isnt that hard to implement.

Unfortunately this is hard to implement - resp. if I would change the sequencer engine to cover this request, it would have a disadvantage on MIDI timing accuracy (which I find more important than such a feature)

Background: in distance to common MIDI sequencers running on a PC, the event handler of MBSEQ doesn't schedule MIDI events based on time, but based on the MIDI clock tempo.

This results into a higher accuracy. This also allows to change the tempo during runtime without re-scheduling MIDI events (especially important for MIDI Echo Fx)

As a side-effect, the granularity of the scheduler interval is independent from the time. It isn't possible to delay events with uS accuracy, only with "midi tick" accuracy, which depends on the tempo, and which is higher than 1 mS (e.g. at 120 BPM with 384 ppqn, it's ca. 1.302 mS, at 140 BPM it's ca. 1.116 mS)

For a high accuracy and stable delay compensation, I recommend the usage of audio delays!

Best Regards, Thorsten.